What questions should I ask the candidate for a software engineering role?

I was recently taking part in a discussion about how to conduct the first phase of a technical interview. You know, the one in small to medium companies, without any strict guidelines for the process, when you meet the candidate for the first time, and the interview is split in two between HR and engineering. A lot of suggestions came up from people: to ask about personal projects, there were proponents and opponents of live coding, and of course dozens of examples of great technical questions both about theoretical as well as practical topics.

While I agree that a practical test is a crucial part of the process, I would personally postpone it for later, as it tends to require a lot of effort, both from the candidate as well as the person reviewing the results. Instead, I’d focus on a short conversation, that can quickly reveal if the skill level matches your expectations. You can think about it in the following way: the interview’s purpose is for you to have an idea of what to expect of the candidate in the first month (the onboarding phase), as well as their first quarter (the first larger task), and then 12 months (the prospect of growth).

Present the candidate with a hypothetical task for each of those periods. Ones that are down to earth, you can simply think about the last person that joined the team and adjust some of the tasks they completed. Then simply ask the candidate how would they approach them. Things to pay attention to at this point:

• How quickly do they understand the task?
• Are they asking for clarifications or making assumptions?

Then, the crucial part: ask a lot of follow-up questions. Two, three levels deep of followups at least. For example, depending on the task of course, ask about their technology choices: language, framework, architecture. You don’t even need to be familiar with them, nor have an opinion on what would you use yourself, because the goal of this interview is not to guess the answer you’re expecting. There are no good or bad answers.

Why did you choose A over B? What advantages do you see going with A? What are the downsides? In what circumstances would you consider C for the job?

That’d be the first follow-up. You’re not assuming either of the choices is better than the other, that’s for the candidate to justify. Are they doing that, or are they just going with what they know? That’s a valid reason too, given there are no other requirements. So follow up by adding some made-up context.

Given that Z, X and Y is important to us, how would your choice hold? Would you still consider it the best?

So the candidate can put their answer in context. I mentioned there are no right and wrong answers, there are only solutions that solve problems and meet criteria, and those that don’t. And each situation is different, so it’s best to talk about specifics. Next, ask how specifically they think their solution fits the requirements.

You claim that A will provide the best tools to achieve Z and X. How is that exactly? Explain it to me in detail as if I had no experience in that area (hint: you might as well have none). What is the practical application of the mentioned theory?

Things that might seem obvious to everyone in the room are questioned this way. Do the candidate really understands why and how the problem is being solved? Or are they just cargo culting or quoting others without deeper understanding? Be curious at this part. Ask a lot of How’s and Why’s. At any point you can dig deeper until you reach some fundamental truths they believe about software engineering. Continue until it hurts and the candidate starts to struggle with answers. You’ve probably reached their limit then.

What have you learned this way?

• If you can have a curious conversation with that person. Are they communicating their thoughts clearly? Was it a pleasure to have that discussion?
• You probed their skill level. Are they just proficient on the surface, or can they go multiple levels deep? I’m not saying then necessarily need to, but you have that knowledge now.
• Do you agree with their justifications? Not with their choices, not if they figured out the same solution you did, or picked your favourite tool for the job, no. Remove that bias. Were their choices justified given the constraints? Did they adapt to the changing circumstance? If so, they’ll probably efficiently adjust on the job instead of sticking to their favourite framework.

At this point, what do you think? Will they fit the team? Would you have a hard time accepting the solution they proposed for their first task, or would it rather just require ironing out some rough edges? What qualities will they bring to the team, that you might lack at the moment?

Technical skills will be learned — attitude comes harder. Pick for the latter one, and any shortcomings in the former will quickly be made up. Just remember to go where the conversation leads you, be open, be curious, let them speak and follow up with open questions a lot.