What is a reliable routine for answering “what does this print?” under interview pressure?
Mental model. Solving a puzzle like a mechanic: find the one part that moves differently from what you assumed, then explain the whole engine from there.
A puzzle is a short program with one hidden rule, and the routine is to find that rule before you start tracing. Read once for what the code is about (a closure, a defer, a queue, an await, a view’s identity), then ask the matching question from the table. Then trace line by line, writing down state: which references are alive, what the variables hold, what is in the queue. Say your reasoning aloud: interviewers care more about the model than the final line.
When you are not sure, say what you would check, name the rule you believe applies, and mention what is unspecified (release order of properties, ordering of unrelated tasks, whether the optimiser may shorten a lifetime). Two habits to avoid: pattern-matching to a famous puzzle without reading the code, and defending an answer after you spot a mistake. Finish by saying how you would make the code robust (capture list, explicit await, stable id, cleanup in deinit), because for staff-level roles the fix matters more than the trace (and this topic is a minor part of a loop: the design questions carry more weight).
| The usual surprise | |
|---|---|
| Is it a value or a reference? | Copies are independent; a class instance is shared (struct captures, defer return values). |
| Does the closure copy or share the variable? | A closure shares the variable unless a capture list copies it; loops differ (for versus while). |
| Who holds a strong reference, and for how long? | Cycles through stored closures or work items; a strong reference taken for the closure body. |
| When does this code actually run? | Async never runs inline; defer runs on scope exit; a Task waits for the actor. |
| What can change at this await? | Another call can run in between, so a check made before it can be stale. |
| What is the identity? | SwiftUI state follows the id, not the position on screen. |
| Is the order promised? | Only what the queue, an await or a happens-before rule orders is guaranteed. |
Common traps
- Answering from memory of a similar puzzle. Small changes (let versus var, sync versus async) flip the result.
- Guessing at unspecified behaviour as if it were guaranteed. Say what is promised and what is merely typical.
They might follow up with
- How do you check your answer? Run it, or add prints, in a playground or a command-line target, ideally in both debug and release builds.
- What do you do when a puzzle has an unspecified result? Say so, give the likely result, and explain what makes it dependable.
Related questions
- 27.1.1 In what order do initialisers and deinitialisers run for a subclass with stored properties, and what does…
- 27.1.2 What do closures print when they capture a loop variable, a shared variable, or a copy in a capture list?
- 27.2.1 A function returns x and a defer changes x afterwards. What does the caller receive, for a value, an inout, a…
- 27.3.1 Blocks are scheduled on the main queue from the main thread, and one of them schedules another. In what order…
- 27.4.1 Two tasks each withdraw 80 from an actor account holding 100, with an await between the balance check and the…
- 27.4.3 Rows keep a @State value. After removing the first of three items, which state does each remaining row show…
- 3.1.3 When exactly is an object deallocated: at the end of its scope, or after its last use?
- 10.4.1 What does an actor guarantee, and what is actor reentrancy?
← Rows keep a @State value. After removing the first of three items…