Tell me about a time you pushed back on a launch because of a reliability concern.

TL;DR: A pushback story is scored on four things and almost nothing else. The evidence, meaning the number that made you worried and where it came from. The ask, meaning the specific smaller thing you proposed instead of the launch, because "delay it" is a position and "launch to 5% behind a flag with an automatic rollback on error rate" is an engineering proposal. The outcome, including whether you were right, since a story where you were wrong and said so is stronger than one where you were vindicated. And the change, meaning what is different now so the same argument does not have to happen again. Most candidates give the concern and the outcome and skip the ask, which is the half the interviewer is actually there to hear. Bring one story with numbers in it, know the numbers cold, and be ready for the follow-up that asks what you would do if you were overruled.

How to approach it

Open with the launch and the concern in one sentence each, then give the number that made it a concern rather than an opinion. Then the alternative you proposed, in the form of a specific plan with a threshold. Then what happened, then what changed. Keep the whole thing near two minutes and let the interviewer pull on whichever thread interests them, because the follow-ups are where the level is decided.

A strong answer

A typical situation: a serving team is a week from launching a new model version. A platform engineer notices during the load test that the p99 time to first token doubles when the request mix includes long prompts, and the launch plan has no way to route around that. The concern is real, the deadline is public, and the model team has been working toward this date for two months.

What separates the two versions of this story is entirely in the second beat:

The right-hand column is not a better outcome. It is the same outcome described by someone who did the work of turning a worry into a proposal. That is the whole difference, and it is learnable.

Where the numbers come from matters as much as the numbers. Saying p99 doubled is a claim; saying it came from a load test at 1.4x expected peak with a production prompt-length distribution is evidence. The interviewer will often ask exactly that: how did you know. Latency Metrics: TTFT, TPOT and Goodput covers which number to quote for which symptom, and SLOs for AI Systems covers why an SLO breach is a launch blocker while a p50 regression usually is not. The Reliability Pushback Story goes deeper into the structure and the failure modes of the story itself.

Three follow-ups arrive almost every time, so prepare them rather than improvising:

"What if you had been overruled?"
  the answer that works: name what you would have asked for anyway. A rollback plan you
  own, a dashboard the launch owner watches, and a written note saying what you expect to
  break and at what threshold. Then support the launch.
  the answer that fails: "I would have escalated." Escalation is a step, not a plan, and
  answering with it alone reads as someone who has never had to live with a decision.

"How did the model team take it?"
  the answer that works: you brought them the number before you brought anyone else the
  number. The story where the concern reached a director before it reached the team that
  owns the code is a story about politics, and it is scored that way.

"Were you right?"
  the strongest version is a story where you were partly wrong. The rollback fired once,
  not the six times you predicted, which means your estimate was pessimistic and you say
  so. Candidates who have never been wrong in any story are not believed.

The reversal condition: not every reliability concern is worth a pushback, and a candidate who pushes back on everything is a different problem from one who never does. The test is whether the failure is user-visible and whether it is reversible. A regression that degrades a background batch job by 10% is neither urgent nor irreversible, and raising it as a launch blocker spends credibility that the next real one needs. Say that out loud in the interview if you have an example of choosing not to escalate, because it shows the judgment rather than the reflex.

What interviewers probe next

• "What was the SLO, exactly?" Have the number and its window. An SLO without a measurement window is not an SLO, and the follow-up exists to find out whether you have ever owned one.
• "Who made the final call?" Name the role and say you supported the decision afterward. The story where you kept relitigating it is the one that fails.
• "What would you have missed if you had not run that load test?" This asks whether the catch was systematic or lucky. If it was lucky, say so, then say what you changed to make it systematic.
• "Have you ever been the one who wanted to launch?" A yes with a real example is a strong signal, because it shows you understand the cost of the delay you asked for.

Common mistakes

• Giving the concern without the number, which leaves the interviewer unable to tell a judgment call from a feeling.
• Proposing only a delay, when the useful move is a smaller launch with a threshold and a rollback.
• Ending at the outcome and skipping what changed, so the story has no organizational result.
• Telling it as a story where you were right and everyone else was slow, which reads as difficult to work with.
• Choosing an example where the stakes were trivial, so there was never a real disagreement to describe.

Key takeaways

• Four beats: the evidence with its number and source, the specific alternative, the outcome, the change that outlasted it.
• "Launch to 5% behind a flag with an automatic rollback at 800 ms p99 for five minutes" is a proposal; "delay it" is a position.
• Bring the number and where it came from, because the first follow-up is almost always how you knew.
• A story where your estimate was pessimistic and you say so is stronger than one where you were exactly right.
• Know one example of a concern you chose not to escalate, since that is what proves the judgment.