Interviewing people by phone for senior developer roles in my todo list for the week. Another roll of the dice.
Is difficult to assess fully if the candidate is trustworthy and resourceful. We can only do our best to decide if it's worth to move further with the candidate and bring him to another stage.
These interviews are a mix of screening questions about the predominant programming language, object-oriented programming, databases, distributed system, software engineering practices and agile principles.
We find that, generally, developers know their language very well.
When it comes to object-oriented programming concepts, such as Inheritance, Composition, Polymorphism, Encapsulation and Composition, we still find that the candidates are well versed in those as well.
But, architectural principles questions are when the score starts to go down. It looks something like this picture.
Software engineering practices questions are where candidates score lesser, according to the guideline standards. We try to understand what the candidate believes to be his responsibility when it comes to testing.
These question generally focuses on BDD (Behaviours Driven Development) and TDD (Test-Driven Development). When we ask if they practice TDD, we hear an explanation about the process. Excellent knowledge.
We then ask the candidate to sell us the idea of TDD in a role-playing game.
They are the senior developer, and we are the TDD sceptic junior developer. The conversation could go like this:
(We) Junior dev: TDD? Is a waste of time.
(The candidate) Senior dev: You make sure your code has no bugs. You don't need to stress about receiving calls in the middle of the night go into firefight mode while your code is burning in production because your code is tested to work...
(We) The junior dev: Yeah, but then if the requirements change, then I have to change in two places.... the production code and test code
(The candidate) Senior dev: huum.......ahhh.... well, the requirements can't change during the sprint...
(We) The junior dev: But aren't we agile, shouldn't we be responding to change over following a plan? And if the requirements change, as they always do during the sprint? And if we do Kanban? And if there are no sprints.
Here is where we find the answers to show that, although they know how to practice TDD, they do not appreciate the benefit of this practice yet.
They may not have applied TDD enough to feel the real benefits. And that's also ok.
Experience tells me that doing the test code first (the fundamental essence of TDD) or doing the test code after, both approaches works.
But how well it works. I can only tell from my own experience.
Some studies say that the benefits are marginal. However, being able to respond to change has a lot to do how well a developer can advance the code to do something else more to meet business needs.
Advancing the codebase generally requires that code has to change, reused and sometimes completely dumped in the trash. Code is alive.
Helping advance your code safely is where software engineering methods come to rescue. Test-Driven Development is one of these methods.
When teams adopt Test-Driven Development mindset, then projects can benefit from:
- More reuse and thus saving time, by using more abstract design and code;
- Introduce new functionalities faster, by designing and coding with extensibility in mind;
- End-users won't find faults because of well-tested code.
By understanding how software engineering methods, such as TDD and BDD, developers will be able to respond to changes in the business, quicker and with fewer defects.
Benefits of this side effect of software engineering methods include:
- Reduced Development and Maintenance Costs.
- Improved Customer Satisfaction
- Reduces Cycle Time
- Increased Profitability
- Improved Professional Staff
For reading up to here, I want to give something to your teams.
Back in 2012, I was helping software developers to adopt software engineering practices because their employers wanted better software. One of those practices is Programmer Testing, which focuses on Test-Drivel Development.
Sessions for this training was about five hours for Programmer Testing. We started with the concepts, discussing them and then do a few exercises to put the concepts in practice. We also planned how they could introduce this to their coding practices.
If you want to use these slides as a template for your team's internal training programs, you can download them now.
You might also want the exercises. I have in PDF format and PPTX format.
Note: the exercises have not been updated yet and are using old versions of Java. If you need help updating these, let me know.
You should receive an email from me shortly with all the links.
If you don't see my email in your inbox in the next 5 minutes, then check for the spam folder for my email from firstname.lastname@example.org
Thank you again for your interest in my material.
Can I send you all the training material to your email?
Good software developers keep their cognitive muscles sharp by life-long learning.
Why not use all my material and customise it to your software development teams training programs?
If you give me your best email, here's what I will send you to your email:
- A link to a shared Google Drive folder with all the material in editable format
- A link to a zip file with all the material in editable format
The editable training material has the following templates:
Why do I want your email?
You're probably involved somehow with software development, and you care about the skills and competences of your development teams.
That's why I think it might be a good idea to have an informal chat about what your pain points might be and see if I can help.
My name is Joao Pereira, director and principal engineer at Yule Technologies, LTD.
I build software commercially for more than 18 years, and while working in a myriad of roles in multiple projects across different industries, I learned a bit about this industry.
I'll build your ideas. I'm very hands-on and code a lot, mainly in Java and distributed systems. I'm formally certified and have experience in Agile Methodologies and more waterfall' ish ones, like PMP from the Project Management Institute and have led multiple development teams during my career.
Will you let me send you all training material and get in touch?
- This email is not valid.
- Name seems odd.