How Swift concurrency is tested in interviews

Companies probe concurrency in more than one format. Knowing which format you are in tells you how to show your knowledge.

The formats you will see

Live coding often asks you to convert a completion handler to async/await or fetch several resources concurrently. Code review rounds plant a data race, a misused DispatchQueue, or a retain cycle in a closure for you to spot. System design and architecture discussions ask how you would keep shared state safe across features, which is where actors and Sendable come up.

How to prepare for each

For live coding, rehearse continuation wrapping, task groups, and cancellation until they are automatic. For code review, practice narrating why a snippet races and how an actor or isolation fixes it. For architecture, be ready to justify where you put actors, how you keep types Sendable, and how you avoid blocking the main actor.

Go deeper than a summary

Share Your Screen works topics like this through in full: 75 solved Swift problems with tests, 9 real case studies, and 7 annotated mock interviews, so you rehearse the live round instead of just reading about it.

Get the book

Frequently asked

Do interviewers make you write concurrent code live?

Often yes, such as converting a callback to async/await or fetching resources in parallel, but concurrency also appears in code review and architecture discussion.

What is the best way to prepare?

Rehearse the common live tasks, practice explaining why a snippet has a data race and how to fix it, and be ready to justify actor and Sendable choices at the design level.