Forty minutes into the session he had a working solution, a clean one, and the distinct sense that it had gone badly.
He had been given a repository, a failing test, and an engineer called Dan who said "I'll be pairing with you — treat me like a teammate." So he had opened the file, gone quiet, and fixed it. Twice Dan had said things like *"I wonder if the issue is in the parser"*, and both times he had said "mm" and carried on reading the stack trace. He found it in the end, on his own, and he was quietly pleased about that.
The feedback said: *"Solved it. Didn't really pair."*
Which sounds like a contradiction until you notice what the round is for. In every other coding round the interviewer is an examiner scoring your output. In a pairing session they are a colleague simulating a Tuesday. They are not trying to find out whether you can fix the bug — the round before this one already established that. They are finding out what it costs to work next to you.
Once you see that, the specific behaviours stop being mysterious.
How it differs from the rounds around it
The confusion is understandable, because four different rounds all involve writing code:
- The online assessment — timed, auto-graded, no human present. Optimise for hidden test cases. Our online coding assessments guide covers it.
- The take-home — untimed, async, read later by a human. Optimise for structure and judgment. Our take-home assignment tips guide covers it.
- The machine coding round — a solo two-to-three hour build, reviewed afterwards. Optimise for a working, extensible design. Our machine coding round guide covers it.
- The pairing session — 45 to 90 minutes, a real repository, an engineer beside you the whole time. Optimise for the collaboration, because that is the variable this round exists to measure.
Same skill, four different scoring functions. Bringing the assessment mindset (heads-down, silent, output-only) into a pairing session is the single most common way strong engineers fail it.
The six things being scored
Do you say what you are about to do? Not narrate every keystroke — announce direction. *"I'm going to reproduce it with a failing test first, then work backwards."* One sentence before a block of work. It lets your partner disagree cheaply, which is the entire point of pairing.
Do you take hints? This is the one that sank the engineer above. When an interviewer says *"I wonder if it's in the parser"*, that is not idle musing — it is a deliberately softened instruction. Taking it immediately is not losing; it is the behaviour they are testing for. Ignoring a hint twice reads as someone who will burn a sprint rather than accept input.
What do you do when you're wrong? Everyone goes down a wrong path. The score is in the recovery: how fast you drop it once evidence arrives. "You're right, that's not it — let me back out" is a strong answer. Defending a dead approach for another ten minutes is the weak one.
Are your silences announced? You are allowed to think. You are not allowed to disappear. *"Give me twenty seconds to read this function"* costs nothing and converts an uncomfortable void into a normal working pause. Unannounced silence is the most common reason feedback says "hard to follow."
Do you ask before you assume? A pairing task usually has at least one deliberately underspecified requirement. Asking is the pass condition; guessing silently and building the wrong thing is the fail.
How often did they have to rescue you? Interviewers keep a rough count of the times they stepped in to stop you stalling. Not fatal — this is a scale, not a gate — and it is the number that most directly predicts what a week with you feels like.
What the session usually looks like
Formats vary, and the common shapes are:
- Debug an existing failing test in a repository you have never seen. Most common, because it tests navigation of unfamiliar code rather than recall.
- Extend a small feature — add a field, handle a new case, refactor one function.
- Driver/navigator swaps, where you type for a while and then they do. Some teams do this explicitly; when they type, your job is to direct, which is its own test.
You will usually be allowed your own editor, documentation, and often a search engine. Ask what the rules are on the first minute rather than guessing — including whether AI assistants are permitted, since policies differ and assuming is the risky option.
The first five minutes decide the tone
- Ask what "good" looks like. *"Should I prioritise getting it green, or do you want production-quality as I go?"* Genuinely different tasks, and interviewers rarely volunteer which they want.
- Read out loud what you understand the task to be. Cheap correction if you have it wrong.
- Say how you like to work. *"I usually reproduce before I read — is that alright with you?"* This is a normal pairing negotiation and signals you have actually paired before.
- Get the code running first, if it isn't. Do not start reasoning about a system you haven't seen execute.
The behaviours that quietly cost you
- Narrating everything. Over-correcting on "think out loud" produces a keystroke commentary that is exhausting to sit through. Announce direction and decisions, not motions.
- Apologising continuously. One acknowledgement is fine; a running apology track makes the session about reassuring you.
- Refusing to use the tools you actually use. If you would search for the exact signature at work, do it here. Pretending to have memorised an API is a worse signal than looking it up confidently.
- Going quiet when stuck. The one behaviour to eliminate entirely. Say *"I'm stuck — here's what I've ruled out"*, which converts silence into information and usually earns a hint. Our how to recover from blanking guide covers the sharper version of this.
- Treating the interviewer as furniture. They said "treat me like a teammate" and they meant it.
Practising for it honestly
This round is genuinely harder to rehearse alone than any other, because the thing being scored only exists when a second person is in the room.
What does help: pair with a friend on a real bug and ask them afterwards how often they wanted to interrupt. Work in an unfamiliar open-source repository under a timer to build the navigation muscle. Practise saying "I'm stuck, here's what I've ruled out" until it comes out without effort — under pressure, people default to silence unless the sentence is automatic.
Where the usual advice comes up short
"Think out loud." The most-repeated advice about this round and the least calibrated. It produces narration when what scores is stated intent and announced silence.
LeetCode. Builds the underlying skill and none of the collaboration. Many people arrive at a pairing session having practised exclusively for a round that no longer applies.
Reading about pair programming. The XP literature is genuinely good on driver/navigator mechanics. It describes established colleagues, not a stranger assessing you in 45 minutes, so translate with care.
Generic ChatGPT prompting. Useful for drilling the underlying problems. It will not tell you that you went quiet for four minutes, which is the actual failure mode.
Greenroom. Straight about the fit: Ari, the AI interviewer, does not pair-program with you — this round is spoken *and* hands-on, and Greenroom covers the spoken half. What it does train is the reflex this round rewards most: saying where you are, out loud, while you are still uncertain, instead of going silent until you have an answer. Honest tradeoff: for the hands-on half, a human partner and an unfamiliar repository beat any tool.
The one-line version
Announce your direction before you type, take every hint immediately, abandon wrong approaches out loud and fast, say "give me twenty seconds" instead of going quiet, and ask about the underspecified requirement — because the round is measuring what a week of working with you costs, not whether you could have solved it alone.
Frequently asked questions
What is a pair programming interview?
A round of roughly 45 to 90 minutes in which an engineer works alongside you on a real task, commonly debugging a failing test in a repository you have not seen before, extending a small feature, or swapping between driver and navigator roles. Unlike an online assessment or a take-home, a person is present throughout, and the round exists to assess collaboration rather than raw output. You are usually allowed your own editor, documentation and search.
How is pair programming different from a normal coding interview?
The scoring function is different. An online assessment is graded by hidden test cases with no human involved, a take-home is reviewed asynchronously for structure and judgment, and a machine coding round is a solo build assessed afterwards. A pairing session measures what working with you costs — whether you state your intent before acting, take hints, abandon wrong approaches quickly, and keep your partner informed. Bringing a silent, heads-down assessment mindset into it is the most common way strong engineers fail.
Should I take hints in a pair programming interview?
Yes, and quickly. When an interviewer says something like 'I wonder if the problem is in the parser', that is a deliberately softened instruction rather than idle speculation. Acting on it immediately is the behaviour being tested, not a concession. Ignoring hints repeatedly tends to read as someone who will spend a sprint on a wrong path rather than accept input from a colleague, which is precisely the risk the round is designed to surface.
What should I do if I get stuck during a pairing session?
Say so, and say what you have ruled out. A sentence such as 'I'm stuck — I've confirmed it isn't the input parsing, so I think it's in the transform' converts silence into useful information and usually prompts a hint. Going quiet is the single most damaging behaviour in this round, because your partner cannot tell whether you are thinking productively or lost. Announcing short pauses — 'give me twenty seconds to read this' — is normal and costs nothing.
Can I look things up during a pair programming interview?
Usually yes, and it is worth confirming in the first minute along with any policy on AI assistants, since teams differ and assuming is the risky choice. If you would search for an exact method signature at work, doing the same here is a better signal than pretending to have memorised an API. What matters is that you look things up confidently and stay in dialogue while doing it rather than disappearing into a browser.
How do I prepare for a pair programming interview?
Practise the collaboration rather than only the coding. Pair with a friend on a real bug and afterwards ask how often they wanted to interrupt you. Work inside an unfamiliar open-source repository under a timer to build the skill of navigating code you did not write. Rehearse saying 'I'm stuck, here's what I've ruled out' until it is automatic, because under pressure most people default to silence unless that sentence requires no effort.