Deciding Under Incomplete Information

TL;DR: Classify first, then decide. A decision you can undo cheaply should be made fast on partial evidence, because the cost of being wrong is the cost of undoing it and that is usually smaller than the cost of waiting. A decision you cannot undo deserves the delay, the extra evidence and someone else's eyes. Then attach a trigger rather than a date: a specific observation that would tell you the call was wrong, with an owner and a deadline. Separating decision quality from outcome quality is the second half of the skill, because a well-made decision can turn out badly and a lucky guess can turn out well, and interviewers listen for whether you can tell those apart about your own work.

The classification, and why it comes first

The question that orders everything is what would still be different if you reversed this in an hour. If the answer is nothing, the decision is reversible and the bar for evidence is low. If the answer includes anyone else's state, it is one-way, and the bar rises.

That test is sharper than it first appears, because several things that look undoable are not. A configuration change that clients cache for a week cannot be pulled back inside that week. A deletion of anything is permanent. A public communication cannot be unsent. A schema migration that has already been read by another service has propagated. In each case the mechanical action has an undo button and the decision does not.

Writing the cost of waiting next to the cost of being wrong

Most decisions that feel like they need more information become tractable the moment both costs are written down. The cost of being wrong is usually bounded and estimable: two teams lose a feature for three days, a rollback takes one deploy, a customer sees a slower response. The cost of waiting is often larger and is almost never written down, because nothing visibly happens while you wait.

An engineer who says "the rollback costs two teams three days of features, and every hour we wait costs the customer their latency objective" has converted a judgment call into a comparison. Interviewers listen for exactly that conversion, because it is what separates someone who is comfortable deciding from someone who is comfortable deferring.

The trigger, which is what makes it a decision rather than a guess

A decision under uncertainty needs a stated observation that would prove it wrong, an owner, and a deadline. A date alone produces a meeting; a trigger produces an action.

The trigger has a second effect that is worth naming: writing it forces you to say what your theory predicts. "If p99 has not improved by 30 percent within 48 hours, the fragmentation theory is wrong and we look elsewhere" commits you to a falsifiable claim, which is the same discipline that stops a wrong root cause from surviving for a week.

The trigger is also what connects this to the story an interviewer hears later. The Reliability Pushback Story covers the shape of that story, and the trigger is the beat inside it that distinguishes a considered call from a guess that happened to work.

The record also matters later. When the predicted problem does arrive, having written it down in advance turns "I told you so" into "the case we wrote down is now happening twice a week, here is the data". The first ends your influence on the next decision and the second extends it.

Decision quality is not outcome quality

A decision can be well made and turn out badly, and interviewers are specifically listening for whether you can hold that distinction about your own work. The strongest version of a story here is one where the call was wrong, the trigger caught it in 48 hours, and you would make the same call again with the same information. That sentence demonstrates the separation better than any successful outcome does.

Candidates whose stories all end well are either describing small decisions or telling an edited version. Both readings are worse than a story that includes a bad outcome and a sound process, which is why the ones that survive follow-up questions tend to be the ones that did not go to plan.

What interviewers are listening for

The word reversible, or its equivalent, said out loud. After that, the two costs written next to each other, and a trigger rather than a date. The last thing they listen for is whether the candidate can describe a decision that went badly without either defending it or disowning it, because that is the behaviour they are actually hiring, and it is rare enough that hearing it usually settles the round.

Key takeaways

• Classify by reversibility before deciding; the test is whether anything would still be different if you undid it in an hour.
• Several mechanically undoable actions are one-way: cached configuration, deletions, public communications, and anything another service has read.
• Write the cost of being wrong next to the cost of waiting, which makes most of these tractable.
• Attach a trigger with an owner and a deadline, not just a review date, because a trigger forces a falsifiable prediction.
• Separate decision quality from outcome quality, and be able to say you would make the same call again.