What to look for in a coding interview

The four things worth scoring

1. Decomposition — can they turn a vague problem into parts they can start on?
2. Verification — do they test their own work before you point at it?
3. Recovery — what happens when something does not work?
4. Readability — could you review this code without rewriting it?

Decomposition: the first five minutes matter most

Watch what happens before any code is written. Strong candidates restate the problem, ask about inputs and constraints, and name an approach before typing. Weaker ones start coding immediately and discover the requirements by colliding with them. This is the single most transferable signal in the round, because it is exactly what the job asks for — most real work starts with an under-specified request, not a clean problem statement.

Verification: who finds the bug

The most informative moment in a coding interview is usually when the code does not work. The question is who notices. A candidate who runs through an example by hand, finds their own off-by-one and fixes it has demonstrated something a correct-first-time answer cannot. Leave space for this: if you point out every problem immediately, you convert the interview into a test of how fast they can take instruction, and you lose the signal entirely.

Recovery: the response to being stuck

• Do they narrow the problem? Reducing to a smaller case, adding a print statement, checking an assumption — these are the behaviours of someone who debugs for a living.
• Do they say what they are thinking? Silence is not necessarily a bad sign, but you cannot score what you cannot observe. Ask.
• Do they take a hint well? Offer one, deliberately, and see what they do with it. A candidate who takes a small hint and runs is more useful than one who needs it restated three times — and both are more useful than one who ignores it.
• Do they get rattled? Distinguish between flustered-but-functional and genuinely derailed. The first is an artefact of the setting; the second might be real.

What is not signal

• Typing speed, or using an unfamiliar editor. You are not hiring a stenographer.
• Knowing the trick. Problems with a single insight test exposure to that problem. If you must use one, give the insight away and score what they build on it.
• Syntax recall. Tell them to write pseudocode for the part they cannot remember and move on. Nobody writes production code without a reference.
• Nerves in the first ten minutes. Almost universal, and uncorrelated with the job.
• Finishing. Calibrate so that most strong candidates do not finish. Then completion stops being the score and reasoning becomes it.

Run the round so the evidence is comparable

• Use the same problem for every candidate at a level. Your sense of difficulty is anchored on the candidates you have already seen; comparability requires one problem, not a fair one.
• Decide the hints in advance. Write down the three hints you are willing to give and in what order, so one candidate does not get a guided tour and the next a wall.
• Score during, not after. Note the moment they identified the constraint, the moment they tested. Afterwards you will only remember whether it felt good.
• Say the rules at the start — whether they may search, whether they should talk aloud, how long they have, whether finishing matters. Half of bad coding-interview performance is uncertainty about what is being assessed.

Pick a problem that resembles the job

For most product engineering roles, reading and extending unfamiliar code predicts performance better than a graph algorithm. Give them a small, working program with a seeded bug or a missing feature, and watch them orient. That is the actual job, and it has the useful property of being hard to prepare for in a way that does not also make someone better at the work. See how to test coding skills without LeetCode.

Score against a rubric you wrote first

Before the first candidate, write what a 1, 2, 3 and 4 look like for each of the four attributes. Doing this afterwards means scoring against the candidates you happened to see. See how to write an interview scorecard.

Where Interviewer Mode fits

Disclosure: we make CoPilot Interview, which includes Interviewer Mode for the hiring side and a real-time assistant used by candidates. We have an interest in you using the first, and our view of the second is that interviews should be designed to measure something an assistant cannot fake. Weigh the advice below accordingly.

Frequently asked questions

What should I look for in a coding interview?

How the candidate decomposes an unfamiliar problem, whether they verify their own work before you point at a bug, how they respond when stuck, and whether the code is readable enough to review. Reaching the optimal solution matters far less than the reasoning that gets them most of the way.

Should a candidate finish the problem in a coding interview?

Calibrate so most strong candidates do not. If finishing is achievable, completion becomes the score and you learn less about reasoning. An unfinished solution with clear decomposition and self-testing is a stronger signal than a memorised complete one.

Is it okay to give hints in a coding interview?

Yes, but decide the hints in advance and give them in the same order to everyone. Unplanned hinting is the main reason two interviewers reach different conclusions about the same candidate — one gave a guided tour and the other did not.

Should I let candidates look things up in a coding interview?

Yes for syntax and library signatures, and say so at the start. Nobody writes production code without a reference, and testing recall rather than reasoning just adds noise. State the rules explicitly so the candidate is not guessing at what is allowed.

How do I score a coding interview fairly?

Use the same problem for every candidate at a level, write the rating definitions before the first interview, note evidence during the round rather than afterwards, and plan your hints in advance. Fairness here comes from consistency, not from choosing a kinder problem.