TL;DR: Choose a real launch decision you helped make. Explain the evidence behind your concern, the alternative you proposed, who decided and what happened. Include the cost of delaying or narrowing the launch, and say what you learned if the risk turned out differently than expected.
How to approach it
Introduce the launch and who depended on it, then identify the measurement that raised the concern. Explain your proposal and the alternatives you considered. Separate your contribution from the final decision, and close with the outcome and any lasting change. Aim for a short first telling that leaves room for questions.
A strong answer
Suppose a load test shows that long prompts push first-token latency beyond the launch target. The deadline is close, and the team needs to decide whether to proceed, reduce exposure or delay. This is an illustrative situation, not an experience to present as your own. Choose an actual event from your work and use only measurements you can explain.
The Reliability Pushback Story helps organize the account. Start with what made the risk concrete: the workload tested, the affected users, the observed latency or error rate, and the target it missed. A statement such as “p99 got worse” needs a population, a measurement window and enough samples to make the comparison meaningful. Latency Metrics: TTFT, TPOT and Goodput explains those boundaries.
Next, show how the concern became a proposal. A smaller rollout can be appropriate when exposure is bounded, failures are detectable and rollback works. It is not automatically safe: data loss, access violations or hard contractual limits may require fixing the issue before any exposure. Explain why your proposed route matched the failure you expected.
| Part of the account | Detail the listener needs |
|---|---|
| Evidence | Workload, measurement, source and relevant limit |
| Proposal | Scope, owner, acceptance test and stop condition |
| Alternatives | What a delay, smaller launch or immediate release would cost |
| Decision | Who had authority and what you personally contributed |
| Outcome | What actually happened, including surprises |
| Lasting change | A test, control or process that addresses the original gap |
For a numerical exercise, suppose the agreed p99 TTFT target is 500 ms and the representative test reports 1,900 ms. The ratio is 1,900 / 500 = 3.8: the test is far outside the target. A proposed rollback threshold of 800 ms is still 60% above it. Such a trigger might detect a severe regression, but it cannot be described as proof that the 500 ms target is met. State any temporary exception and who can approve it. These are hypothetical numbers; replace them with your own evidence.
Discuss the disagreement without turning another team into the villain. They may have been weighing a launch commitment or information you did not have. Describe when you shared the evidence, how they challenged it and what changed in your proposal. A story in which you revised an estimate can demonstrate judgment just as well as one in which the test confirmed your concern.
If your recommendation was overruled, explain what authority and obligations applied. For an ordinary reversible tradeoff, you may document the risk, agree on monitoring and support the authorized plan. An unresolved security, safety or compliance requirement can call for the relevant escalation or stop process. “Support the decision” is not a universal instruction to ignore a mandatory control.
SLOs for AI Systems helps connect the concern to the service's promises. A missed SLO is evidence for a decision, but it is not a universal launch veto. Likewise, a 10% slowdown in a background job may be serious if it breaks a deadline or consumes the remaining capacity. Explain the impact and reversibility that made this particular concern worth raising.
What interviewers probe next
- "Where did the number come from?" Describe the test, window, population and limitations; distinguish observation from forecast.
- "What did you ask the team to do?" Give the specific alternative, its owner and the condition for proceeding.
- "Were you right?" Report the observed outcome without turning a cautious estimate into a prediction you proved.
- "What if you had been overruled?" Describe the applicable escalation path and the monitoring or rollback you could still own.
Common mistakes
- Giving a concern without the evidence or user impact behind it.
- Calling a canary safe without checking whether the failure is reversible.
- Treating a rollback threshold above the target as compliance with that target.
- Claiming the team’s entire decision as your own contribution.
- Borrowing an illustrative story and presenting it as personal experience.
Key takeaways
- Connect evidence to a proposal, a decision, an outcome and a lasting change.
- A 1,900 ms result against a 500 ms target is a 3.8× miss in the hypothetical test.
- Narrow exposure only when the failure mode and rollback make that a justified choice.
- Explain disagreement and uncertainty honestly, including what changed your mind.