Two roles, evaluated differently
A pairing interview conventionally splits into two explicit roles that you and the interviewer (or you and another candidate, in some formats) alternate between: the driver, who has the keyboard and is writing code, and the navigator, who is reading, thinking ahead, catching mistakes, and directing at a higher level without touching the keyboard. Interviewers evaluate these differently, and candidates who prepare only for driving — the part that feels like "real coding" — are missing half the round. Navigating well is a distinct, practiced skill, not a passive default state you fall into when it's not your turn to type.
Driving well: narrate, don't disappear into the keyboard
As driver, the core expectation overlaps heavily with Working Under Observation: narrate what you're typing and why as you go, rather than going quiet and producing a finished chunk of code for your navigator to review after the fact. A pairing-specific addition: actively invite your navigator's input at natural pause points ("does this approach seem right so far, or is there something I'm missing?") rather than only reacting when they interject — treating the navigator as a resource to consult, not an observer to tolerate, is itself part of what's being evaluated.
Navigating well: this is not the easy role
The instinct to relax when you hand over the keyboard is exactly backwards — a good navigator is actively tracking the bigger picture the driver's local focus makes it easy to lose: is this approach going to work for the whole problem, not just the next five lines? Is there an edge case the current code doesn't handle? Is the driver about to spend ten minutes on something that could be simplified? Concretely, good navigating looks like: catching a typo or off-by-one before it becomes a debugging session, asking "what happens if this list is empty?" while the driver is still writing the loop rather than after it fails, and suggesting a direction change early and specifically rather than vaguely ("I think this might not handle the empty case" beats "something feels off"). Interviewers explicitly watch for navigators who go silent — it reads as either disengagement or an inability to track code you're not directly writing, both bad signals.
Switching roles is itself part of the round
Most pairing interviews swap driver and navigator at least once, often at a natural checkpoint (a feature boundary, a test passing). Handling the swap smoothly — briefly summarizing where things stand for whoever's picking up the keyboard, rather than assuming context transfers silently — is a small habit that reads as genuine collaboration experience rather than two solo turns taken in sequence.
Disagreeing without stalling
Pairing rounds sometimes deliberately include a moment where driver and navigator have different opinions about the right approach — this is often intentional, testing how you handle a real disagreement under time pressure. The strong pattern: state your reasoning briefly, listen to the counter-reasoning, and default to a quick, low-cost way to resolve it rather than a prolonged debate — "let's try your approach first since it's the smaller change, and I can always suggest mine if it doesn't pan out" resolves the disagreement and keeps the clock moving, which matters more here than being provably right about a minor implementation choice.