A Human’s Guide To Technical Interviews

The first step is to keep it simple.

You want to see how well the candidate will perform in your work environment. Unless your work environment is high-pressure & high-stress, this means keeping things relaxed.

At the end of the day, you want to evaluate intelligence rather than the depth of their framework knowledge. Don’t get me wrong, they have to be able to write code, however, it’s far more important to have transferable skills such as problem-solving abilities, rather than knowing every nuance of the Python dict hashing algorithm. Frameworks can be taught. Intelligence, not so much.

Begin the interview as casually as possible. Get them settled and relaxed and show that you’re human. A good way to ease into it is with easy questions such as,

“What do you like most about being a developer?” Or, “When did you realise you wanted to be a developer?”.

Where possible I’d suggest not having more than two interviewers, otherwise it can feel like an interrogation and increase stress levels. Stress negatively affects how you think, which can be problematic when you are trying to see how the candidate thinks when they are relaxed.

The second step is discovery.

It can be good to have a bank of questions prepared in advance, however make sure to only use them as a guide. Generally, start with an easy questions, and progressively ask harder questions, based on their answers. The goal is to gradually explore their strengths and weaknesses so that you build up a detailed picture of the candidate’s abilities.

Avoid contrived questions as much as possible. Rather, aim to ask questions people would ask on a daily basis. Avoid questions like, “please write an algorithm to sort an array without using in-built functions”.

That’s not exactly the kind of thing you ever need to do when writing production code… (unless of course the role involves creating sorting algorithms, in which case it’s probably completely sensible). Again, you want to mirror their daily work experience as closely as possible.

Remember, the purpose of asking them questions is not to look for a perfect answer, rather learn how they solve problems. As you’re exploring their strengths and weaknesses, be sure to ask some questions that are a bit outside their abilities.

The goal here is not to see them fluster, but to observe how they handle failure.

Do they admit they don’t understand? Do they ask for clarification? Are they able to reason through the problem?

The third step is to explore.

Personally, I don’t like take-home coding tests. While they are good in that they show how a developer solves a complex problem, they provide limited insight into how they solve problems in a team setting, with people around them from whom they can ask questions and ask for clarification.

The trouble is, whether they arrived at the correct answer is less important than how they arrived at it. You want to see how the candidate thinks and solves problems. In the past I’ve found that a powerful way to do that is to ask them to bring in a small sample of their own code (or code they like).

It doesn’t have to be perfect code, and indeed they shouldn’t be graded on the code itself, so much as how they answer questions about it. Use it as a talking point: go through the snippet during the interview — this will give you a good idea of what they are interested in and how they think.

Perhaps they talk about the code’s aesthetics, or maybe they talk about the technical nuances or security aspects. Great questions to ask include “why did you do X this way?”, “what would you improve?”, and “could you explain X?”.

Just keep in mind that a technical interview isn’t all about the tech. It’s about understanding the candidate, what makes them tick, and whether or not their style of approach will align with you and your team.

Having trouble hiring a full stack developer?