Home / iOS live coding interview

Live coding round

iOS live coding interview

The live coding round is where strong iOS engineers stall. Here is what actually happens in it, how interviewers score it, and how to prepare so you perform instead of freeze. This is the hub for the whole live coding cluster.

What happens in an iOS live coding interview

An iOS live coding interview is a 45 to 60 minute session where you build a small Swift program live, usually in Xcode or a shared editor, while the interviewer watches. Typical tasks are modeling and parsing JSON with Codable, an async networking or caching feature, or a small stateful component. The problem is deliberately open so the interviewer can see how you think, not just whether you memorized an answer.

How interviewers score it

You are rarely judged on reaching a flawless solution. Interviewers score how you clarify requirements, choose types and structure, handle edge cases, talk through trade-offs, and verify your work with a quick test. A partial solution explained clearly beats a complete one built in silence. Communication and recovery are weighted as heavily as correctness.

The shape of the hour, minute by minute

Most 60 minute rounds follow the same arc, and knowing it removes half the stress. Minutes 1 to 5 are introductions and the task statement. Minutes 5 to 10 are yours for clarifying, and interviewers notice who uses them and who starts typing immediately. Minutes 10 to 40 are the build, where the interviewer will interject at least once with a requirement change or a challenge, because watching you absorb a change is part of the design. Minutes 40 to 50 are edge cases and, ideally, a test. The last stretch is questions and wrap up. When I run this round, the interjection is planned before the call starts. Candidates who treat it as a normal code review comment score well. Candidates who treat it as an attack visibly lose ten minutes recovering.

What a passing performance sounds like

The audio track matters as much as the code. A passing candidate sounds like this, roughly every few minutes: I am going to model this as a struct because nothing here needs identity. I will decode defensively since this is server data. This dictionary is now shared mutable state, so before I go async I will wrap it in an actor. I have the happy path working, so let me handle the empty and error cases before optimizing. Each line is 15 to 30 seconds, spoken while typing. None of it is performance for its own sake. It is the same narration you would give a teammate pairing with you, which is exactly the signal the round exists to collect.

The 3 mistakes that end the round early

Three behaviors reliably sink an otherwise capable candidate. I have written no hire after each of them more than once.

• Coding for ten minutes before speaking. By the time you surface, the interviewer has already stopped following, and a lost interviewer cannot give you points.
• Arguing with the requirement change. The change is scripted. Pushing back on its realism scores as inflexibility, not insight. Absorb it, restate it, adjust the plan out loud.
• Refusing to run the code or the test. Saying it should work while declining to verify reads as a habit, and interviewers assume your habits ship to production.

How this round differs from the rest of the loop

The system design round scores what you would build. The behavioral round scores what you say you did. Live coding is the only round that scores what you actually do under observation, which is why it carries disproportionate weight in debriefs when signals conflict. It is also the round where preparation transfers most directly: the task types repeat across companies far more than system design prompts do. Codable parsing, an async fetch with caching, a debounced search, a small refactor. Rehearse those four shapes with narration until the talking is automatic, and you have covered the majority of what any iOS loop will put in front of you. The chapters linked below break each shape down individually.

The recovery line to memorize before the call

Every candidate wobbles at least once per hour. What separates outcomes is the next ten seconds. Memorize one all purpose recovery line and use it verbatim: let me step back, say what I know, and pick the simpler path. Then do exactly that, out loud. The line buys you a breath, tells the interviewer the stall is handled, and commits you to movement instead of polish. In my scorecards, a visible recovery like this is worth more than not stalling at all, because it is evidence of how you behave when production breaks. Nobody gets to observe that in the rounds where everything goes smoothly.