Many candidates struggle to express their full potential during a technical interview. As the interviewer, your job is to let them shine. You will certainly look out for red flags, and your attention will naturally be drawn to their technical weak spots. But you’ll have to be intentional if you don’t want to overlook talent.

Your job in a technical interview: prove that this very candidate is the best fit for the role. Of course they might not be, but the idea behind this approach is that if they are, you minimise the risk of not finding out. And if they are not, you will have given them a fair chance.

Before the interview

List the key competencies

Write down 5-6 technical topics that are relevant to the role. This list will be the base for your meeting notes, that you should reuse for each candidate. Highlight any deal-breaker competencies.

Then make sure you add to your list:

• collaboration: you will need to assess how their collaboration skills and teamwork experience fit with your current or desired team set-up.
• continuous learning: whatever the current competencies of the candidate, your employer will need the new hire to be ready to take on new topics.
• mentoring: depending on the seniority of the role, you might need the new hire to support the growth of their teammates. As for junior engineers, the habit of being mentored might be an indicator of their inclination to mentor someone else later in their career.

Consider that it’s easier to teach Lisp than to change one’s attitude. The importance of these competencies might outweight most of any individual technical skill.

Share your notes with your co-host

If you are running the interview with a colleague, share your notes with them upfront. They might review your topics and give you their ideas in exchange. A little bit of coordination will help you organise your speaking time during the interview, and you will know upfront whether your co-host plans to assess some of the same topics you listed.

Know your candidate

I personally find it hard to parse a CV into actionable information. Some people can read one and immediately understand the candidate’s history, and even spot what’s missing from the document. If you are one of those gifted folks, consider discussing your findings with the rest of the panel.

I will just extract the keywords. If the candidate states that they are an expert in something, then I will steer the conversation towards that something, because their own stated strengths is where I expect to find excellence. Assuming good faith here will also have the byproduct of catastrophically highlighting any potential bad faith.

Know the law

Ask your manager, or the People team of your company, for training material dedicated to interview panellists. Law and company policies might require you not to ask certain questions, or to avoid specific topics. Some look obvious, others might not. The wrong question or comment may have serious consequences; besides, labour law tends to be there to protect humans and that’s typically a good thing to do.

During the interview

Take notes

In a physical conference room, think about where you’re going to sit. Your notes might become a source of distraction if they are readable from the candidate’s seat.

In a conference call, let the candidate know that you are taking notes. If they see you typing, they will know that you’re still focusing on their interview. Consider taking notes on an online docs platform where you can share your notes with your co-host during the interview itself, if you believe this can help coordination between interviewers.

In both cases, keep eye contact as much as you can: it is very hard for a candidate to concentrate while talking to someone who’s staring at their notes.

Make introductions

Your name may be on the calendar invite, alongside the name of your team. But in most cultures, introducing yourself and what you do is a basic form of respect. Briefly introduce yourself and your team. Say your name and later listen to theirs, so that you know how to pronounce it. As a bonus, if any of you is not a native speaker, this preamble will help everybody getting used to each other’s accent.

Keep introductions brief: the candidate’s attention at this stage is focused on what’s next, and nothing you say now will likely stick.

State your intent

It is important to let the candidate know that you and them have a common goal: finding the experiences, the competencies and the attitudes that are a match for the role. You will use every precious minute to find them. Warn them that you might even interrupt them if they indulge in topics that are less relevant to the role, and they must know that you will only do that in their best interest.

Consider sharing an outline of what this meeting will be. Let them know whether it will be a conversation, or whether you’ll ask them to code, and that they will have time for questions. Consider showing your candidate the list of topics they will be tested on. While this transparency doesn’t bring you any direct value, it may contribute to the candidate’s peace of mind, which is a scarce and valuable asset.

Ask broad questions

If you ask a narrow technical question and the candidate can’t answer, what does this tell you about their fitness for the role?

The best question is the one that uncovers a candidate’s specialisation within the topic in your list. And since you don’t know where that gem is hiding, your best bet is to ask a broad question and let the candidate reveal it.

For example, if hiring for a Kubernetes software developer:

Don't ask: What are Linux control groups?

Ask: Tell me what you know about Linux containers.

Within one technical topic, a candidate may possess an extremely valuable competency that they will only reveal in response to a broad question. The candidate might not be able to explain cgroups in detail, but they know that Linux kernel features enable some degree of isolation, and they might start talking about network namespaces. By starting with a narrow question, you might never know about their passion for virtual networks and interfaces.

