# Pair programming interview preparation: code together out loud A pair programming interview evaluates how you collaborate while you code. Narrate your reasoning before typing, confirm the task and environment first, take corrections as information, keep the interviewer involved at decision points, and recover from errors openly. Rehearse thinking aloud while implementing, because silence reads as disengagement even when the code is right. About 6 min read. ## On this page - [Understand what pairing is being evaluated](https://preprole.com/guides/pair-programming-interview-preparation#format) - [Narrate before you type](https://preprole.com/guides/pair-programming-interview-preparation#narrate) - [Set up the session before the clock starts](https://preprole.com/guides/pair-programming-interview-preparation#environment) - [Take the interviewer's input as information](https://preprole.com/guides/pair-programming-interview-preparation#input) - [Recover from errors openly](https://preprole.com/guides/pair-programming-interview-preparation#mistakes) - [Worked example: the first five minutes of a session](https://preprole.com/guides/pair-programming-interview-preparation#worked-example) - [Rehearse collaboration, not just solving](https://preprole.com/guides/pair-programming-interview-preparation#practice-plan) ## Understand what pairing is being evaluated A pair programming interview puts you and an interviewer on a shared editing session, a shared screen, or one keyboard, working a real problem together. Some formats have you drive while the interviewer navigates; others reverse roles or swap. Confirm the format, the environment, and whether tests are available before the session, and ask whether you can use your usual editor setup. What is being measured is collaboration under real working conditions: do you communicate your reasoning, incorporate input, verify as you go, and recover from mistakes without collapsing? The code matters, but the working relationship is the interview. A silent, technically correct session usually evaluates worse than a slightly slower collaborative one. ## Narrate before you type The single highest-leverage behaviour is saying what you are about to do before you do it: 'I am going to check the empty-input case first because the loop assumes at least one element.' That narration lets the interviewer follow, correct, and collaborate. Going quiet to concentrate reads as disengagement, and disengagement is what this format exists to detect. Narration is not a monologue. Pause at decision points and check in: 'I see two ways to handle this, do you have a preference?' You are practising the behaviour of a good colleague, not performing a lecture. Interviewers consistently reward candidates who treat them as a navigator rather than an audience. - Intent: say what you are about to change before changing it - Decision points: invite input at real forks, not ceremonially - Verification: announce what you are checking and what result you expect - Recovery: name mistakes when you find them and say the fix ## Set up the session before the clock starts Spend the first minutes confirming the environment: can you run the code, is there a test runner, what is already provided, and what the interviewer expects as output. Candidates who discover a broken setup fifteen minutes in lose time and composure they did not need to spend. Also confirm the task itself. Restate the goal in your own words and ask about the edges that shape it: input constraints, expected behaviour on invalid data, and whether refactoring an existing codebase or writing fresh code is the intent. Clarifying aloud is collaborative behaviour, not hesitation. ## Take the interviewer's input as information When the interviewer suggests a different direction or catches a bug, treat it as data. Say what the suggestion changes and adapt, or explain your reason for continuing the current approach and check whether that is acceptable. Both are defensible; ignoring the input or abandoning your reasoning at the first comment are not. Disagreement is normal in real pairing and interviewers sometimes probe how you handle it. The evaluated behaviour is the reasoning: 'I chose this because the requirement is X, but your approach handles Y better, so let us use yours.' Holding a position with a stated reason and yielding to a better argument are both strong; stubbornness without a reason is the failure. ## Recover from errors openly You will write a bug or go down a dead end. The interview is watching what happens next, not whether it happens. Say what you found, what it means, and what you will do: 'That assumption was wrong, the sort changes the order we need, so I am going to build the result differently.' Do not quietly rewrite or hope the interviewer did not notice. An unacknowledged error that gets caught reads much worse than an acknowledged one you fix. Debugging aloud, reading the actual error, and forming a hypothesis before changing code are all visible professional skills. ## Worked example: the first five minutes of a session A strong opening sounds like this: confirm the task in your own words, ask about the environment, state your plan, and start. 'So the goal is to make this endpoint return deduplicated results. I see the tests directory has a failing test I can run; I will get that passing first, then check the edge cases with you. Anything you would prioritise?' Notice what that does: it confirms shared understanding, surfaces a verification path, states an order of work, and invites the interviewer in. Every part of that is practised, not improvised. Rehearse your own opening the same way you rehearse an introduction. > The task is to return deduplicated results from this endpoint. I am going to run the existing tests first so we both see the same failure, then implement the smallest change that passes and check the empty and duplicate-heavy inputs with you before we call it done. ## Rehearse collaboration, not just solving Practice that omits the communication half misses the point of this format. If you can pair with a colleague or friend, do it: the awkwardness of narrating fades with repetition. If not, narrate your own practice sessions aloud and review where you went silent or stopped checking in. After each session, note where communication broke down: did you go quiet while debugging, skip confirming the task, or push through an approach the other person questioned? Fix one communication behaviour per practice run. The coding is already covered by your other preparation; this rehearsal targets what pairing adds. ## Frequently asked questions ### What if the interviewer drives and I navigate? Navigating is a real skill: describe intent at the level of what to achieve, not keystrokes, check the driver understands before moving on, and read the code as it appears. Practise giving directions that survive imperfect implementation, because that is what the role evaluates. ### Is it okay to think in silence for a moment? Yes, as long as you say so. 'Give me thirty seconds to think through the edge cases' keeps the interviewer informed. Unannounced silence reads as disengagement; announced thinking time reads as focus. ### What if my coding style differs from theirs? Match the existing codebase or the interviewer's stated conventions where reasonable and say why you are doing it. Adaptability to team conventions is itself part of what a pairing session evaluates. ### Do pair interviews always involve writing code? Mostly, but some include debugging an unfamiliar codebase, reviewing changes, or designing together. Confirm the format. The communication behaviours this guide covers apply to all of them. ## Practise the next answer Use a Coding Mock Session to rehearse narrating your reasoning while you work through a problem, which is the core skill a pair programming interview evaluates. Where a session includes the Code Pad, the AI Interviewer reads it but never executes code, so run implementations in your own environment when checking correctness. Practise for your job: https://preprole.com/setup ## Sources and scope Employer sources describe their own processes, which may change. The exercises and illustrative examples are PrepRole editorial guidance, not employer questions or hiring criteria. - [Atlassian: engineering interview handbook](https://www.atlassian.com/company/careers/resources/interviewing/engineering) ## Related guides - [Prepare the problem-solving portion](https://preprole.com/guides/coding-interview-preparation) - [Rehearse explaining your decisions](https://preprole.com/guides/technical-deep-dive-interview) - [Manage the pressure of working live](https://preprole.com/guides/interview-nerves) AI feedback can be wrong. A practice Verdict is not a hiring decision.