Tell me about a decision you had to make without all the information you needed.
answer
- name the call and the missing fact
- how long you let yourself look
- the assumptions you wrote down
- reversible path chosen on purpose
- what the real data showed later
basics
~20 sTests judgment under uncertainty, not luck. Answer with one real call: the fact you were missing, the timebox you set, the assumptions you wrote down, why the path you chose was cheap to undo, and what the later data showed.
how to answer
5 beats- the call you faced and the fact you were missingTwo or three sentences, no more — this and the stakes should take about fifteen to twenty percent of your airtime. Name the decision in plain terms and the single piece of information you could not get, and say why you could not get it.
- what being wrong would have costState whether this was cheap to undo or hard to walk back, and say it in the same words you used at the time. This one sentence is what tells the interviewer your speed was a choice rather than an accident.
- how you bounded the search and what you assumedThis and the next beat carry roughly sixty percent of the answer. Give the timebox you set in advance, where you looked, and the assumptions you wrote down somewhere others could challenge them.
- the decision you made and who you toldSay the option you picked, the confidence you had, and the condition that would have reversed you. Naming the people you informed shows the decision was visible, not private.
- the result, and what the later data showedClose with a number and an epilogue — about twenty to twenty-five percent of your airtime. Say what happened when the real information finally arrived, including the part where you were wrong, if you were.
your answer
5 story prompts- Pick a decision YOU made, not one you watched, ideally within the last 18 months.
- Name the one fact you were missing and could not get in time.
- Write down the timebox you set and whether you actually honoured it.
- Find the number your decision moved, before and after.
- This can be your changed-requirements story re-angled around the missing fact.
draft and rehearse your own answer in a learn session
go deeper
Probes judgment and ownership under uncertainty. The interviewer wants to see whether you can act without complete facts while keeping the decision honest: bounding the search, sizing the cost of being wrong, recording assumptions, and revisiting once evidence arrives. A strong answer proves decisiveness and intellectual honesty in the same story.
I contribute a connector to an open-source data pipeline project, and the maintainers were assembling the next release. My connector's nightly rollup disagreed with the upstream export it is supposed to mirror — a reconciliation gap of 1.8 percent on row totals. I could not tell whose bug it was, because the only material I had was sample dumps that community users had attached to issues. There was no real source system I could query. So I bounded it. I gave myself two working days to reproduce the gap, and I wrote in the issue what I would do if I failed: ship the connector opt-in and off by default rather than hold it or make it the standard path. That mattered to me because opt-in is easy to walk back — nobody's numbers change unless they choose it — whereas making it the default would have quietly moved figures in other people's dashboards. I did not reproduce it. So I posted the three assumptions I had been working from, marked the connector experimental in its README with the gap stated in plain numbers, and asked for reports. Two adopters ran it and came back within eleven days. Their traces showed the upstream export truncates timestamps to local midnight while I was bucketing in UTC. Fixing my bucketing brought the gap down to 0.06 percent, and the connector became the standard path in the following release. The thing I would keep is publishing the gap instead of hiding it. That is what got me the traces.
The signal is in the third and fourth beats: a timebox set in advance, a fallback declared before the search failed, and a deliberately reversible choice with the reason said out loud. Publishing the known gap turns a weakness into an evidence-gathering move. It would downlevel if the assumptions had stayed in his head or the answer stopped before the later data arrived.
I own the export layer of an open-source analytics library. We carried two export paths, a wide-table writer and a normalized one, and they disagreed: users kept filing issues about a reconciliation gap of around 2.3 points between them whenever a run had late-arriving rows. I wanted to delete the wide-table path in the coming release, and I had no way to learn how many people depended on it, because an open-source project has no usage telemetry. The honest position was that I would never get that number, so I bounded the search instead of chasing it. One week, three sources: a code search across sixty-one public repositories that depend on us, a note in the release-planning thread, and a direct message to the four largest downstream forks. Nine of the sixty-one referenced the wide-table writer. Then I wrote the decision up before I made it. The assumption that those sixty-one repositories were representative. The confidence I actually had, which was about seventy percent. And the condition that would reverse me: more than a handful of maintainers reporting the converter did not cover their layout. I cut the path and shipped a converter script in the same release. Two projects opened issues, and both converted in under a day. With one writer left there was nothing to reconcile, and export-mismatch reports went from a steady trickle to none over the following quarter. What I would repeat is naming the reversal condition aloud. It made the cut feel cheap rather than final.
Feature-scope ownership plus a decision made in the open: a bounded three-source search, a stated seventy-percent confidence, and a written reversal condition, all recorded before the outcome was known. The converter is the move that made a scope cut affordable. Removing the reversal condition or the sixty-one-repository sample would leave a confident guess.
Own one task-level call and show you did not freeze. Naming the missing fact, setting yourself a small timebox and asking for help before the timebox ran out is a passing answer at this rung.
Show the decision affected a feature or teammates, and that you chose deliberately between a cheap-to-undo option and an expensive one. Interviewers want the written assumption and the condition that would have reversed you.
Expect production or user-visible stakes, a stated confidence level, and the people you brought in before committing. Add what you changed afterwards so the same class of decision is faster next time.
Talk about the decision as a class, not an incident: how you set the bar for when the org commits, who is allowed to decide at what confidence, and where the assumptions are recorded so they can be revisited.
saying these in an interview costs you the question
- Waiting for perfect data and presenting that delay as rigor
- No timebox — an open-ended investigation that never becomes a decision
- Assumptions never written anywhere, so nobody could challenge them
- No sense of the cost of being wrong, so every decision gets the same care
- The story ends at the decision with no outcome and no number
- Claiming the call was right without saying what later evidence showed
- How did you know when to stop investigating?Give a stopping rule, not a feeling. Say what you had bounded — hours, a fixed set of sources, a question you were trying to answer — and what you had planned to do if the search failed. If your real reason was a deadline, say so plainly and add the rule you would use now.
- What would you have needed to know to decide differently?Name one concrete fact and the threshold attached to it. This is where you prove the decision was reasoned rather than guessed. Avoid answering that nothing would have changed your mind — that reads as stubbornness, not confidence.
- What did you do when the real data arrived?Show a revisit, not a defence. Say who you told, how fast you corrected, and whether the correction was cheap because of how you set the decision up. If the data proved you right, still say what you were prepared to do if it had not.
## What the interviewer is really testing This prompt separates two candidates who look identical on a resume: - the one who treats missing information as a reason to **stall and escalate** - and the one who treats it as a **normal condition** of engineering work. Nobody in this job ever has complete information. The interviewer wants to hear a **decision procedure** — a way of turning an uncomfortable gap into a bounded, recorded, revisitable choice. ## Common wordings You will meet this prompt as: - "Tell me about a decision you made without enough data" - "Describe a time you had to act on incomplete information" - "Walk me through a judgment call you made under uncertainty" - and the compressed screener form "How do you handle not knowing?" They are one question. The only wording that changes your answer is the one that adds a constraint — "and you could not ask anyone", or "and it was expensive to undo" — which asks you to lean harder on, respectively, the assumptions beat or the reversibility beat. ## The single move that most improves a weak answer Say out loud **what it would have cost to be wrong**. Weak answers describe the uncertainty and then jump to a choice, leaving the interviewer unable to tell whether the candidate was brave or reckless. Strong answers classify first: - this was cheap to undo, so I decided fast and moved on; - or this would have changed data other people already stored, so I bought myself more evidence before committing. The classification is the signal. The choice is just what follows from it. ## Evidence that lands Four kinds, roughly in descending order of value. 1. **First, a timebox** you actually set in advance and stuck to — "three days, then I decide with what I have". 2. **Second, an assumption written somewhere other people could see** and argue with; a sentence in a pull request or a planning ticket is worth more than a paragraph of recollection, because it proves the assumption existed before the outcome was known. 3. **Third, a reversal condition**: the specific thing that would have made you back the decision out. 4. **Fourth, a number in the result**, and ideally the same number before and after, so the interviewer can size the effect without taking your word for it. ## The airtime trap Uncertainty stories invite long setups, because explaining why the information was missing feels necessary. It usually is not. Two or three sentences establish the gap. If you find yourself explaining a data model for ninety seconds, you have written a systems-design answer with a decision bolted on the end. Keep the setup under **a fifth of the runtime** and spend the bulk on what you did. ## How the bar moves with seniority - **At the junior rung** the interviewer wants to see that you did not freeze and did not silently guess: a small timebox and a question asked before the timebox expired is a complete answer. - **At mid level** they want deliberate choice between options with different reversal costs, and evidence that you told someone what you were assuming. - **At senior level** the decision should touch production or users, carry a confidence level you stated at the time, and end with a change to how the next such decision is made — a template, a default, a review step. - **At principal level** the incident becomes an illustration of a mechanism: who decides at what confidence, where decision records live, and how the organization notices when a recorded assumption turns out false. ## What sinks otherwise good answers Two failure modes recur. 1. **The first is the hero who decided alone** when consultation was cheap and available; decisiveness is not the same as isolation, and interviewers hear the difference. 2. **The second is the answer with no epilogue.** If more data eventually arrived and you never say what it showed, the interviewer is left assuming you never checked — which is exactly the habit this prompt is designed to detect.