What is a pair programming interview?

A pair programming interview gives you an existing repository you did not write, a small feature or bug ticket, and an interviewer who plays a teammate rather than a silent examiner. You are expected to ask them questions, read the surrounding code, and add your change in the style the project already uses. There is no hidden grader, only their judgement of how you work.

What should I do in the first four minutes of a pair programming interview?

Keep your hands off the keyboard. Read the ticket back in your own words and name the condition that means it is done, skim the file tree rather than the files, trace one existing feature that resembles the ticket from entry point down to the data, open a test file and ask how tests are run, then say which files you plan to change and ask whether that matches how they would do it.

Is the interviewer really acting as a teammate, or is it still a test?

Both, and using them is the behaviour they want to see. They will genuinely answer questions, point at files and explain context, because that is what a colleague would do in your first week. They are also writing notes throughout. Ask about conventions, constraints and intent, not about things you could read for yourself in ten seconds.

How much of the codebase should I read before I start typing?

Enough to place your change, not the whole project. In practice that is the entry point, the one existing feature closest to the ticket, and a test file. Trace a single request or a single render from the top down to the data and back. Reading more burns the clock, and reading less means your code lands in the wrong layer.

Do I have to write tests in a pair programming interview?

Decide out loud rather than asking permission. Many interviewers will not expect a full suite in the time available, but adding one focused test for the case you know is risky reads far better than saying you would write tests if there were more time. Name the layer you are testing and the cases you are deliberately skipping.

What should I do if I get stuck during a pair programming round?

Say what you are stuck on within about thirty seconds. Silence is the real failure mode, because the interviewer cannot tell whether you are thinking or lost. Naming the decision you are caught between and asking for a nudge is ordinary teammate behaviour, and how you recover is usually a larger part of the score than the stall itself.

Pair Programming Interview Tips: What to Expect in a Real Repo

Expect a repository you have never opened, one small ticket against it, and an interviewer who behaves like the person who sits next to you rather than an examiner watching in silence. They are still taking notes. What those notes measure is whether working with you next Tuesday would be cheap or expensive. Most of that is decided in the first four minutes, and you should spend them reading and talking, not typing.

What the format actually is

The setup is usually a small service or app, somewhere between a few hundred and a few thousand lines, running in a shared editor, a Codespace, a sandbox link, or a repo you cloned an hour earlier. It is often deliberately imperfect. Expect one oversized file, an inconsistent naming convention, a helper nobody uses, and a test suite with something skipped. That mess is not an accident, it is the material you are being asked to work inside.

The ticket is small on purpose. Common shapes:

Add one field end to end, through the model, the endpoint and the view.
Add a second filter or a sort to a list endpoint that already has one filter.
Fix a test that was left red, where the bug is real and one layer away from where it fails.
Handle an edge case in an existing parser, importer or formatter.
Add one transition to a small state machine, or one new event type to a handler.

Then comes the line almost every interviewer says in some form: treat me as a teammate who knows this code, or, I inherited this too, ask me anything. That is a real offer and it is also part of the exercise. Candidates waste it in two opposite ways. Some never ask anything, believing questions look weak, and spend eight minutes deducing something a colleague would have answered in five seconds. Others treat the interviewer as a hint dispenser and ask what a function returns when the function is nine lines long and on screen. Ask about intent, conventions and constraints. Read the things you can read.

The first four minutes, before you touch the keyboard

This is the part you can rehearse and the part almost nobody rehearses. Say all of it out loud. Your hands stay off the keys except to navigate.

0:00 to 0:45, restate the ticket and name the done condition

Say the ticket back in your own words, then say what would make it finished. Then ask the one scoping question with the largest blast radius, usually about how your change interacts with something that already exists. Getting this wrong is the most expensive mistake available, because it is discovered at minute twenty five.

0:45 to 2:00, read the tree, not the files

Look at the folder structure and the entry point only. Say what the layout implies before you verify it. Routes, services and a data folder means your change is probably three small edits rather than one clever one. A single flat folder of twenty files means convention will have to come from reading a sibling. You are placing your change, not learning the project.

2:00 to 3:15, trace the nearest sibling feature top to bottom

The highest value move in the whole round. Find the existing feature that most resembles the ticket and follow it from the entry point down to the data and back. Search for one distinctive identifier and read every place it appears. You now have the shape of your diff, in this project's style, without inventing anything.

3:15 to 4:00, open a test, then state your plan

Open the test file covering that sibling and ask two things: how do I run these, and how long do they take. If the suite runs in seconds you will lean on it constantly. Then say your plan as three or four concrete edits, name the files, and ask whether that is where they would put it. Cheap to say, and it catches the case where validation lives in a schema file you have not seen.

At the four minute mark you have written no code, and you know the shape of the change, the conventions you are matching, and how you will check yourself. The candidate who started typing at thirty seconds is usually putting logic in the wrong layer right now, and will move it later under time pressure while explaining why.

A worked example: add a status filter to an orders endpoint

Small Node service. Folders are routes, services, db and tests. The ticket says orders can already be filtered by customer, now add filtering by status. Here is the actual sequence, with the sentences said out loud.

