Home / how to pass the iOS live coding round

Live coding round

How to pass the iOS live coding round

Passing the live round is a skill you can rehearse. The engineers who pass are not the fastest coders, they are the clearest communicators under pressure.

A repeatable method

Open by clarifying the problem and stating your assumptions, then sketch a plan out loud before typing. Build the simplest correct version first and say so; you can optimize once it works. Narrate as you go so the interviewer can follow your reasoning and help you when useful, and leave time to verify with a quick test or a walked example.

Handling pressure and stalls

When you get stuck, do not go silent. Say what you are considering, weigh two options aloud, and commit to one with a reason. Writing a small failing case or asking a targeted clarifying question turns a stall into a visible, senior looking recovery. Manage interruptions by acknowledging the redirect, adjusting, and continuing to narrate.

What actually gets written on the scorecard

After 500 plus interviews on the hiring side, I can tell you the scorecard rarely has a line called finished the problem. It has lines like problem framing, code quality, communication, and handling of feedback. That changes what passing means. A candidate who clarifies the requirement, ships a small correct core, and names the two edge cases they skipped can score well on every line. A candidate who silently completes everything can still fail communication and feedback outright. You are not being graded like a compiler. You are being graded like a future teammate whose reasoning the interviewer just watched for an hour. Optimize for legible reasoning first and completeness second, in that order, on purpose.

The first five minutes, scripted

The strongest candidates I have watched run a near identical opening, and it is learnable. First, restate the task in one sentence and get a nod. Second, ask the one question that changes the design, for example: should this survive bad server data, or can I assume the payload is clean. Third, say the plan in under 30 seconds: I will model the types first, write the core function with async await, handle the error and empty cases, then test one path if time allows. Fourth, name what you are deliberately skipping. This script costs three minutes and buys you the rest of the hour, because the interviewer now scores everything you type against a plan they agreed to instead of guessing where you are going.

4 recovery lines for when an answer wobbles

Stalls are scored by how you exit them. Each of these takes one breath to say.

• When your approach is failing: this is getting more complex than the problem deserves, let me step back to the simpler version with a plain struct and one function.
• When the interviewer challenges a choice: you are right that this breaks under concurrent writes, the fix is to move this state into an actor, let me do that.
• When you blank on an API: I do not remember the exact URLSession signature, so I will write the shape I want and fix the name against autocomplete.
• When a test fails in front of them: good, that failure is telling us the empty input path is wrong, which is exactly what the test was for.

Notice the pattern. Each line names the problem, claims it, and states the next move. That sequence reads as composure. Silence followed by frantic edits reads as the opposite, even when the final code is identical.

Swift specifics that earn points fast

Some moves are cheap to make and disproportionately scored in iOS rounds. Model with structs and enums before reaching for classes, and say why: value semantics remove a whole category of shared state bugs. Make errors typed and thrown rather than returning optionals that erase the reason. Use async await over completion handlers and mention that structured concurrency ties the work to a scope, so cancellation is not an afterthought. If shared mutable state appears, name the race before protecting it. And write one XCTest on the core logic, even a five line one. In my experience running these rounds, a single test on the decode path moves a borderline scorecard more than ten minutes of extra features.

What to do in the last five minutes

Do not start anything new. Walk the code top to bottom out loud, once, the way you would in a code review. State what is done, what is stubbed, and what you would do next with another hour. Then stop talking. Candidates who sprint into a new feature at minute 55 usually leave a compile error on screen, and that error is the last thing the interviewer sees before writing the debrief. A clean stop with a clear summary is a senior behavior, and it is the easiest one on this page to rehearse.