I'm currently reading the book The Software Craftsman and wanted to share some tips and knowledge when it comes to interviewing software developers.

Let's start off with this first quote from the book:

A good interview is like a good and informal chat between passionate developers. It’s an exchange of information: a good debate about techniques, tools, challenges, and approaches to software development.

What to look for?

When interviewing, we should look for talent, attitude, passion, and potential, not knowledge of specific technologies.

In the book, the author speaks about a story of a guy whom he interviewed, who didn't have much experience with the technologies they used and basic TDD skills, though the author could see how passionate he was about trying new things. They hired him, and after a year, he became one of the best developers they had.

The moral of the story, passion matters the most, with passion comes potential, because when someone is passionate, they will naturally be open-minded and are constantly looking for ways to learn.

It's also extremely important to hire someone who is humble, which the book The ideal team player emphasizes, someone who is not scared of being convinced differently, and don't see that as if they were wrong, rather they learned something.

Someone who is down to earth and happy to share their knowledge with others, and takes responsibility, if they did something that wasn't good, they will look for ways to improve and do it better.

Going back to the first quote mentioned from the book, by having a debate, we can see if the candidate is curious, open-minded and down to earth, or if they are rather constantly being defensive, not willing to learn and are narrow-minded.

The book gives us points we should have a look at in a candidate:

• How enthusiastic and passionate the candidates are when talking about technology, their previous projects and jobs, and their own achievements.

• How do they describe their failures?

• Do they take any responsibility for things that went wrong or do they just blame others?

• Have they done anything to turn an unpleasant situation around?

• Have they done anything in their previous jobs to improve the things they were complaining about?

• What sort of environment are the candidates looking for?

• Can we match their expectations?

A red flag

If a candidate isn't asking questions, that is a clear sign they may just be looking for another job.

Always prefer candidates who ask questions over those who don't, not because they are necessarily better, but because they really care about their career and finding the right company, being in a place they enjoy.

Interviewing

Focus

The book speaks about focusing on that which is important to the company, instead of chatting about things that aren't really relevant.

• What are our core values?

• What are the key skills we need?

• What are the things we would like to do better?

If we value technical practices such as TDD, pair programming, refactoring, etc. then we can chat with the candidate about these practices, what do they think of these practices? How do they relate to building quality software and satisfying the customers?

Mind-mapping

The author speaks about a technique he finds useful when chatting with the candidate, mind-mapping. He usually takes a piece of pen and paper and starts the interview with a very open question.

• What is well-crafted software for you?

• What are the main challenges in a software project?

Open questions like that tend to be answered with a list of things like maintainability, testability, readability, performs well, satisfies requirements, and so on. Each item in this list becomes a node, hanging off from the mind-map root well-crafted software. With that, we can start exploring one of the nodes and mapping the conversation against them, creating new nodes according to what is said—either by the interviewer or by the candidate. Whenever I’m happy with the conversation about one of the topics, I can easily go back to one of the other nodes that are hanging off the mind-map root. “We talked about readability, but you also mentioned testability. Could you expand on that?”

If I want to be slightly more specific, because the conversation doesn’t get to where I want it to, I then ask a more direct question: “What do you think about TDD?” This will lead to another interesting conversation captured by the mind map.

Once the interview is finished, I have the entire conversation mapped, which helps me to remember every conversation I had with each of the candidates.

I took the following excerpts from the book because I think the author himself explains it beautifully on how he approaches mind-mapping.

Further questions

I thought of listing out further questions you can ask when interviewing a candidate, questions that will tell more about the candidate:

• What is your process when it comes to fixing bugs?

• Can you tell us about a tough software development problem and how you solved it?

• What are you most passionate about when it comes to software development?

• What are your career aspirations? Where do you want to be in months and years from now?

• Why do you think we should hire you?

• How do you assure the quality of your software?

• Do you have any questions for us?

• Can you speak about some mistakes you learned from?

• How do you keep your skills sharp and up to date?

Pair Programming

We shouldn't hire developers without seeing their coding, a good pair programming session is great, there is a lot we can get from it and could even be enough as the technical interview:

• How quickly the developer decides on which tests to write—that shows experience

• How familiar they are with the tools (the integrated development environment [IDE], language, testing and mocking frameworks, usage of shortcuts, etc.)

• Choice of names for classes, methods, functions and attributes

• How clean and expressive the code is

• How the developer reacts when the interviewer makes suggestions or comments

• Their thought process

• Their care in not just solving the problem but also how they are solving the problem

Pair programming means pair programming and not standing over someone’s shoulder and applying unnecessary pressure. That’s not how we usually work with our colleagues and there is no point to behave this way with a candidate.

I think this is an important point brought up in the book, as the interviewer, we shouldn't let the candidate struggle for too long, it is a pairing session, not standing over their shoulder and putting unnecessary pressure.

Anti Patterns

In order to attract good developers, there are things we should avoid doing as the interviewer.

Smart Ass

Don't be arrogant.

Don't try to make yourself look smarter and better than the candidate, or impress them with your job title, responsibilities, skills and whatnot.

Just be honest, humble and down to earth, be open-minded and listen to the candidate, treat the candidate as if you were to have a technical conversation with someone you respect.

You could even end up learning a thing or two yourself.

Fool

This kinda goes hand in hand, but don't try making the candidate look like a fool, even if the candidate says something that is obviously wrong.

The interview should be a conversation between fellow software professionals, feel free to perhaps correct the candidate and teach them something.

Be humble and down to earth.

Don't ask questions to which you don't know the answers

If you aren't sure about the question and the answer to the question, they are probably not very important to the job, focus on that which is important to the job.

Don't try to trick the candidate with confusing and misleading questions.

Don’t block the Internet

To me, this is pretty clear, if we think about the work environment, the last thing we want is for the internet to not work, or how else will we be able to develop our software?

Also, knowing everything on top of the head, no developers do that, and the ones who try to memorize everything, in my opinion, aren't smart, as Albert Einstein said:

Never memorize something that you can look up.

Don’t code on a piece of paper

Coding on a piece of paper makes no sense.

This is not even what the candidate will be doing at their job.

We should look at real code produced with real tools and not some scribbles on a piece of paper or whiteboard.

Don’t use algorithms

Again, will this be the job of the candidate?

Focus on what's important, what do we value and need in our company.

If the main problems we have in our system are not about algorithms, we should not use them in our coding interviews. We should focus on giving candidates exercises where they need to design a solution and express the business domain. If we need developers with good skills in Test-Driven Development and design, we should use exercises that reflect that.

Obviously, if the main problems and tasks are about writing algorithms, then we should test the candidate's skills when it comes to writing algorithms that resemble the algorithms which we write and need in our company.

Conclusion

Well, I certainly learned a ton myself when it comes to interviewing software developers by writing this and reading the book The Software Craftsman.

I hope you found this article helpful, I will likely refer back to it many times when interviewing developers.