Home / iOS live coding interview questions

Live coding round

iOS live coding interview questions

Live coding rarely uses abstract puzzles. The tasks look like small slices of real app work, so knowing the common shapes lets you rehearse the moves in advance.

The task types that recur

Expect JSON modeling and decoding with Codable, an async networking call with error and loading states, a small in-memory or disk cache, debouncing or rate limiting user input, a lightweight list with filtering or sorting, and refactoring a messy snippet. These map directly to daily iOS work, which is the point.

What a strong answer looks like

Clarify the contract first, model the data with value types, isolate side effects, and handle the empty, error, and loading cases explicitly. Name your complexity and trade-offs as you go, then prove one path with a quick test. Reaching for the right standard library tool, rather than reinventing it, signals experience.

What each task type is really scoring

I have run this round more than most candidates have sat it, and every task type has a hidden rubric. The Codable task scores how you handle data you do not control. The caching task scores your grasp of ownership and invalidation. The debounce task scores whether you understand time as a source of bugs. The refactoring task scores what you notice before you touch anything. Solving the surface problem while missing the hidden rubric is the most common way a technically correct candidate gets a weak score. Ask yourself, before typing, what failure this task exists to expose. Say your answer out loud. That one sentence tells the interviewer you have seen this class of problem in production, not just in prep.

The Codable question and the trap inside it

The obvious answer is to declare structs, conform to Codable, and decode. The trap is the follow-up: what happens when one item in the array is malformed. If your model decodes the whole array with a single throw, one bad element kills the entire feed. Interviewers plant this on purpose. A line you can say in about 20 seconds: I will decode each element individually and drop failures, because in a real feed one corrupt item should not blank the screen, and I will log the failure so the backend team hears about it. Mention a lossy decoding wrapper or a manual init from decoder that recovers per element. If you already decoded strictly and the follow-up lands, the recovery line is: that is a fair catch, strict decoding is the wrong default for server data, let me isolate the failure to the element level.

The async and caching follow-ups

The networking task looks like a URLSession call with async await. The scored part comes after it works. Expect these follow-ups: what happens when the view disappears mid request, what happens when two requests race, and where the cache lives when two tasks write at once. The obvious in memory dictionary cache walks straight into the third one. The strong move is to name the data race before the interviewer does and reach for an actor, then say why: an actor serializes access so I do not need locks, and the await points make the suspension explicit. For cancellation, check Task.isCancelled or rely on URLSession throwing on cancel, and say that stale responses must not overwrite fresh state. Candidates who mention request deduplication, keeping one in flight task per key, usually get flagged as senior in the debrief.

3 spoken lines that transfer across task types

These lines fit most tasks on this page and each takes under 30 seconds to say.

• Before I code: the input I do not trust here is the server payload, so I will design the model to survive bad data rather than assume good data.
• Mid task: I am choosing the simple version first, a plain function with value types, and I will only add the actor once I have shared mutable state to protect.
• At the end: the paths I have not covered are cancellation and the empty state, and with five more minutes I would write one XCTest for the decode failure case.

The third line matters most. Naming your own gaps before the interviewer finds them converts a missing feature into a scored positive.

The senior differentiator

Mid level candidates answer the question they were asked. Senior candidates answer the question plus its blast radius. On a filtering task, that means asking whether the list can change while the filter runs. On a cache, it means stating the eviction policy even when nobody asked. On a refactor, it means writing one characterization test before moving code. None of this takes extra time worth mentioning. It takes one sentence per decision, spoken while you type. In the debriefs I have sat in, that habit is the single most reliable predictor of a strong hire recommendation for this round.