Tell me about a decision you had to make in minutes, with information you knew was incomplete.

A different skill from planning under ambiguity

Ambiguity spread over a quarter rewards writing assumptions down and sequencing by reversibility. Ambiguity compressed into ten minutes rewards something else, and this question is aimed at the second thing: how you behave when there is no time to consult, when the data is partial and will stay partial, and when not deciding is itself a decision costing money every minute.

Two opposite failures show up. One is the candidate who deliberated — gathered more data, asked three people, waited for a dashboard to refresh, and let a five-minute problem become a forty-minute one. The other acted decisively and cannot articulate why that action rather than another, which reads as luck, and luck does not transfer to the next incident.

Say what the clock was

The first thing to establish is the rate. An urgent situation without a stated cost of delay is indistinguishable from a candidate who panics, so quantify what each minute of waiting was doing: orders failing, money moving in the wrong direction, data being written that would have to be unpicked, customers being told something untrue. "We were selling seats we did not have, at roughly forty a minute" tells the interviewer that speed was rational. "It was really urgent" does not, and invites the follow-up about what would have happened if you had waited.

The corollary is worth saying out loud too: sometimes the honest answer is that the clock was slower than it felt, and the right move was to take twenty minutes. Candidates who can distinguish real urgency from ambient pressure are unusual and it shows at senior level.

Sort the options by whether you can undo them

The single most useful move under time pressure is to ask which of the available actions you can reverse. When the information is bad, prefer the option whose failure mode is recoverable, even if it is not the option that would be best if you were right.

Option	Reversible?	What it costs if you are wrong
Turn the feature off behind its flag	Yes, seconds	Some revenue for the duration
Stop the queue consumer, let the backlog build	Yes, if the queue retains long enough	Delay, plus a replay to manage
Roll back the deployment	Mostly	Loses an unrelated fix in the same release
Cancel and refund the affected orders	No	Contactable customers annoyed for nothing
Truncate and reload the inventory table from the source	No	If the source is the broken thing, the data is gone

Reading a table like that in the moment is what separates twenty minutes of damage from two days, and it reframes the question: often you are not choosing the fix at all, you are choosing the cheapest way to stop the bleeding while you find out what is true.

Authority, and being honest about it

Interviewers listen carefully to whether you acted inside your remit. A strong answer either names the authority you had — the on-call engineer can disable any flag without approval, and that was written down — or names the person you woke up, at what time, and what you asked them for. Refunding customers, sending a mass email or deleting data are rarely an engineer's call at any level, and a candidate who took one alone because it felt heroic, without noticing that this is the problem, has answered the question badly.

The shape that reads best is a split: take the reversible containing action immediately on your own authority, and escalate the irreversible commercial decision with a recommendation attached. That is defensible in every direction, including the one where you turned out to be wrong.

Write it down while it is happening

A running timeline in the incident channel — timestamp, what you observed, what you did, what you believed at the time — costs almost nothing and does two things. During the incident it stops the fourth person who joins from re-asking everything. Afterwards it is your only defence against being judged on what became obvious later, since the fair question at review time is whether the decision was sound on the information available, and only a contemporaneous record answers that.

A pattern to adapt, not to memorise

"We ran ticketing for live events, and about six minutes into a stadium show going on sale I noticed the sold count for one seating block was climbing past the block's capacity. We were selling roughly a hundred and fifty seats a minute overall, so whatever was wrong was getting worse fast, and I did not know whether it was a display bug in the count or a genuine oversell.

I did not have time to find out, so I picked the reversible thing. The block was configurable, so I closed sales on that one block only, which took about fifteen seconds and left the rest of the event selling. If the count turned out to be a display bug, I had cost us a few minutes of sales on one block and could reopen it. If it was real, I had stopped it. I posted in the incident channel what I had seen and what I had just done, with the time, before doing anything else.

It was real: a caching layer in front of the inventory service had been serving a stale remaining count for that block for a little under two minutes, and we had sold about ninety seats too many.

The next decision was not mine and I did not treat it as mine. Cancelling or upgrading ninety customers is a commercial and reputational call, so I paged the duty commercial lead at half past nine on a Friday, gave her the number, the two options our systems could actually support, and a recommendation that we upgrade rather than cancel because the block above had unsold capacity. She chose that, and it went out from the support team rather than from engineering.

Two things I would do differently. I should have closed the whole event for the ninety seconds it would have taken to check, because the cache was shared and other blocks were exposed to the same fault — I got lucky that they were selling more slowly. And we had no alert on sold count exceeding capacity, which is a comparison of two numbers we already had. That alert existed by the following week and has fired twice since, both times before a human noticed."

What that answer supplies: a rate, a reversible first action taken inside authority, an irreversible decision escalated with a recommendation, a written timeline, and a self-criticism about the containment being too narrow rather than the decision being too fast.

When the call went badly

Have a version of this story where you were wrong, because it is a common follow-up and the improvised answer is usually defensive. The way to tell it is to separate the decision from the outcome. Given the information available, the reasoning may still have been sound, and the honest finding is often about the information rather than the judgement: the signal you needed existed somewhere and you could not reach it in time, or the reversible option you did not know about was sitting in a runbook nobody had read. Both are fixable and both are more interesting than an apology.

Under a real clock the question is rarely which fix is correct — it is which action you can undo, taken at the level you are actually authorised to take it, with the reasoning written down while it is still what you believed.