A Modern Swift Concurrency Interview Map

Most Swift concurrency interview prep starts with syntax. async, await, Task, actors, MainActor, Sendable. The syntax matters, but senior interviews usually test lifetime, ordering and ownership.

When you see a Task, ask what owns it. When you see an await, ask what can change before execution resumes. When you see cancellation, ask whether the work actually observes it. These questions find the real bugs.

A senior candidate can explain the feature over time, not only the line of code in front of them.

Cancellation in Swift concurrency is cooperative. That means the task needs to reach a cancellation-aware suspension point or explicitly check cancellation. If the code is doing expensive synchronous work, cancellation may be requested but not honored quickly.

In an interview, connect cancellation to user intent. A search result for an old query should not update the UI. An image request for a reused cell should stop. A payment or draft save may need to continue through a more durable path.

The right cancellation answer depends on what the work means.

Actors serialize access to isolated mutable state. They do not automatically make a workflow correct. The dangerous part is usually the await inside an actor method.

If an actor reads state, awaits the network, then writes based on the old state, another call may have changed the state during suspension. The actor did its job and the logic can still be wrong.

A strong interview answer names reentrancy and then describes the fix: snapshot values, re-check after await, split the operation, or move the mutation to protect the invariant.

MainActor is a useful boundary for UI state. It is not a junk drawer for code that made the compiler complain.

If a view model on MainActor starts doing heavy mapping, image processing, database reads or JSON decoding, the annotation may hide a design smell. The UI lane is not where expensive work belongs.

In a senior answer, say what belongs on MainActor and what should move elsewhere. That shows you understand correctness and performance together.

Sendable is not just a warning to silence. It asks whether a value can safely cross concurrency domains. Value types with immutable data are easier to reason about. Shared mutable reference types require much more care.

When code uses unchecked Sendable, ask what invariant makes it safe. Is the object immutable after initialization? Is access protected? Is it really thread-safe, or did the annotation just move risk out of sight?

That is the answer interviewers want: not just the definition, but the proof you would expect in production code.

A useful concurrency answer follows this map: what owns the work, what can cancel it, what state it touches, what can change across awaits, what concurrency domain it crosses and how the UI stays truthful.

If you can apply that map to search, image loading, caching, sync and SwiftUI view tasks, you will sound like someone who has debugged real apps, not someone reciting API names.