Tell me about a recent hard technical decision.
What is being assessed
The scale of the problems you are trusted with and your reasoning: can you see options, name trade-offs and own compromises. A "perfect" story with no downsides sounds implausible — numbers and honesty are valued more.
Structure: STAR
- S (Situation) — context: product, team, constraints.
- T (Task) — your task and why it was hard.
- A (Action) — the options you considered, each one's trade-offs, what you chose and why, what you personally did.
- R (Result) — a measurable outcome and what you would do differently.
Example answer
S: A food-delivery app, four iOS developers. The cart screen was slow on older iPhones, and product wanted to add recommendations to it.
T: I had to decide whether to rewrite the screen in SwiftUI or optimise the existing UIKit one, three weeks before a release.
A: I weighed three options: targeted UIKit optimisation (fast, but the debt stays), a full move to SwiftUI (clean, but a schedule risk and an iOS 15 minimum), or a hybrid — SwiftUI for the new recommendations block inside UIHostingConfiguration. Instruments showed 70% of the time went into cell layout recalculation. I chose the hybrid: removed the recalculation with a height cache and wrote the new block in SwiftUI so we would not grow the UIKit code.
R: Render time dropped from 48 to 11 ms and the release shipped on time. The downside was two technologies on one screen; two releases later we moved it to SwiftUI entirely. Today I would measure before discussing options, not after.