What are the driver and navigator roles in pair programming, and why rotate them?
answer
- Two people, two different jobs
- One holds the keyboard
- The other works a level up
- Swap on a timer or per test
- Never swapping creates an audience
basics
~20 sThe driver types and handles the mechanics. The navigator stays a step ahead — unhandled cases, naming, the remaining plan — and keeps talking. Rotating the keyboard on a timer keeps both people active and able to explain the change.
solid answer
~50 sPair programming puts one change in front of two people who hold two different jobs at the same moment. The **driver** has the keyboard and works at the level of the current line and the next few minutes. The **navigator** works one level up: which case is still unhandled, whether the name says what the function actually does, whether this is still the approach the two of them agreed on. Both talk continuously — a silent pair is two people doing one person's work. **Rotation** is what keeps the split honest: a fixed timer, or ping-pong, where one writes a failing test and the other makes it pass and then writes the next failing test. Without rotation the more confident person drives the whole session and the other becomes an audience, which loses the main payoff: two people who can each change that code next week.
code
pseudocode · 6 linesloop until the case list is empty:
A writes one failing test
B makes that test pass
B writes the next failing test
A makes that test pass
both refactor while all tests are greengo deeper
Be ready to name both seats and say what each one is thinking about, and to say plainly that rotating the keyboard is part of the practice rather than an optional courtesy.
Explain the mechanics: how a rotation rhythm is enforced, what ping-pong looks like against the test cycle, and why a navigator who reports formatting problems has stopped doing the job the tools cannot do.
An interviewer expects you to diagnose a pair that has gone wrong — one driver all session, silence, a missing agreed plan — and to describe the correction you would make in the moment rather than afterwards.
Own the framing that rotation exists to spread the ability to change the code, not to be fair. Be ready to say how you would set a team default for it without turning a working practice into a mandate people perform.
## Two people, two jobs, one change Pair programming is not "two people looking at a screen". It is a deliberate division of one task into two roles that are held simultaneously by two people and swapped on a rhythm. The **driver** holds the keyboard. Their attention is necessarily tactical: the expression being typed, the call being wired up, the shape of the next few lines. Writing code consumes working memory at the mechanical level, and that is exactly why the second seat exists. The **navigator** deliberately does not type. Their attention sits one level above the keystrokes: - Which cases from the agreed list are still unhandled? - Is the thing being built still what we decided to build ten minutes ago? - Does this name describe the behaviour, or the implementation we happened to pick? - Is there a simpler shape that removes this branch entirely? - Should this be a test first, so we can see it fail for the right reason? A navigator who spends the session pointing out a missing bracket has taken the driver's job and done it worse — the editor already reports that. The navigator's value is the thinking the driver cannot afford while typing. ## Talking is the mechanism The transfer only happens out loud. The driver narrates intent ("I'm going to make this return early when there's no slot"), the navigator responds at the level of intent ("before that — what happens for a request that arrives while the previous one is still holding the slot?"). Two people typing in companionable silence on one machine have paid twice for one person's understanding. One named variant makes the talking mandatory: in **strong-style pairing**, the rule is that an idea has to travel from the navigator's head through the driver's hands. The person who knows the area navigates and the person who does not drives, which forces the knowledge across instead of letting the expert simply do it. ## Why rotate Rotation is not politeness, it is the control that stops the pair collapsing into a demonstration. 1. **It prevents the audience effect.** The moment one person keeps the keyboard for an hour, the other stops predicting and starts watching. Watching feels like learning and is not: the friction of actually writing the thing is where the gaps show up. 2. **It forces articulation.** At the swap the outgoing driver must state where things stand and what comes next. If they cannot, the pair has drifted and just discovered it cheaply. 3. **It refreshes attention.** Both seats are demanding in different ways; the navigator seat decays after a stretch, and the swap resets it. 4. **It spreads the change.** Two people who each drove part of it can each modify it later. One person driving all session leaves the same single point of knowledge you started with. Common rhythms are a short fixed interval enforced by a timer, or ping-pong tied to the test cycle. The interval matters less than having one at all; teams tune it and often find that a longer interval quietly reverts them to one driver. ## A concrete session Two engineers on a hospital appointment scheduler add a rule that a follow-up must be offered inside 21 days of the referral. The newer engineer drives. The navigator, freed from typing, notices that a referral recorded at 23:52 on the last day of a month lands on a different calendar day once the clinic's local offset is applied, and adds it to the case list rather than interrupting the current line. Nineteen minutes in, the timer goes; the outgoing driver tries to summarise the plan and cannot name what the half-written function is for. That failure to summarise is the useful signal — the pair had stopped agreeing on the goal several minutes earlier, and they recover it in thirty seconds instead of in a review days later. ## What good and bad look like Good: continuous low-level conversation; the keyboard moving on a rhythm; disagreements resolved by writing the case down and trying it; both people able to describe the change at the end. Bad: the experienced engineer drives all session while the other nods; the navigator nitpicking whitespace; either person answering messages on a second screen; no plan agreed at the start, so the navigator has nothing to navigate against; a session run so long that both are exhausted and the last hour produces work neither would defend. ## What this is not Pairing is synchronous co-creation while the change is being made. Reading and critiquing a change that is already finished is a different activity with different economics, and pairing does not automatically make that unnecessary.
- What does a navigator add that an editor's warnings and an auto-formatter cannot?Tooling reports syntax, style and a fixed set of known-bad patterns. A navigator supplies intent: whether the case list is complete, whether the abstraction matches the problem, whether the name will still make sense to a reader who lacks today's context, and whether the pair is still building the thing they agreed to build. None of that is mechanically checkable, which is why a navigator who spends the session on formatting has swapped a job only they can do for one the tools already did.
- How can you tell that a rotation interval has been set too long?The clearest signal is at the swap: the outgoing driver cannot state in a sentence where things stand and what comes next, or the incoming driver has to re-read the last twenty minutes of work before they can type. Other symptoms are the navigator having started reading something unrelated, and one person having produced most of the session's code. Shorten the interval and the summary at each swap becomes cheap again.
- Does pairing make sense when one person knows the area far better than the other?Yes, and it is one of the strongest cases for it — but the seating should be deliberate. Put the person who knows less on the keyboard and let the expert navigate, so ideas have to be expressed and then executed by the newcomer rather than silently performed by the expert. It is slower for that session and it is the difference between the newcomer having watched the change and being able to make the next one.
Rally driving: one person steers for the corner they are in, the co-driver reads the notes for the corner after that. Swapping seats stops either from forgetting how the other job feels.
saying these in an interview costs you the question
- The experienced engineer drives the whole session while the other watches
- Says the navigator's job is spotting typos and formatting slips
- Calls two people working silently on separate machines a pair
- Refuses to rotate because swapping breaks the driver's flow
- Treats the navigator as a supervisor grading the driver
- Claims pairing needs no agreed plan because talking will produce one