A lot of teams that have soured on traditional live coding have moved to pair-programming interviews instead. The format is intuitive. Sit beside the candidate, work together on a problem, chat as you go. The argument for it is that it looks a lot more like the actual work of engineering than a timed algorithm puzzle does.

That argument is partly right. Pair-programming interviews are better at some things than live coding is. They're also worse at others, and they have their own failure modes that are worth naming before you put one in the process.

What pair-programming interviews are good at

Seeing how a candidate communicates while thinking. A real pair session involves negotiation. The candidate has to say what they're about to do, respond to your suggestions, push back or take them on. That's a skill that matters on the job. It doesn't really show up in any other part of the process.

Seeing how they respond to being slightly off-balance. A pair-programming session inherently has moments where the candidate has to decide whether to defer to you, disagree with you, or work around you. That dynamic mirrors the real daily work of collaborating with a colleague more senior than you, and the candidate's reaction to it is diagnostic in a way that few other rounds are.

Watching them use their environment. Pair-programming usually gives you a view into how the candidate works their own tools. How do they check the types? How do they look up documentation? Do they read the error message carefully, or skim it and rerun the command? Watching this in action surfaces habits that matter at work and don't appear in any artefact.

Where pair-programming interviews quietly fail

The biggest failure mode is that pair-programming often becomes live coding with a friendlier-sounding name. The interviewer sits beside the candidate "pairing," but actually watches them solve a problem alone, intervening only when they're stuck. The candidate knows this. They treat the session as live coding, and all the same stress responses kick in.

A real pair-programming session has the interviewer contributing, not observing. That's much harder to run well. It requires the interviewer to have a specific thing they want to work on together, to know when to contribute code and when to step back, and to be willing to let the candidate take the lead on decisions the interviewer might make differently. Most processes don't train interviewers for any of this.

The second failure mode is that pair-programming rewards a very particular style of engineer: the one who is comfortable thinking out loud with a stranger. Some of the strongest engineers you'll meet are quieter, especially in a high-stakes first meeting with a new person. They do their best work after they've had time to read a problem, form an opinion, and come back to the conversation. A pair session gives them none of that. What you see is their worst thirty minutes, not their best.

The third is calibration. Pair sessions are hard to calibrate between interviewers, because the interviewer is part of the signal. One interviewer pairs well and surfaces good work from everyone. Another pairs poorly and surfaces mediocre work from the same candidates. The session measures the pair, not just the candidate, and that bleeds into every debrief that follows.

When to run one anyway

Pair-programming is probably the right round when all of the following hold:

  • You're hiring for a role where daily collaboration involves a lot of synchronous working-alongside: coaching, incident response, some kinds of platform work.
  • The interviewers who'll run it are willing to be trained on pairing specifically, not just on interviewing.
  • It's not the only technical round in the process. You still need a round that doesn't penalise quieter candidates.

If any of those aren't true, the session is probably not earning its keep, and you'd get better signal from a take-home challenge — not a code-gen exercise, but one that probes how the candidate thinks — plus a structured follow-up.

A smaller, cheaper version

One variation that works well for teams that don't want to commit to a full pair round: give the candidate the problem thirty minutes before the session starts, with no interviewer present. They spend the time reading it, sketching a plan, maybe writing a few notes. Then the session begins.

What you get is a conversation about a problem the candidate has actually thought about, rather than one they're encountering cold. The interviewer can still pair on specific parts. The candidate gets to show their work at their best rather than their most flustered. And the session surfaces reasoning, not reflexes.

This format tends to work better. The candidate shows up with an opinion. The conversation starts at a useful depth. The interviewer doesn't have to spend the first fifteen minutes watching someone read a prompt.