Running Great Tech Interviews: The Art of the Follow-up Question

The key to clear and decisive tech interviews is to ask good questions with good follow-ups. You need to know what you’re looking for and how you’ll find it.

The aims of the interview conversation

An interview is not just any conversation. It should be a purposeful conversation, and your main role as an interviewer is to direct what the candidate talks about. That direction should give the candidate opportunities to show whether they have what you’re looking for. That means knowing in advance what you’re looking for.

Typically the questions we should be looking to get answered are:

1. Can the candidate produce solid, relevant technical work?
2. Can they communicate about that work clearly?
3. Will they work in a focused and sensible way?
4. Are they comfortable making compromises and trade-offs?
5. Do you feel we could work with them?

Leading the interview conversation

Start from the CV or any of the candidate’s work. Look for suggestions that this candidate has done something relevant or interesting. Get the candidate to tell stories and explain their decision-making on that work by moving the focus to work that the candidate has done and how they’ve approached problems. You want to avoid focusing too much on names and companies they’ve worked for and unnecessary context of previous jobs.

Here are some great starter software engineering questions:

• Is there a piece of work from that time that you’re particularly proud of?
• Could you give a brief example of something that you personally contributed to the team’s work?
• Did you learn a lot in that role? Any lessons in particular that you learned?
• Could you briefly summarize your experience with technology X?
• What was the toughest challenge you faced working on/at Y?
• I don’t know much about Z. Could you explain the essence of it to me?

These types of questions direct the candidate on what to talk about. And they give hints on how much detail you want. Your tone should be friendly and approachable. But don’t let the candidate spend too much time diverting by asking for an explanation – tell them you want to know what they think.

Candidates like clear direction

If you’re not clear what the candidate is talking about, you should tell them that. Make sure the impetus is on the candidate to make themselves understood. If you can’t understand them then you can’t hire them. The point is not to find out if the candidate is a good communicator. It is to find out if they can communicate with you. Ideally about problem-solving close to your work.

Drilling Into Details

Let’s see what this approach can look like in detail.

Candidate: I introduced a new library for mapping code entities to the database. It sped up some queries by 40%.

You: Were there any challenges with introducing that?

Candidate: When I first looked, it wasn’t compatible with another library we were using. But we were planning to upgrade that library soon anyway, so we brought that upgrade forward, and it worked with the newer version.

The initial story is a good start but doesn’t show you problem-solving. The follow-up leads into the challenges. The handling of those challenges reveals sensitivity and suggests good collaboration skills. If this were a real conversation they’d name the library and what the incompatibility was. This requires some common ground. You want to direct the discussion so that you can ask good follow-up questions. If the candidate doesn’t remember the level of detail you want then you can ask for a more recent example.

Let’s consider another example.

Candidate: I led the implementation of a new feature to generate business insight reports.

You: How did you ensure the reports offered the insights the business was looking for?

Candidate: It took a couple of iterations to get them right. We agreed on initial specs, but they were a bit rough, and the business wasn’t very clear from the beginning. In the second iteration, they got more excited and could guide us more clearly.

Again, the initial story doesn’t demonstrate much. It asserts an achievement, but it doesn’t demonstrate it. The answer to the follow-up leads us to an appreciation of stakeholder management and requirements solicitation. It could still do with more detail, and you could follow up to ask about how they worked to get better specs. Getting into detail does not have to be based on stories. You could ask the candidate to draw out the design of the last system they worked on. Or work through a small coding problem like LeetCode.

Being organized for good interviews

Often you’re under time pressure. You have a mountain of candidates to get through. You’ve got loads of other things to do. If you’ve not looked at the candidate’s CV properly, then just tell them that. Ask the candidate to walk you through it.

When you’re rushed then you tend to go with the flow. That leads to letting the candidate talk too freely and without structure. You need to be directing the conversation.

You want to think before the interview about what you’re going to probe on. Maybe you want to know about an experience with technology X. Maybe you’re not sure they’ve worked to tough timelines. What could the candidate say that would answer or confirm those concerns?

Think about what kind of stories you’re looking for. Imagine yourself interviewing for the role. Consider what work you’re proud of. Or some great work that a colleague did. You’re probably looking for stories a bit like those. If you’ve used a technical test then it’s valuable to review it well before doing a run-through with the candidate. Having a few notes going into the interview makes a big difference. When a candidate scores well on a technical test it certainly shows some skills. But you gain more confidence from walking through the thinking. Then you see the skills in action.

Having a strategy for interviewing

It might sound like I’m recommending behavior-based interviewing. Talking about specific scenarios is certainly the essence of behavioral interviewing. But I’m only recommending a similar style of questioning. It’s a tool to get into enough detail to reveal problem-solving skills. You don’t want to let the interview become a chat that doesn’t give you answers. You want to have a strategy and then improvise a bit within that strategy by following things they say to get more detail. Part of having a strategy is knowing what you’re looking for. Think about what you’d need in order to say yes to a candidate. This forces you to think about what you’re really looking for.

Confusion often enters the process around what is needed for the role. Job ads may ask for all the relevant skills and background for the job from day one. This is rarely necessary. Aptitude for learning and problem-solving should be given more weight. It’s ok to list all the relevant skills on the job ad. But don’t let that dominate the interview. There’s a risk of turning the interview into a box-ticking of technologies and experience. That won’t really give you confidence. You need to see that this person can think about relevant problems and share their insights with you.

This article was written by Ryan Dawson for HackerNoon and was edited and published with permission.