How do you know when you have enough information to make a call?
answer
- reversible or hard to undo, first
- the timebox you give yourself
- assumptions written where others can argue
- the trigger that reopens the decision
- one short example, not a lecture
basics
~20 sTests whether you have an actual decision rule rather than a mood. Answer with the rule — cost of reversal first, then a timebox, written assumptions, and a revisit trigger — and prove it with one short decision you ran through it.
how to answer
5 beats- the sorting question you ask firstOpen with the rule itself in one sentence — usually how expensive this decision is to undo. Leading with the rule rather than a story tells the interviewer you have thought about this before the room.
- the box you put around the searchGive a concrete bounding habit: hours or days, a fixed set of sources, and what you commit to doing when the box expires. Say that the timebox is set before the search starts, not after it stalls.
- what you write down before you commitDescribe the assumption and the confidence going somewhere other people can argue with them. Emphasise that a written assumption is what makes the decision correctable later by someone who is not you.
- the trigger that reopens itName the condition or signal that would make you revisit, and where it is recorded. This is the beat most candidates skip, and it is the one that separates a decision from a guess.
- one short example of the rule workingThirty to forty seconds, with one number. The example is proof the rule is real, so keep it compressed and resist turning it into a full story with setup and cast.
your answer
4 story prompts- Write your actual rule in one sentence before you look for an example.
- Pick one decision you deliberately made fast and one you deliberately slowed down.
- Find an artifact — a ticket, a review comment — where you wrote an assumption down.
- Prepare one decision where your rule misfired, for the inevitable follow-up.
draft and rehearse your own answer in a learn session
go deeper
Probes decision-making judgment as a repeatable habit rather than a single lucky outcome. The interviewer wants to hear how you size the cost of being wrong, bound the time you spend investigating, and make your reasoning inspectable. A strong answer states a rule in one sentence and then proves it with a decision that actually ran through it.
My first question is never how much information I have. It is what happens if I am wrong. If I can undo the thing inside a week and nobody outside the repository notices, I decide quickly on partial evidence and treat it as an experiment. If undoing it means other people editing their code or rewriting data they have already stored, I slow down and go looking. On the open-source data project I work on, that came up when our aggregation layer was producing totals users kept disputing. I gave myself a three-day spike to choose between patching it and rewriting it. Three days was nowhere near enough to know the rewrite would work, but it was enough to learn two things: the patch closed the disputed gap, taking it from 2.9 points to under a tenth of a point, and the rewrite's real benefit was speed, not correctness. Correctness was what people were filing issues about, so I patched, and I noted in the thread that the rewrite stayed open if speed complaints ever outgrew the correctness ones. The other half of my rule is that the assumption goes somewhere it can be argued with. If I am assuming most deployments run under a million rows a night, that sentence goes in the pull request description. Roughly half the time someone corrects me within a day, which is far cheaper than the research I would otherwise have done.
The rule leads and the example proves it, in that order, which is what this prompt rewards. The strongest move is treating a public assumption as a cheaper substitute for research. It would downlevel if the spike had no fixed length or if the answer stayed abstract with no disputed number attached.
I sort decisions into two piles and treat them differently on purpose. Most are cheap doors: I decide at the first defensible answer, write the reasoning in a couple of lines, and move. The expensive pile is anything that changes a file format, a public interface, or numbers people have already stored. For that pile I have three requirements, and they are the same every time. First, a written proposal with the assumptions numbered, so a reviewer can attack an assumption instead of attacking me. Second, an explicit confidence — I will say I am at seventy percent and name the thirty percent that worries me, because a stated number invites correction in a way that a confident tone does not. Third, someone who is not me and is likely to disagree. We hit that pile when I proposed dropping one of two storage backends from the roadmap. Two of the six maintainers pushed back, which was the point of asking. What settled it was not opinion: the two backends disagreed by 0.7 points on aggregate totals for decimal columns, and only one of them matched what users independently computed. I committed at that, with a deprecation window spanning two releases so anyone caught out had a path off. The part I have added over time is the revisit. Every expensive decision leaves behind the condition that would falsify it, and I actually go back and look when the condition can be measured.
The senior signal is in the seams: a stated confidence figure offered aloud, deliberately recruiting a dissenter, and a deprecation window that buys reversibility on an otherwise expensive call. Letting evidence rather than seniority settle the maintainer disagreement is what makes it credible. Dropping the revisit habit would flatten it.
It is fine for your rule to be small: ask early, timebox yourself, and escalate before the box runs out. Show you have a habit rather than improvising each time, and back it with one decision from real work.
Your rule should distinguish cheap-to-undo from expensive-to-undo work and show up in artifacts — a note in a pull request, an assumption in a ticket. Attach a thirty-second example so the rule is not theoretical.
Show the rule applied to production risk: who you consult on the expensive class, what confidence you commit at, and how you leave an escape hatch. Mention a case where the rule misfired and what you changed in it.
Talk about the rule as something other people run, not just you: where decision records live, what confidence the organization commits at for different classes, and how a wrong assumption gets caught and revisited.
saying these in an interview costs you the question
- An abstract process answer with no decision attached to it
- Naming a framework without saying what it changed in practice
- Claiming you always gather all the data before deciding
- Treating every decision with the same weight regardless of reversal cost
- Deciding by seniority or gut with nothing written down anywhere
- No revisit step, so the rule never learns from being wrong
- Can you give me an example where that rule led you wrong?Take it — refusing makes the rule sound untested. Pick a case where you decided fast on something you had misclassified as cheap, say what the misclassification cost, and name the check you added afterwards. One sentence of consequence beats three of self-criticism.
- Who else do you pull in before a decision like that?Name roles and the trigger for involving them, not a blanket habit of consulting everyone. Show you distinguish between informing people and asking permission, and that on expensive decisions you actively look for someone who would disagree with you.
- What if you are wrong and nobody notices for months?This probes whether your rule has a detection half. Talk about the signal you attach to the assumption — an alert, a metric you watch, a scheduled revisit — so being wrong surfaces on its own rather than waiting for a complaint.