I come across a list of interview questions on the web for interviewing software engineers, or specifically, for coders.
What's the differences among a software engineer, a software developer, a programmer, and a coder?
It's arguable what constitutes a good developer. To me, it's the curiosity and the ability inside a developer to find and implement cost-effective software solutions that are easy to be extended by others. Knowing answers to the list below does not demonstrate the core ability of what I believe a good developer should have.
Coding ability is only partially relevant to become a good software developer. There are other factors like the ability to identify the problem, the ability to provide solution, and the ability to allow others to understand your thought process so that they can extend/maintain your code easiily.
Scrum is a flexible agile development practice / method / framework built around some agile principles and on top of BDD. Scrum is one of many agile methods. Each SCRUM team is recommended to be not too big. In Scrum practice, features of products are written from the perspectives of end users. Features are known as user stories. The collection of user stories are called product backlog, which is a wish list to make end product great.
Not every senior software developer understand good design principles. Good object-oriented design is not common. It's all about knowing the 'why' then devote to learning to design with good OOD concepts and OOP principles in programming. It takes disciplines and years of experiences.
In object-oriented design, there are three good primary OOD concepts I'd like to fall back on, and 5 OOP principles that I initially forced myself practice coding Java, then I gradually became natural doing so.
BDD is basically TDD done properly. It is an approach for building a shared understanding on what software to build by discussing examples. It is a technique that uses a business language to define acceptance criteria. It is about figuring out what to build with an outside-in approach - having conversations, capturing conversations, automating conversations. In other words, first think about what you’re about to write, then think about how you would test the code, before writing it.
BDD is not an agile project framework (e.g. SCRUM) nor a project management approach.