Restate and scope. "So a request to the orders endpoint with a status parameter returns only orders in that status. Done means it combines with the existing customer filter and still paginates correctly. Is that right?" That one sentence forecloses the classic failure, a second filter that quietly replaces the first.
Ask the edge case now, not at minute thirty. "What should happen for a status value that is not valid, a rejection or an empty list?" If they answer with "what do you think", pick one, give a reason in a sentence, and move on. Rejection is usually the better default, because an empty list hides typos from the caller.
Read the tree, forty seconds. "Routes, services, db. I would expect no SQL in the route layer and no request objects in the db layer, so this is likely three small edits. Let me check that assumption rather than trust it."
Trace the sibling. Search for the customer filter identifier. It appears three times: the route reads it from the query string, the service puts it into a filter object, the data layer turns it into a condition. Read all three. Note how validation is written, whether the filter object is built with defaults, and what the existing error shape looks like.
Open the test for that filter. There is a case asserting the customer filter narrows the result set. Ask how the suite is run. A test you can copy and modify is worth more than any amount of confidence about your own code.
State the plan and get agreement. "Parse and validate status in the route the way customer is parsed, pass it through the filter object, add one condition in the data layer, then copy the existing filter test with status swapped in and add one for the invalid value. Does that match how you would do it?"

Now type. Run the tests after the first edit, not after the last. If you finish early, do not add features nobody asked for. Say what you would do next and why you stopped, which is a senior habit and takes twenty seconds.

Narrating, so it sounds like thinking rather than commentary

Narration is not describing your cursor. It is saying your prediction before you check it, so the interviewer can correct a wrong model early instead of watching you build on it for ten minutes.

Moment	Commentary, weak	Narration, strong
Opening the tree	"OK, so there is a src folder here."	"Layered, so I expect the change in the service and not the route handler. Checking whether that holds."
Opening a file	"This is the orders controller."	"I am looking for where the existing filter is built, because I would rather copy its shape than invent one."
Hitting an error	Silence, then a fix appears.	"That is a 500 where I expected a 400, so validation is not running before the query. Reading the trace."
A real choice	Quietly picks one.	"I can filter in the query or in memory after fetching. In memory is two lines but it breaks pagination, so query."
Stuck	Two minutes of nothing.	"I have been going in circles on how status is stored. Is it an enum column or a plain string?"
Finding a helper	Writes a second one.	"There is already a parser in utils doing this. Using it, so the behaviour stays consistent."

Thirty seconds is roughly the limit on silence before it starts costing you. Reaching for the interviewer at that point is not a penalty, it is the behaviour the format exists to observe.

What ends up on their notes

Did the change land in the right layer, and does it follow conventions already visible in the file.
Did they reuse what exists instead of writing a parallel version of it.
Did they ask before assuming, and were the questions worth the interruption.
Did they run the code and the tests along the way, or only at the end.
When something broke, did they read the error out loud or flinch and start changing things at random.
Would the repository be in a coherent state if the call ended right now.

Almost nothing on that list is typing speed or recall. A rough but well placed change, one test, and a clear sentence about what is unfinished usually beats a finished change delivered in silence.

Nobody hires a pair for their typing. They hire for whether the next four hours next to you would be cheap or expensive.

Where OfferPilot AI is the wrong tool for this round

Worth being direct, since this is a vendor page. A pair programming round is close to the worst fit for live coding assistance, for reasons that are structural rather than ethical.

The problem is not self-contained. Code Copilot captures a problem statement from your screen and returns a solution with intuition, a dry run and complexity. That is built for algorithm prompts. It cannot know that this project keeps validation in a schema file, that the filter object is built with defaults, or that a helper already exists two folders over. The entire difficulty of a pair round is the context that is not on your screen.
You are interrupted constantly. A teammate asks why every few minutes, in the middle of the code, pointing at one line. Anything you did not reason through yourself falls apart on the second follow up, in front of the person deciding.
Windows 10 and 11 only. No macOS, no Linux, no mobile, no browser extension. If your interview is on a Mac, none of this is available to you at all.
Be accurate about capture exclusion. The overlay is excluded from screen capture at the operating system level, so it does not appear in Zoom, Teams, Meet, OBS or screenshots, while staying visible on your own monitor. That covers screen sharing and recording, nothing else. It does nothing about a webcam, a lockdown browser, a proctor in the room, eye tracking, or a camera on a second device. Company rules still apply, so ask before the call if the invitation is ambiguous.

The honest use for this round is everything before it. Live help fits self-contained algorithm rounds and question heavy conversations. Fluency in an unfamiliar repository comes from practice you cannot outsource.

How to practise the format

Reading about pair rounds does very little. Three drills that transfer:

The four minute drill. Open an unfamiliar open source repo, pick any small issue, set a timer for four minutes and narrate the whole opening to an empty room. Record it. Listen for the moment you stop predicting and start describing.
The trace drill. Given a repo you have never seen, find where one specific behaviour is implemented in under three minutes. Speed here is the actual skill the format rewards.
The teammate drill. Have a friend hold the ticket, answer questions in character, and stay quiet otherwise. Ten minutes of this reveals more than an evening of solo practice.

Then spend the closing minutes on the round's own currency. Ask how they onboard someone new into this codebase and what their review culture looks like, since you have just lived a compressed version of both.

OfferPilot AI runs on Windows 10 and 11 and meters listening time only, with a free tier of five minutes a day and no card required. It fits the rounds where the problem is on the screen, not the rounds where the problem is a repository.

Pair programming interview tips: what to expect when the repo is not yours