Designing fair technical interviews that work

You’ll probably recognise this. A candidate who seemed perfect on the first call goes quiet as soon as the take-home test lands in their inbox. Or the opposite happens: you hire someone who flew through an algorithms exercise and, a few months in, you notice they struggle with exactly what the job asks of them every day.

Both problems tend to come from the same place, an interview process that measures the wrong things or measures them differently depending on who’s interviewing. When a company asks us to help review its technical process, nearly everything we change has to do with clarity. What gets measured, with which exercise and against which criteria.

Decide what to measure before you pick the exercise

The most common mistake is building interviews out of habit (“we always do an algorithms test here”) instead of starting from the role. Before thinking about formats, write down what really makes a difference in the job. For a senior backend engineer, that might be system design and judgement when choosing between options, the quality of the code they leave behind (readability, tests, maintainability), how they debug a production issue, how well they work with product and other teams, and how far they get on their own before asking for help.

Then assign each skill to a stage. If one doesn’t appear anywhere, you’ll end up deciding on gut feeling. If it appears in three, you’re wasting the candidate’s time and your team’s.

The closer to the real job, the better

No format is perfect, and it helps to know what each one gives you.

A take-home exercise lets people work calmly, but it penalises those with less free time, who are often the ones carrying the most responsibility. If you use one, keep it to a few hours and say so clearly when you send it.

Live pair programming shows how someone thinks and collaborates, as long as the problem is realistic rather than a puzzle. A code review, where the candidate comments on a snippet with flaws in it, says a lot about their judgement and how they give feedback. For senior roles a system design session is close to mandatory, and what counts there is the reasoning more than landing on a particular answer. Talking through one of their own projects works very well when the person can show real work, though confidentiality means not everyone can.

Our rule of thumb is simple: the exercise that looks most like the job gives you the best information.

Agree on scoring first

Without criteria agreed in advance, each interviewer values different things and the outcome depends on who the candidate happens to meet. A couple of habits fix most of this. A simple rubric for each skill, describing what a weak, a solid and an excellent answer look like. The same core questions for every candidate in the process. And every interviewer writing down their score before discussing it, so the first opinion voiced doesn’t sway the rest.

Bias never disappears completely, but you can reduce it a good deal. Replace “would they fit in the team?” with the specific behaviours you value. Aim for a varied panel. Check whether any exercise rewards something unrelated to the job, like recalling details from memory that anyone would look up in the documentation. And ask openly at the start whether anyone needs an adjustment.

They’re interviewing you as well

It’s easy to forget when you design a process from the inside. A reasonable technical process fits into three or four stages, and beyond that every extra step should justify what it adds that you haven’t already seen. A few things candidates really appreciate:

• Hearing about every stage up front, how long each takes and who’s involved.
• Knowing the format of each exercise in advance, since you’re not trying to measure how they react to a surprise.
• Getting an answer within a few days of each stage.

Prepare your interviewers too. A good engineer isn’t automatically a good interviewer. Spend some time explaining what each stage assesses and how to use the rubric, how to give hints without solving the problem, which questions are off limits (personal life, family plans, age, background) and how to present the company and the team.

A structure that tends to work

For an experienced engineering role we usually suggest something like this: an initial conversation about background, motivation and terms; a focused practical exercise linked to the real work; a system design session or a review of that exercise with the team; and a final interview with the hiring manager about collaboration, values and expectations.

Afterwards, hold a short debrief where everyone presents their scores and reasoning. Before the process starts, make it clear who has the final say and what happens if people disagree. And every so often, look back. Are the people you hired performing well? Do the candidates who drop out always leave at the same stage?

When someone doesn’t make it

This is the part most often neglected. If someone has spent several hours on your exercise and you turn them down, send them brief, specific feedback on what went well and what was missing. It costs very little, and it’s what makes that person speak well of your company even though they didn’t get the job (and perhaps apply again in a couple of years).

At Mimmic Talent we assess candidates before we put them in front of you, and we like to go over the technical process with the people who’ll be interviewing. If you’d like a second opinion on yours, tell us about it.