Note that with broad questions, you may need to lead the candidate back on track if they choose a direction that is not relevant to the role. Also, some candidates will perform better with narrow, specific questions. Don’t let them down.

Broad questions can be definition-type questions, like the one above, or for example experience-type questions (“tell me about the last time you solved a bug”), or exercise-type (“how would you diagnose a malfunction in Kubernetes?”). Experience-type questions may be very revealing but also a potential source of noise, because everyone’s professional history is influenced by factors that have nothing to do with their skills. Well-crafted exercises on the other hand are complex to design but may provide great insights.

When asking definition-type questions, pay attention to how the candidate builds the answer. Do they randomly throw one fact after the other, or do they take the time to structure their knowledge? This can help you assess the degree of operational vs conceptual knowledge they possess. Operational knowledge tend to make people faster at solving problems. Conceptual knowledge typically makes one better at finding solutions to new problems.

Especially for a junior position, consider asking what their favourite topic is within their branch of software engineering. Bring popcorn.

Note that sometimes the role requires some very specific technical knowledge, for which you have to ask very narrow questions. But then ask yourself whether a motivated hire could acquire this knowledge on the job.

Ask all the questions

Make sure you give each candidate the chance to showcase their expertise on each one of the topics in your list: it’s about fairness. You may also prepare a small set of questions that you ask each candidate for an apples-to-apples comparison.

If the candidate doesn’t fare well with some topic: give them the chance to succeed by asking a couple different questions on the same topic. If that doesn’t work, consider giving them your answer and observe their reaction. They may realise they knew the answer all along, and build on it. Or they may express joy in learning something new, and this tells you something about their continuous-learning skills. Or they may react negatively, giving you a valuable data point to consider.

In any case, if they digress: don’t let them waste their precious time.

Example questions to assess Collaboration:

• What do you expect in a code review?
• Do you often review other people’s code?
• How do you effectively work in a group?
• You are tasked to implement a new complex feature. How do you set yourself up for success?

Example questions to assess Continuous learning:

• How do you keep your professional knowledge up to date?
• Is there a technology topic that caught your attention lately?
• How would you leverage in your work?
• You’ve been assigned a bug for a feature you didn’t write, and you know very little of the code involved. What do you do?

Example questions to assess Mentoring:

• How do you support the growth of your junior peers?
• Have you ever been mentored?

And answer some

Leave some time at the end of the meeting for the candidate’s questions. Is the role clear to them? Have they understood what the team does?

After the interview

Immediately review your notes

Review your notes and integrate them while you still remember what was said. Make sure that your notes will be readable and meaningful even in a couple days when your attention will be on something else. For each of the key competencies you investigated, add a concise assessment and identify one supporting fact.

Add your impressions at the bottom: this will help you remember which candidate was which later on.

Process your feelings

Take a moment to reflect on your notes before the hiring manager asks you about your assessment. Depending on the hiring process in your company, hours or days may have passed since the interview. After this pause has your sentiment changed with regard to the candidate? In which direction? If your notes can’t justify the enthusiasm you felt for a candidate, then maybe this means that they were able to make a connection with you. You may disregard that feeling as a disturbance, or you may choose to report it alongside the rest of the data points, now that you have isolated and identified it.

The same goes for a negative sentiment: what did the candidate do or say to make you uncomfortable? One of the hardest responsibilities as a panellist is to choose what to include in your report. Try to isolate and identify that feeling. If you think that helps, discuss with your co-host if you had one. If you come from an underrepresented group, some of your impressions may not match with everybody else’s and this is precisely what makes them so valuable.

Report with supporting facts

When it’s time to report to the hiring manager, briefly go through each competency. State your assessment for each and add a supporting fact for the big ones. Your notes will be useful if there is a discussion. The format here is heavily dependent on the hiring manager’s preference.

Listen to what the other interviewers say. It may reinforce something you were on the fence or contradict what you learned, which would imply further investigation may be needed.

Good luck

To recap, my guiding principles are:

• focus on assessing each of a well-defined list of competencies;
• what they call “soft skills” are core engineering competencies when teams have more than one person;
• give the candidate the opportunity to shine, asking the questions you think they will answer best. If despite all your efforts you don’t find what you were looking for, then you can tell it’s not a match.