Lately, I’ve been thinking a lot about technical interviews, from how to ensure I can get the data points needed to decide to ensure the candidates enjoy it and find it useful rather than annoying but needed steps.

More often than not, technical interviews focus solely on algorithms, with a binary mindset: the candidate either solves the problem or not. I’ve written before about how I think that is a sign of a broken process, and I’d be delighted if you give it a read but if you can’t be bothered here’s a summary:

I argue that the interview process is broken, not only because it doesn’t evaluate what I think matters (knowledge, expertise, or even problem-solving skills) but, more importantly, because it can be gamed (as shown by multiple courses and books about the topic). Ultimately, this happens because evaluating those skills is more subjective and requires more time and skills from interviewers and managers to make a decision.

Recognizing that there’s something wrong with the most common interview method is a step in the right direction but where do we go from there? Interviews are not going anywhere, we still need to somehow evaluate candidates. The key for me is changing the focus of the interview: from hard technical skills to soft technical skills

The change is subtle but significant. Both are important and must-haves but we’re switching from skills that are easier to learn to skills that are hard (and sometimes almost impossible) to learn.

With that in mind, I have created a technical interview with these goals in mind: 1) ensure the basic hard skills for the role are there and 2) evaluate the soft skills are also there. My interview style is far from perfect and it’s ever-changing, but, in general, I’ve felt pretty confident about the decision and I can take from the data points it offers me

Here’s a list of do’s and don’ts I arrived at that helped me make the process as useful for me and the candidates as possible. Of course, this is not a list of rules but a guideline, and a technical interview for a senior developer will have different guidelines than a technical interview for a junior developer. As a rule of thumb, the more senior the candidate the less prescriptive the interviewer should be. This list is informed by my more recent experience interviewing mostly senior candidates.

Do’s

• Do ask open-ended questions. These questions allow you to understand what the candidate thinks about the given problem and what they consider important.
• Do let candidates lead the answers in the directions they consider important.
• Do steer candidates into a new direction if you think the direction they’re taking is way off. And be mindful that candidates not being able to answer relevant to the question is a data point in itself
• Do pay attention beyond the actual answer and think about how they deliver it, how they get the message across, and how easy it is for you to understand their thinking process.
• Do ask the candidate to explain a topic or a project you’re not familiar with. This is something that, if they are hired, they will have to do at some point. Do you feel you’re missing context? Do you feel they are explaining things at the right level of abstraction?
• Do ask the candidates to provide some code to ensure the minimum coding skills are present. How did they structure it? Is it consistent?
• Do ask them to walk you through how they would approach a problem that you or your team have dealt with. This is not to see if they would have done the same but to understand how they would reason about it and how they would try to clarify the problem
• Do ask them about a technical decision they made in the past and if they would do something different with the information they have now. If they wouldn’t change a thing about the decision, that could be a red flag, but if they can clearly explain what they’d do differently and why, then that indicates that they have reflected on it.
• Do follow up their answers with more questions. Keep digging into the topic and try to find out how deep their knowledge is in that area.

Don’ts

• Don’t be prescriptive
• Don’t try to steer the candidate towards the answer you think is the right one. You should not be interested in asserting whether the candidate would solve a problem the same way as you would.
• Don’t interrupt them. Let them find their flow. Some people are better at explaining themselves and feeling comfortable talking to strangers and others aren’t as good. Give them a chance to get there. Conclusion

As I said before, this is a guideline and not a ruleset. They help me navigate interviews with different candidates and add some objectivity to something very subjective, and, at the end of the day, you will have to rely on your intuition and judgment.