Senior iOS interviews are about risk

A senior iOS interview has quiz-like moments, but the hiring decision is not really about trivia. The team is trying to answer a risk question: if we put this person on a complicated mobile surface, will they make the system safer or more fragile?

That is why simple questions often become deeper. Optionals become data modelling. Weak versus unowned becomes ownership and crash risk. SwiftUI state becomes identity and rendering cost. Caching becomes correctness. System design becomes user trust when the network disappears.

When asked about a technical choice, do not stop at what it is. Say what can go wrong. If you choose optimistic updates, the risk is showing a state the server later rejects. If you choose Core Data, the risk may be migration complexity and threading mistakes. If you choose a shared module, the risk may be dependency drag and unclear ownership.

This does not make you sound negative. It makes you sound like someone who has shipped software long enough to know that every design has a bill.

Pattern names are useful shorthand, but they are not seniority. MVVM, coordinators, repositories, actors, dependency injection and clean architecture can all be reasonable or ridiculous depending on the team and problem.

A stronger answer explains why the pattern fits this constraint. For a small feature, a repository may be ceremony. For offline sync across several screens, it may be the boundary that protects the rest of the app. The same tool can be over-engineering in one context and necessary in another.

You will give an incomplete answer. Everyone does. What matters is how you recover when pushed. A weak recovery defends the original answer because pride is now involved. A strong recovery updates the model.

Say: that changes the constraint. Then adapt. If the interviewer says the app must work offline, your caching answer needs a mutation queue and conflict policy. If they say the screen handles sensitive data, your lifecycle answer needs privacy behaviour. If they say the list has ten thousand items, your rendering answer needs measurement and pagination.

Pushes come in three shapes, and each wants a different recovery. The interviewer tests an overclaim: you said the cache is thread-safe, is it? Name the boundary in the same breath, safe for this access pattern and not for that one; an interviewer who catches one inflated claim starts doubting the rest. The interviewer adds a constraint, as above: say that it changes the constraint, then change the answer. Or the interviewer asks why, and then asks why again. Go one level down to the mechanism each time, and when you reach the edge of what you know, say how you would find out instead of guessing.

A cache layer tells me where data might live. It does not tell me whether the screen can show the previous account's data. Here are two answers, each with the follow-up that tests it. Say them in your own words, and claim only what you would build.

Prompt: the profile screen should open without waiting for the network. The first answer most people give is to read the cache, show it and refresh in the background. That is a flow, not a policy. The stronger answer:

I would decide which fields may be shown from a previous fetch and how the screen labels them as stale. I would scope the cached record to the account, so another account cannot reuse it. If the refresh fails, the screen shows a defined stale or unavailable state and never implies the data is current.

Follow-up: the user signs out while the refresh is in flight.

The response belongs to the account and session that started it. It must not update the next account's screen. I would test it with a controlled response that completes after sign-out. Cancellation helps with cleanup, but I still need an ownership check that decides which result may apply.

The risk named is an account-boundary leak. The evidence is a test of the late-result path. The SwiftUI and UIKit article develops the ownership question behind that answer.

Prompt: what do you do when a payment request times out? A blanket retry skips the case where the server already accepted the request.

I would separate a known rejection from an unknown outcome. Before retrying a state-changing call I need the API's operation identity and a way to reconcile. The UI shows an unresolved state until the authoritative result is known. I would test acceptance followed by response loss, because that breaks a happy-path retry design.

Follow-up: the server has no status lookup and no duplicate policy.

Then my recovery design is unsupported, and I say so. I would raise the dependency and agree a narrower product behaviour with the service and product owners. A retry loop does not make an unknown outcome safe.

The signal is that you change the design when the contract it needs does not exist. For more prompts, use senior iOS preparation.

For each topic, practise four layers: definition, production use, failure mode, recovery. What is it? Where have you used it? How does it fail? How would you detect and fix the failure?

This turns interview prep from memorisation into judgement rehearsal. You still need the definitions. But the offer comes when the interviewer believes you can protect the app, the team and the user when the clean answer stops being enough.

If the interviewer asks how you would cache a profile screen, do not answer with only a cache layer. Say what must stay fresh, what can be stale, what happens offline, whether sensitive fields can be stored, how refresh is triggered, and what the user sees if the update fails.

If the interviewer asks about architecture, do not start with a diagram. Start with the risk: team scale, change frequency, offline behaviour, testing cost, release safety or ownership. The architecture should answer that risk.

That specificity is what separates a senior answer from a rehearsed answer. It gives the interviewer something real to evaluate.