Tell me about shipping a release under a tight deadline
Model answer
Use STAR and show how you protected quality while cutting scope.
Situation. Two weeks before a marketing campaign, we still had the payments screen and push notifications unfinished for the app release.
Task. Ship a stable build on both stores in time, knowing that App Store review can take days.
Action. I proposed cutting the scope to the must-haves with the product owner and moved the nice-to-have items to a later release. I split the work with a teammate, put the risky features behind a remote flag and submitted a build for review early. I agreed on a daily checkpoint to flag risks quickly, and ran a regression pass on real devices.
Result. We shipped on the planned date with a 99.6% crash-free rate, and the flagged features were enabled gradually afterwards.
Stress negotiation of scope, early risk communication and not skipping testing.
Key points
- Negotiate scope instead of working longer hours
- Reduce risk with feature flags and early store submission
- Communicate risks early and often
- End with a measurable result
Likely follow-ups
- What did you decide not to ship, and how did you decide?
- What would you do if the store review rejected the build?
Common mistakes
- Describing heroic overtime as the solution
- Forgetting store review time in the plan