Tell me about a hard-to-reverse decision you made before the data was conclusive.
answer
- why this one could not be undone
- the bar you raised before committing
- how you bought back an escape hatch
- the confidence you stated aloud
- the review after the data landed
basics
~20 sTests whether you raise your standards for decisions you cannot walk back. Answer with a genuinely irreversible call, the higher evidence bar you set, the escape hatch you built anyway, who you invited to disagree, and the review after the facts landed.
how to answer
5 beats- the decision and why it could not be walked backSay in one or two sentences what would have had to happen to reverse it — other people rewriting code, stored data being rewritten, a promise already made. Keep the setup to roughly a fifth of your airtime.
- the higher bar you set before committingDescribe the evidence you demanded that you would not have demanded for a cheap decision, and what you deliberately did not wait for. Naming both sides shows a bar, not a stall.
- who you invited to disagreeName the roles you brought in and what you asked them to attack. On an irreversible call, deliberately recruiting a dissenter is a stronger signal than the decision itself.
- the escape hatch you built anywayExplain how you bought back some reversibility — a version marker, a staged rollout, a migration path, a deprecation window. This is the beat interviewers listen hardest for.
- the outcome and the review once data existedClose with a number and what the later evidence showed, including where you had been wrong. Roughly a quarter of your airtime, and never skip the review.
your answer
5 story prompts- List decisions of yours that other people's code or stored data now depends on.
- For one, name what would have had to happen to reverse it.
- Write the escape hatch you built, or the one you wish you had built.
- Name who you invited to argue against you, and what would have changed your mind.
- Reuse your biggest-technical-decision story here if it was genuinely hard to undo.
draft and rehearse your own answer in a learn session
go deeper
Probes risk calibration and ownership on decisions that cannot be undone cheaply. The interviewer is checking whether you can tell a one-way door from a routine choice, raise the evidence bar accordingly, invite challenge instead of avoiding it, and still commit rather than stall. A strong answer shows both nerve and the discipline that earns it.
I maintain an open-source data toolkit, and we had to fix the on-disk encoding for checkpoint files. That one is a genuine one-way door: once users have written months of checkpoints, you cannot quietly change how the bytes are laid out, because their historical files stop reading. I could not get the evidence I actually wanted, which was how people's real datasets are shaped. So I raised a different bar instead. I benchmarked three candidate encodings against a forty-one-million-row synthetic sample built from the shapes users had posted in issues, and I refused to commit until I understood how each one handled decimals, because money columns are where mismatches hurt. Two of the three disagreed with our reference totals by 1.4 points on decimal aggregates. That settled the choice more cleanly than any benchmark did. Before committing I asked the two maintainers most likely to object to try to break the proposal, and one of them found a case I had missed with very wide sparse rows. Then I bought back what reversibility I could. Every checkpoint we write carries a format marker in its header and the reader accepts the older layout indefinitely, so a future change is a migration rather than a break. We shipped it, and adoption ran ahead of what I expected. When enough real files existed, I went back and measured: the sparse case my reviewer flagged was about three percent of files, and it cost us storage, not correctness. I documented it rather than reopening the format.
The one-way door is real, and the answer treats it as one: a raised evidence bar, a dissenting reviewer recruited on purpose, and a format marker that converts a break into a future migration. The closing review with a measured number is what turns confidence into calibration. Without the escape hatch this would read as a lucky bet.
I chair the technical steering group for an open-source data ecosystem, and we carried four supported ingestion paths across the project and its plugins. Consolidating to two was effectively irreversible: fourteen known downstream forks had already built on those interfaces, and once we stop shipping a path, the forks diverge and never come back. We did not have the usage data that would have made the choice obvious, and no amount of waiting was going to produce it. So I changed what we required instead of what we knew. I put in a rule for this class of decision: anything that forks the ecosystem needs a written record with numbered assumptions, a named engineer whose job is to argue the other side, and a first step that is recoverable. Nobody commits the whole path at once. For this one, the recoverable first step was freezing the two weaker paths rather than removing them, and publishing the reconciliation evidence: those two disagreed with the primary path by 1.9 points on aggregate totals under late-arriving data, which was the substantive argument for consolidation and the thing maintainers could check themselves. We held the freeze across two release cycles before removing anything. Three forks raised objections in that window, two of which we accommodated by extending one interface. Eleven of the fourteen had migrated before removal. The durable outcome is not the consolidation. It is that the decision record and the assigned dissenter are now how this project handles anything it cannot take back.
Scope is the ecosystem, and the answer sells a mechanism rather than a heroic call: a decision record with numbered assumptions, an assigned dissenter, and a recoverable first step. Freezing before removing is the staged commitment that makes an irreversible decision safe to start. The migration count keeps it from being pure process talk.
You may not own a truly one-way decision yet, and pretending otherwise reads badly. Use the largest call you genuinely made, be honest about who owned the irreversible part, and show you flagged the cost before it was committed.
A feature-scope decision that other people's code came to depend on is enough. Show you recognised the reversal cost before committing and did something concrete about it — a migration path, a version marker, a staged rollout.
This is your rung. Expect user-visible or data-shaped stakes, a deliberately raised evidence bar, a named dissenting reviewer, and an escape hatch you built on purpose. Close with the review you ran once the data existed.
Speak about the class of one-way doors, not one of them: how the organization identifies them, what evidence it demands before committing, and the staged path that keeps the first steps recoverable. One incident illustrates the mechanism.
saying these in an interview costs you the question
- Calling a routine reversible choice irreversible to make the story sound weighty
- No escape hatch considered — only confidence that the call was right
- Deciding alone when a dissenting reviewer was available and cheap
- No follow-up once the real numbers arrived
- Blaming missing data for a bad outcome instead of owning the judgment
- A confidence claim with no evidence behind it and no worry named
- How did you decide the risk was worth taking?Compare it against the cost of not deciding — delay is a decision with its own price. Name what waiting would have cost in concrete terms, and the ceiling you put on the downside, so the risk sounds bounded rather than accepted.
- Who could have talked you out of it?Name a real person by role and the argument that would have worked. This shows the decision was open to challenge. If nobody could have, you are describing a decision you had already made before you consulted anyone — say what you would change now.
- What would you do differently if you faced that call again?Give one specific change, ideally to the process rather than the outcome: an earlier check, a smaller first step, a different reviewer. Avoid answering that you would do it identically — this probe is asking whether the decision taught you anything.