Pair programming interview: what gets scored

This guide is for mobile engineers with a round called “pairing session” or “pair programming interview” on the schedule. It explains how the round differs from ordinary live coding, what the interviewer is scoring while they type next to you, the moments that come up in pairing rounds with the response that scores, a worked exchange, and how the round looks on iOS and Android setups.

I have run pair programming rounds as an interviewer, and I have paired with engineers as a mentor. The two feel similar from the inside, and they are judged very differently. That difference is most of what this page is about.

How it differs from live coding

In a live coding round the interviewer mostly watches. In a pairing round they work with you: they suggest, they ask you to try something, they take the keyboard, they hand it back. The problem is usually practical, often a feature on starter code, sometimes a bug in existing code.

	Live coding	Pair programming
The interviewer	Watches, asks, gives hints when you stall	Suggests, types, disagrees, hands over the keyboard
The problem	Often from a blank file	Often starter code or an existing project
What you are narrating	Your decisions	Your decisions, and your response to theirs
The failure that ends it	Silence	Folding to every suggestion, or fighting every one

The narration habits from the mobile live coding guide still apply. What is added is a second person whose ideas you have to weigh in real time.

What is scored

When I run a pairing round, the notes I need at the end are about working with this person, not only about the code:

Whether you weigh a suggestion or just accept it. A suggestion from the interviewer is often a test of whether you will push back. A suggestion can be a real improvement, or deliberately worse than what you had. Accepting both the same way tells me you are optimising for my approval, not for the code.
Whether you can disagree without friction. Pushing back is only a positive signal when it comes with a reason and an open question, not a defence.
Whether you change your mind for a good reason. When the suggestion is better, saying so, and saying why, scores more than having had the idea first.
Whether the keyboard handoff is clean. Saying what you are about to do before you take it, and where you left things before you give it back.
Whether the code still moves. A pairing round is not a design debate. If twenty minutes pass in discussion and nothing runs, the collaboration failed too.

The moments that come up, and the response that scores

1. “What if we used X instead?”

What it is: often a test of whether you will defend a choice you made on purpose.

Response that scores: “That is a fair option. I chose Y because of this reason. X would win if this condition changed. Do you want me to switch, or is Y fine for now?” Name your reason, name what would make theirs better, and hand the decision back.

The trap: “Sure, let’s do X” when you had a reason for Y and did not say it.

2. “I think there is a bug here.”

What it is: sometimes there is, sometimes it is a check that you read your own code.

Response that scores: read the line out loud with a concrete input before agreeing or disagreeing. “If the list is empty, this index is out of range. You are right.” Or: “With an empty list the guard returns first, so I think this is safe. Let me run it to be sure.”

The trap: agreeing immediately without checking, or defending without checking. Both skip the step being scored.

When the trace shows they are right, say so and move straight to the fix: “Yes, a thrown error leaves the screen empty. I skipped that path to get the flow working. The view model should publish an error state and the screen should render it; I will do that right after this step.” Three things in one reply: the gap, the fix, and where it sits in your order of work. What costs you is the half defence that starts with “well, I was going to”.

3. “Can I drive for a bit?”

Response that scores: give a one-sentence status before you let go: “The fetch works and returns decoded models; the list is not wired yet.” Then watch and narrate as the navigator: “That will run on the main actor, which is fine for this size.”

The trap: going silent while they type. The round did not pause.

4. “Take it back and finish the list.”

Response that scores: say what changed while they drove before you continue. “You added the error state here, so I will render it in the view.” Integrate their work; do not rewrite it without saying so.

5. “Why not just use a library for that?”

Response that scores: a real answer about dependency judgement: what the library would save, what it would cost in the review, and what you would do in production versus in a 45-minute round. Both answers are defensible. Not having thought about it is not.

6. “We are running out of time.”

Response that scores: cut scope out loud. “I will stop the pagination here and make sure the first page and the error state work, then describe how the next page would load.” Knowing what to drop is scored.

7. The interviewer goes quiet

Response that scores: keep working and keep narrating at the level of intent. Silence from the interviewer is not a signal that you are wrong. It may be a check on whether you need them to keep moving.

Taking suggestions without folding

The collaborative defence has three moves, and it works for every kind of suggestion:

Treat the question as real. Do not repeat what you already said. “Let me make sure I am answering what you are asking.”
Agree with the part that is true. Most suggestions contain a valid point even when the conclusion is wrong. “It does add a layer.”
Give the full trade-off and the weight you put on it. “The layer is complexity, and the coupling it removes is also complexity. Here I think the coupling is worse, because decoding changes would have to be made in four places.”

The shape is acknowledgement, tension, reasoning, weight. It lets you hold a position without sounding defensive, and it leaves room to change your mind in the next sentence.

Disagreeing well

Sometimes you will think the interviewer’s idea is worse, and you should say so. Phrases that work:

“I get why X is attractive. I would still keep Y, for this reason, unless your codebase has something I do not know about. How do you see it?”
“Tell me if I am off here. X has bitten me in exactly this kind of case, which is why I lean towards Y. Is there a reason X works better here?”
“You caught a gap. I can see two ways to handle it; I would lean towards the first. What does your team do?”

The move from a competent answer to a senior one is from “my reason is good” to “my reason is good, and I can see why yours differs”. The move to Staff is from defending to exploring: “help me understand whether I am right.” Candidates who change their minds in real time for a good reason pass. Candidates who dig in by reflex do not.

Worked exchange

A pairing round on an iOS starter project. The candidate has extracted networking into a service behind a protocol.

Interviewer: “Why not call URLSession directly from the view model? It is less code.”

Candidate: “It is less code. The protocol is one more type to read. What it buys is that I can test the view model with a stub that returns after a delay, which is how I would test that a stale search result never lands. For this size of feature I think that is worth one type. If this screen were never going to be tested, I would agree with you.”

Interviewer: “Fine. There is a bug in your cancellation, though.”

Candidate: “Let me trace it. Query ‘sw’, then ‘swift’ before the first returns. The first task is cancelled here, and here it checks cancellation after the await, so it never publishes. I think it is safe. Can I run the test to confirm?”

Interviewer: “Go ahead.”

The first answer held the position with a reason and named the condition under which the interviewer would be right. The second checked instead of agreeing. Neither answer is about Swift. Both are exactly what the round is scoring.

Mobile-specific setups

iOS: normally Xcode with your screen shared, frequently inside a starter project they give you. Have the simulator booted before the call, font size up, and notifications off. If the build breaks for reasons unrelated to the task, say so and continue with a stub.
Android: usually Android Studio with an emulator. The same preparation applies; a slow emulator is worth mentioning early so nobody reads the wait as hesitation.
Shared editors: some teams pair in a browser editor where UIKit, SwiftUI and Compose do not run. Then the round is about the model and the logic, and you describe where the view would go.
Remote handoff: “can I drive” in a remote round often means the interviewer types in the shared editor or you follow their instructions. Ask which before it happens.

Whichever setup you get, say it out loud at the start: what you will run, where, and what you will do if the tooling gets in the way. It costs ten seconds and removes a whole class of awkward pauses.

Sources

Martin Fowler and Birgitta Böckeler, On pair programming

What to do next

Build a prep plan for your loop if the pairing round is one of several.
Read the iOS coding interview for the tasks a pairing round on iOS is usually built on.

Whichever you pick, answer out loud and time yourself. Saying the answer is the part a page cannot do for you, and it is the part the round scores.