Lab 12.3 — Mock Technical Interview

Goal: simulate a full 60-minute senior iOS technical interview, alone or with a partner, with self-grading rubrics.

Time: 60 min interview + 15 min self-debrief = 75 min total.

Prereqs: Quiet room, Xcode or a web Swift playground (https://swiftfiddle.com), timer, recording device.

Setup

If solo: record yourself (audio + screen). If with a partner: they read prompts and play interviewer.

Pick one of three difficulty paths below before starting.

Format

0:00 – 5:00    Warm-up Q&A (3 conceptual questions, ~90 sec each)
5:00 – 35:00   Live coding (one of the prompts below)
35:00 – 50:00  System design (lighter version of one Phase 12.9 scenario)
50:00 – 60:00  Behavioral (one STAR-style question)

Warm-up Q&A bank — pick 3

  1. Difference between @State, @StateObject, @ObservedObject, and @Environment?
  2. How does actor prevent data races, and what’s reentrancy?
  3. When would you choose class over struct?
  4. Walk me through URLSession.shared.data(from:) from start to finish.
  5. What problem does SwiftData solve that Core Data didn’t?
  6. Explain Sendable and Swift 6 strict concurrency in one minute.
  7. Difference between weak and unowned?
  8. How does @Observable differ from ObservableObject?
  9. What’s the responder chain in UIKit?
  10. How do you debug a retain cycle in a SwiftUI app?

Score each answer L1/L2/L3 per 12.8.

Live coding — pick one difficulty

Easy (target: junior/mid)

Implement a Debouncer actor in Swift Concurrency. It should let callers schedule an async closure to run after N milliseconds of inactivity. Each new call cancels the previously scheduled run.

Bonus: write a unit test using Task.sleep proving rapid successive calls only fire once.

Medium (target: mid/senior)

Implement an LRU cache generic over Key: Hashable and Value. Constructor takes capacity. get(_:) returns optional value and bumps recency. set(_:_:) inserts or updates; evicts least-recently-used when over capacity. All operations O(1).

Bonus: make it thread-safe via an actor variant.

Hard (target: senior/staff)

Implement a RateLimiter actor: a token bucket allowing N requests per T seconds. Method acquire() is async — returns immediately if a token is available, or waits until one is. Cancellation must clean up waiters.

Bonus: support priority — high-priority callers jump the queue.

Live coding self-grading rubric

Dimension0 (poor)1 (passable)2 (strong)
Clarifying questionsNone asked1–2 generic3+ specific, written down
NarrationSilent typingSome narration, gapsContinuous; thinking audible
Type signature firstNoYes, but inconsistentYes, explicit, justified
Tests / verificationNoneManually walked throughAt least one sanity test
Tradeoff awarenessNone mentionedOne in passingMultiple explicit
Recovery from stuckSilent or gave upAsked for hintVerbalized obstacle, simplified, asked for hint
Code correctnessDoesn’t compileCompiles, has bugsCompiles and runs correctly
Code clarityHard to readReadableIdiomatic, self-documenting

Pass bar for senior level: average ≥ 1.5 with no dimension at 0.

System design — pick one

Choose one scenario from 12.9 (Instagram Feed, Real-Time Chat, Offline Note App, Maps, Video Streaming) and discuss for 15 min covering:

  1. 3 clarifying questions (record what you’d ask)
  2. High-level architecture sketch
  3. iOS-specific deep-dive on data layer + state + concurrency
  4. Two tradeoffs you’d flag to interviewer
  5. What changes at 10× scale

Grade against the rubric:

Dimension012
ClarifyingSkippedGenericSpecific to scope
iOS focusServer-heavyMixedPredominantly iOS
Tradeoff verbalizationNoneOneMultiple, named
Scaling discussionNoneHand-wavyConcrete (CDN, sharding, etc.)
Offline / background concernsIgnoredMentionedDesigned for

Behavioral — pick one

  1. Tell me about a time you owned a difficult technical decision.
  2. Tell me about your hardest bug.
  3. Tell me about a time you disagreed with a designer or PM.
  4. Tell me about a project that failed and what you learned.
  5. Why do you want to work here? (research a real company)

Use a STAR template from 12.11. 90-second timer.

Self-grade:

Dimension012
STAR structureMissing piecesAll present, weak transitionsAll present, smooth
“I” languageMostly “we”MixedMostly “I” with team context
Concrete resultNoneVague (“it went well”)Specific number / outcome
Time discipline> 2 min90 s – 2 min< 90 s

Debrief (15 min)

  1. Re-listen to your recording.
  2. Score each section using the rubrics above.
  3. Identify the single weakest area.
  4. Pick one action to improve next week.

Common weak areas and remedies:

Weak areaRemedy
Silent live codingPractice narrating while doing daily work tasks
Skipped clarificationsWrite the 5 standard questions on a sticky note next to your monitor
Vague STAR resultsRewrite stories with measurable outcomes; verify numbers
Wandering system designTime-box each section in a 4×4 grid: clarify / architecture / iOS deep dive / tradeoffs
Defensive when correctedPractice the “you’re right, I missed that” acknowledgment phrase aloud

Stretch

  • Run the same exercise 4 weeks running. Track scores. Look for the inflection point (typically week 3) where it stops feeling unnatural.
  • Pair with a peer; switch interviewer/candidate roles each week.
  • Record yourself answering a single behavioral question 5 times in a row, listening to each playback. By the fifth, it’ll be tight.

Notes

The single most valuable feedback comes from listening to your own recording. You will cringe. That’s the data; iterate on it. Most candidates skip recording and then wonder why interviews don’t go well — they’ve never heard themselves under simulated pressure.


Next: Lab 12.4 — System Design Whiteboard