12.11 — Behavioral STAR Templates
STAR refresher
Situation — context, briefly. Task — what you specifically had to do. Action — what you did, in detail, using “I” not “we”. Result — measurable outcome.
Keep it under 90 seconds. Practice each template until the structure is invisible.
The 10 essential templates
1. Performance improvement
Situation: Our chat list scrolled at 35fps on iPhone 11, painful below the home indicator.
Task: I owned a sprint to hit 60fps without UI changes.
Action: I profiled with Instruments, found the bottleneck in cell layout (auto-layout running 8 passes per row due to nested stacks). I refactored the cell to a single UIView with manual layoutSubviews, cached attributed-string sizes in a memoized helper, and switched image loading to downsample-on-decode at the cell’s content size. I added a CI assertion measuring scroll perf via XCUITest.
Result: Steady 60fps; the regression test caught two future PRs that would have re-introduced layout slowdowns.
Adapt by swapping in your real bottleneck (decode time, JSON parsing, Core Animation, network).
2. Difficult technical decision
Situation: We were 4 weeks into adopting RxSwift across the team when Swift Concurrency landed. Task: I had to decide whether to keep adopting Rx or pivot to async/await. Action: I built a small spike of both for our auth flow; compared LOC, test surface, on-call burden, and onboarding cost for a new hire. I wrote an ADR (architecture decision record) recommending we freeze Rx adoption at the auth boundary and write all new features with async/await. I socialized it via two engineering wide reviews to align dissent before locking the decision. Result: 18 months later, no async/Rx hybrid bugs in our incident log; the new hire ramp time dropped from 4 weeks to 2.
3. Working in a legacy codebase
Situation: I inherited a 6-year-old Obj-C app with 200k LOC, no tests, six engineers had left over its history. Task: Add subscription IAP within 8 weeks without breaking the existing flows. Action: I treated the inheritance like an archaeological dig — read every commit message on the touched modules. Wrote characterization tests for the receipt validation code before touching it. Built the IAP layer as a new Swift module isolated behind a typed interface so the Obj-C layer only knew about a protocol. Shipped behind a feature flag, opened to 1 % then 10 % over two weeks. Result: IAP live on schedule, zero regressions, characterization tests caught two unrelated bugs in the legacy receipt code.
4. Designer disagreement
Situation: Designer wanted a custom blur effect requiring real-time UIVisualEffectView updates on every scroll frame. Task: Decide whether to implement as-spec’d or push back. Action: I built two prototypes — one with the spec, one with a precomputed blur — and measured battery + frame rate side by side. Showed the data to the designer and PM together, proposed the precomputed version as default with the spec version as an “iPhone Pro+” toggle. The designer kept ownership of the visual decision; I provided the constraint. Result: Shipped the precomputed version; team felt heard; battery telemetry stayed flat on launch.
5. Debugging a hard bug
Situation: 3 % of users reported the app crashing on launch after the 4.2 release. No repro on internal devices.
Task: Diagnose and ship a fix within 48 hours.
Action: I cross-referenced Xcode Organizer crash logs with the affected user device list, noticed all were iPhone 8 on iOS 16.1 only. Reproduced by installing 16.1 on an iPhone 8 from our device lab. Crash was in a force-unwrap of a CGFloat from a CGColor that returned nil only on that GPU/OS combination. Patched with safe unwrap, added a unit test exercising the code path with nil, shipped 4.2.1 via expedited review.
Result: Crash-free rate back to 99.95 % within 48 hours; the postmortem produced a team-wide rule against force-unwrapping CG types.
6. Failed project
Situation: I led a 6-month effort to migrate our app from VIPER to TCA across all features. Task: Get team consensus on architecture, port 18 features. Action: I ported 4 features myself as templates, ran weekly workshops, paired with each engineer on their first port. Six months in we’d ported 9 of 18 features but velocity on new features had dropped 30 %. I called for a retro; we found the migration cognitive load was the bottleneck, not TCA itself. I recommended freezing migrations, keeping TCA only for the ported 9, and not requiring new features to use it. Result: Project formally closed as partial success; we kept TCA where it was paying off and avoided a half-migration trap. The retro doc became required reading for future big-bang proposals on the team.
7. Staying current
Situation: I noticed our team’s Swift knowledge was 2 versions behind (we still used Result types where async/await would be idiomatic). Task: Level up the team without disrupting feature delivery. Action: I started a “Swift Friday” 30-min weekly slot — five minutes of one team member showing one Swift feature, twenty-five minutes of discussion. I curated the topics over six months: async/await, actors, macros, Observation, parameter packs. Took summary notes that became our internal wiki page. Result: New hires onboarded faster; the team adopted Swift Concurrency cleanly in our next big feature; one engineer started speaking about Swift at meetups based on what they learned.
8. Mentoring
Situation: A new mid-level engineer was struggling with PR feedback — their PRs took 8 review rounds on average. Task: Help them ship cleaner PRs without micromanaging. Action: I shadowed three of their PRs end-to-end, then we did a 1:1 where I asked them to walk me through their thinking before writing code. Diagnosis: they coded first, asked questions later. I taught them a 5-minute “design before code” habit: write the type signature + 3 test names in a comment block, get a thumbs up on the design, then code. Paired with them for 2 weeks on this. Result: Their PR rounds dropped to 2 on average; six months later they were mentoring another new hire on the same pattern.
9. Hardest bug you’ve debugged
Situation: Sporadic background-sync data corruption in a notes app — users reported notes “merging” with other notes’ content.
Task: Find the root cause.
Action: I instrumented every sync operation with os_signpost and uploaded traces from affected devices via a debug build. After a week of trace analysis I found the pattern: two BGAppRefreshTask instances were running concurrently because we’d registered the same identifier twice during an init refactor. They were both writing to the SwiftData store without coordination. Fixed by guarding registration with a single dispatch_once-equivalent, added a unit test asserting single registration.
Result: Corruption reports went to zero; the test caught a similar bug 6 months later when someone duplicated the registration during a feature flag cleanup.
10. Why this company
Situation/Task: This is the meta-question — interviewers screen for genuine fit vs résumé spray. Action: I researched your iOS team via your engineering blog (the post on your SwiftUI migration was particularly relevant — I’ve done a similar one) and noticed three engineers I respect on your team via conference talks. I’m specifically excited because [concrete reason: scale, problem domain, tech, mission]. I want to learn [specific gap] and contribute [specific strength]. Result (implied): I’d treat the first 90 days as listening + shipping one small thing to learn the systems, then take on more.
Always have two concrete reasons drawn from public material, one named team member you’d want to learn from, and one specific contribution you’d want to make.
Adaptation rules
- Use “I” not “we”. Interviewers need to know what you did. “We shipped it” is invisible.
- One story can serve multiple prompts. The chat performance story above also answers “tell me about a time you set a quality bar” and “tell me about a time you used Instruments.”
- Have 3 stories ready per dimension (technical depth, leadership, conflict, failure, learning). Total ~15 stories cover most interview prompts.
- Practice the result. Vague results (“it went better”) kill the story. Be specific: “33% reduction,” “shipped 2 weeks early,” “zero regressions.”
- Time yourself. 90 seconds is the limit. Practice with a stopwatch.
Common misconceptions
- “STAR is mechanical/robotic.” Done badly, yes. Done well, it’s invisible — the listener just hears a clear story.
- “You need a different story for every question.” No — the same 15 stories cover ~80 % of behavioral prompts with light adaptation.
- “Negative stories hurt you.” Concealed negatives hurt. Owned failures with learnings are some of the strongest answers.
- “Results must be technical.” Sometimes the result is a team change, a process improvement, or a saved relationship.
- “Behavioral doesn’t matter at senior level.” It matters more. At senior level, soft signal dominates; technical bar is assumed.
Seasoned engineer’s take
Behavioral interviews are the part most engineers under-prepare. Spend at least 25 % of your interview prep here. Write your 15 stories in a document; have someone else read them; iterate until they’re tight. The interviewer is asking themselves “Would I want this person handling a Saturday-night incident with me?” — your stories are the only answer.
TIP: Record yourself answering 5 behavioral questions. Watch the playback. You’ll cringe; that’s the point. Iterate.
WARNING: Don’t lie or embellish. Senior interviewers cross-check claims — “tell me more about that 33% number” — and inconsistency tanks the loop.
Interview corner
Junior: “What’s STAR?” Situation, Task, Action, Result — a structure for answering behavioral questions clearly.
Mid: “How do you prepare for behavioral interviews?” I write 12–15 stories covering technical depth, conflict, failure, mentoring, and ambiguity. I practice telling each in 90 seconds. I cross-reference each story against common prompts so I know which one to pull for which question.
Senior: “How does a senior behavioral interview differ from junior?” At senior level, interviewers probe for judgment and influence — how you change minds, how you handle disagreement, how you scale yourself by upleveling others. The technical depth is assumed; the questions look for leadership signals. I make sure my stories include moments of negotiation, owning failures publicly, and making decisions with incomplete information — not just “I shipped the feature.”
Red-flag answer: “I don’t really prep for behavioral, I just answer honestly.” Honesty without structure produces rambling answers and missed signals.
Lab preview
No dedicated lab. Write your own 15 stories this week. Read them to a friend on a 90-second timer. Iterate until each is sharp.