Home / iOS pair programming interview

Live coding round

iOS pair programming interview

A pairing round is a collaboration test as much as a coding test. The interviewer acts as a partner, and how you work with them is part of the score.

How it differs from solo live coding

Instead of coding alone while watched, you build something together: the interviewer may steer, suggest, or intentionally disagree. They are assessing whether you listen, incorporate feedback, share the keyboard gracefully, and keep the work moving. Treating it as a solo performance is the classic mistake.

How to behave in the round

Think out loud, invite input, and restate the plan so you are aligned before coding. When the interviewer pushes back, engage with the idea rather than defending your first instinct, and say why you agree or disagree. Small courtesies, like confirming direction and summarizing decisions, signal the collaborator they want to hire.

What the interviewer is scoring when you pair

I have run pairing rounds for years, and my notes rarely mention the final code. They mention moments. The moment you restated the problem in your own words before touching the keyboard. The moment I suggested a different data structure and you either engaged with the idea or brushed it past. The moment the plan broke and you either renegotiated it out loud or went quiet and started typing faster. A pairing round is a one hour sample of what working with you for a year would feel like. Interviewers write feedback in those terms. "Easy to redirect" and "hard to interrupt" are both real lines from real debriefs. Correct code with a partner who felt shut out is a weak hire signal. Slightly unfinished code with a partner who felt heard is often a strong one. That trade surprises most candidates, and it is the single most useful thing to know before the round.

Thinking out loud without narrating keystrokes

Thinking out loud does not mean describing your typing. "Now I am writing a for loop" tells me nothing. What I want to hear is intent and trade-offs. Say what you are about to do and why, at the level of decisions: "I will store seen values in a set because lookups need to be constant time, and the extra memory is fine at this input size." Then code in relative quiet, surfacing again at the next decision point. This rhythm matters in pairing more than in solo rounds because your partner needs entry points. Every time you state a decision, you hand the interviewer a chance to steer. When you narrate keystrokes instead, you fill the air while closing every door. A useful spoken habit: end each decision with a short check. "Does that match what you had in mind?" It takes two seconds and it converts a monologue into a session the interviewer can score as collaboration.

How silence reads from the other side of the screen

Silence is not neutral. From the interviewer's side, thirty quiet seconds while you stare at the editor is ambiguous: you might be reasoning carefully or you might be lost, and interviewers are trained not to assume the generous option. In a pairing round the ambiguity is worse, because silence also reads as excluding your partner. You do not need to fill every gap. You need to label the gaps. "Give me twenty seconds, I want to check this edge case in my head" buys you the silence and turns it into a positive signal, because you managed the collaboration even while thinking. The same applies when you are stuck. "I am stuck on how to handle the empty input, here are the two options I see" is not a confession. It is the moment many interviewers mark you up, because reasoning through being stuck with a partner is exactly the job.

When the pushback is deliberate

Many pairing interviewers disagree with you on purpose at least once, often with a suggestion that is defensible but worse than your plan. This is not a trick for its own sake. It measures the exact skill teams argue about in code review: can you hold a position without being rigid, and yield without being spineless. The failing responses are the two extremes. Instant surrender tells me you will fold in design meetings. Flat refusal tells me review threads with you will be long. The response that scores well is short and structured: name the merit in the suggestion, name the concrete cost, propose a way to decide. "That would simplify the model, but it makes the lookup linear. Can we keep the set and revisit if memory becomes a concern?" If your first answer wobbled, recover plainly: "Let me back up, I dismissed that too fast. Walk me through what you were seeing." That line has saved more pairing rounds than any algorithm.

How to rehearse a pairing round

You cannot rehearse pairing alone in silence, but you can get close. Three drills work. First, solve a problem while recording yourself, then listen only for decision statements: if you cannot count at least one spoken trade-off per few minutes, you narrated keystrokes or said nothing. Second, have a friend interrupt you mid-solution with one wrong suggestion and one good one, and practice the agree, disagree, and check patterns until they come out naturally. Third, practice handing over: stop mid-problem and explain the current state well enough that someone else could continue, because a pairing interviewer will sometimes take the keyboard and you are scored on how well you set them up. Ten sessions of this changes how the round feels. The problem is rarely the hard part. The partnership is the part almost nobody has practiced.