Pair Programming Interviews: What They Grade When You Are Not Alone

The mistake that costs the most

Most candidates arrive assuming the interviewer is a judge who happens to be in the room, so the correct behaviour is to perform competence and avoid revealing gaps. Under that assumption you do not ask questions, because asking looks like not knowing. You do not think out loud, because half-formed thoughts look unpolished.

That is exactly backwards. In a pair round the interviewer is a colleague for forty minutes, and the thing being measured is what working with you is like. Silence from you is not composure — it is a person who is hard to pair with.

Use them, out loud

A pair session gives you something a solo round does not: a second brain who already knows the answer. Candidates who use it well do three things repeatedly.

They check assumptions before building on them. “I am assuming these IDs are unique — is that safe?” Ten seconds, and it prevents twenty minutes in the wrong direction.

They offer a choice instead of guessing. “I can do this with a dictionary or by sorting first. Sorting is simpler to read, the dictionary is faster. Which do you care about here?” That is not indecision — it is how the work actually gets done.

And they take hints without arguing. When someone says “what if the list is empty?”, the answer is not a defence. It is “good catch” and a guard clause.

Typing is not the work

A common pattern: the candidate types steadily for thirty minutes, produces something that almost works, and gets negative feedback. The interviewer could not follow the reasoning, so there was nothing to evaluate except the artefact — and the artefact was incomplete.

The opposite pattern scores better. Less code, more narration, frequent checkpoints. “Right, that handles the main path. Before I go further — do you want me to deal with malformed input, or is the happy path enough for now?”

That question is doing real work. It shows you know the case exists, it respects the clock, and it makes the interviewer a participant in scope decisions rather than a spectator.

When you disagree with them

It happens: the interviewer suggests something you think is wrong. Both extremes lose. Silently complying reads as having no opinion. Digging in reads as someone who will be exhausting on a team.

The move is to make the disagreement concrete and cheap. “I think that breaks when the input is already sorted — can I try it on that case?” Now it is a two-minute experiment instead of an argument, and whoever turns out to be right, you have shown how you resolve technical disagreements. Which is very close to the actual question being asked.

The last five minutes

Most candidates spend the final stretch typing faster, hoping to finish. Unfinished is normal and rarely fatal; unexplained is worse.

Better use of the time: stop, and say where you are. “This works for the standard case. If I had another ten minutes I would handle duplicates, which I would do by keeping a seen-set here.”

You have now demonstrated that you know what is missing and how you would finish it — which is most of what finishing would have proved anyway.

What they are writing down

Interviewers in pair rounds usually score against a short rubric, and it is rarely about the algorithm. The recurring items are communication, collaboration, handling of feedback, and debugging under pressure.

Communication is not fluency. It is whether the person watching could predict your next move. If they can, you are legible; if they cannot, everything you do looks like guessing even when it is not.

Handling feedback is the one candidates underestimate. The interviewer will interrupt at least once, often with something you already knew. What gets recorded is whether the interruption made you defensive, and how quickly the conversation returned to the work.

Debugging is the part they hope to see

A pair round almost always includes a moment where the code does not do what you expected. That moment is not a setback in the interview — it is frequently the point of it.

The weak version is changing things until the output looks right. The strong version is forming a hypothesis before touching anything: “The count is one too high, and the loop runs from zero to n inclusive — I think that is the boundary. Let me check with n equals one.”

Say the hypothesis, then test it. Two sentences, and you have shown a method rather than a reflex.

Setting up the first two minutes

Before writing anything, do three things out loud: restate the problem, confirm the input shape, and say what you will do first. It takes ninety seconds and it changes the tone of the whole session.

It also gives the interviewer an early chance to redirect you. They usually will, if you let them — and a redirect at minute two is free, while the same redirect at minute twenty costs you the round.

If the problem statement is ambiguous, that ambiguity is usually deliberate. Asking about it is not a delay; it is the first thing being tested.

Where a copilot fits

Interview Copilot follows the round in real time and puts a structure on your screen while the other person is still talking — what the question is actually asking, the constraint that matters, and the trade-off worth saying out loud. Not a script to read: a scaffold you speak from, in your own words.

Read next