Skip to main content
  1. Behavioral Interviews - 170+/

Describe a Situation Where You Had to Make a High-Stakes Decision With Incomplete Information

Lakshay Jawa
Author
Lakshay Jawa
Sharing knowledge on system design, Java, Spring, and software engineering best practices.
Table of Contents
Leadership - This article is part of a series.
Part : This Article

S1 — What the Interviewer Is Really Probing
#

The exact scoring dimension is judgment under uncertainty — the interviewer is not testing whether you made the right call. They are testing whether you have a structured mental process for making consequential decisions when the information needed for certainty either doesn’t exist yet or can’t be obtained in time. This is the difference between a leader and an analyst: analysts wait for completeness; leaders learn to act on enough.

At the EM level, the bar is personal decision-making discipline. Did you explicitly separate what you knew from what you didn’t? Did you name the cost of waiting, not just the risk of acting? Did you pick the right people to consult under time pressure and consciously skip the ones who would slow you down? The interviewer wants to see cognitive structure, not heroics.

At the Director level, the bar shifts from personal judgment to organisational judgment. A Director is expected not only to make the call but also to build the conditions in which their teams can make similar calls without escalating. The question becomes: did you communicate confidence without false certainty? Did you set tripwires — leading indicators that would tell you within hours whether you were wrong? Did you design the decision to be reversible wherever possible?

The bar at Director: “An EM who makes a high-stakes decision is judged on the quality of their process. A Director who makes a high-stakes decision is judged on whether they built an organisation that could survive being wrong.”

The failure mode that makes answers forgettable is low-stakes laundering — picking a decision with easy reversibility (a sprint trade-off, a library upgrade) and calling it high-stakes. Or narrating the outcome without naming what information you chose not to wait for and why. The upgrade most candidates miss: explicitly quantifying the cost of delay. Waiting for more information had a price. Strong answers name that price and show you weighed it deliberately.


S2 — STAR Breakdown
#

flowchart LR
    A["SITUATION\nHigh-stakes trigger\nwith a ticking clock"] --> B["TASK\nDecision required before\ncertainty is possible\nWho is the DRI?"]
    B --> C["ACTION 60-70%\n1. Map knowns vs unknowns\n2. Time-box consultation\n3. Name option not taken\n4. One moment of doubt"]
    C --> D["RESULT\nOutcome + one metric\nWhat you'd watch for now\nGenuine reflection"]

Situation (10%): Establish stakes explicitly — revenue on the line, safety, compliance exposure, or people. Name the deadline that made waiting untenable. “We had 30 minutes before the contest lock-in window” lands better than “we had a tight timeline.”

Task (10%): Clarify your decision rights and the decision type. Were you the DRI or advising someone who would decide? Who was waiting on you, and what happened to them while you deliberated?

Action (60–70%): This is the entire answer. Structure it around three moves: (1) rapidly mapping what you knew from what you didn’t, naming both with equal discipline; (2) the consultation you did and the one you didn’t have time for — this shows you understand what you were giving up; (3) the specific option you chose and — critically — the specific alternative you rejected and why. Use I not we. Include one genuine moment of doubt: “I wasn’t sure this was reversible. That worried me.” It’s a quality signal, not a weakness.

Result (10–20%): One metric. Then genuine reflection: what turned out to be true that you didn’t know going in, and what piece of information — if you’d had it — would have changed your call.


S3 — Model Answer: Engineering Manager
#

Domain: Real-money gaming — IPL contest deposit window

[S] It was the evening of an India vs. Pakistan IPL match — our single highest-traffic window of the year. At T-minus 35 minutes before contest lock-in, our alerting fired: our primary UPI payment aggregator was returning a 12% failure rate on deposit transactions, up from a baseline of 0.4%. At that moment, roughly 60,000 users were actively in the deposit funnel. The aggregator’s status page showed “investigating.” No ETA.

[T] I was the on-call engineering manager and the de facto DRI for payment infrastructure decisions on match nights. My call was whether to cut over to our backup aggregator — which had been configured six weeks earlier but had never been load-tested above 3,000 concurrent sessions — or hold and give the primary aggregator time to self-heal. Finance had already escalated; the head of product was asking for a decision in five minutes.

[A] I had 90 seconds of data to work with. What I knew: the primary aggregator’s failure rate was trending up, not stable; our last load test on the backup handled 3,000 sessions without issue; peak contest windows routinely hit 15,000 concurrent deposit attempts in the final 20 minutes. What I didn’t know: whether the backup’s UPI routing was correctly configured for the full transaction volume, and whether the aggregator’s issue was network or an internal processing queue failure. I called our payments lead directly — not over Slack — and asked one question: “Is the backup’s UPI callback URL current in prod?” It was. That answered the one reversibility question I needed.

I could have waited another 10 minutes to see if the primary self-healed. I chose not to, because the cost of a 10-minute delay in a 35-minute window was asymmetric: if the primary recovered, we’d lost nothing by switching back. If it didn’t recover and we hadn’t switched, we’d face 20 minutes of degraded deposit success at peak. I cut over at T-minus 28 minutes. I wasn’t sure the backup would hold at 15,000 concurrent sessions. That uncertainty stayed with me through the first five minutes of the window.

[R] The backup held — peak deposit success rate that evening was 96.1%, against our SLA of 95%. Post-incident analysis showed the primary had a thundering-herd problem at their end that would have taken 22 minutes to resolve. We would have missed the window. The one thing I’d do differently: in the six weeks the backup was configured, I hadn’t stress-tested it. That gap was luck, not process. We now run monthly load tests on all payment routes, not just the primary.


S4 — Model Answer: Director / VP Engineering
#

Domain: Ecommerce — Diwali flash sale, checkout service rollback decision

[S] Four hours before our Diwali flash sale go-live — our largest revenue event of the year, forecast at ₹280 crore GMV across the day — load testing on our newly shipped checkout confirmation microservice surfaced a memory leak. Under sustained 8,000 RPS, the service’s heap grew at roughly 400MB per hour with no plateau. At that rate, we’d hit OOM and restart cycles within six hours of sale start. The service had launched two weeks earlier. It carried the new instalment payment flows that marketing had announced publicly and that product had tied to their Q3 OKRs.

[T] As engineering director, my call was whether to roll back to the monolith checkout path — safe, battle-tested, but losing the instalment flows — or deploy a memory-cap hotfix our team had written in 90 minutes that had not passed a full regression cycle. Three team leads were waiting on my call. The CPO was in a war room two floors up.

[A] I named my unknowns out loud in the room before anyone gave an opinion. I didn’t know the leak’s root cause, so I couldn’t be confident the hotfix closed it entirely. I didn’t know if the monolith path could carry instalment flows via a runtime shim in four hours — we hadn’t tested that path since the migration. What I did know: the rollback was instrumented and reversible within 12 minutes. The hotfix was not reversible if it failed under production load at 11 PM.

I asked each team lead one question before deciding: “What’s the leading indicator in the first 30 minutes of sale start that tells us this is failing?” The hotfix team said heap growth rate in the first 10 minutes. The rollback lead said first-order checkout error rate. I chose rollback, and I set a decision point aloud: if, by 11 AM, the instalment API shim was stable in production, we would re-launch the microservice to 5% of traffic via feature flag. I also spent 20 minutes with the CPO before the decision was public — framing it as a risk-weighted call, not a failure. The service would re-launch same-day if conditions allowed; we were protecting the core GMV. I needed her to carry that framing to the board, not be surprised by it.

[R] The sale ran cleanly. Checkout success rate held at 98.4% through peak. The instalment feature re-launched at 2 PM via feature flag, after the hotfix passed a targeted regression run during the mid-morning lull. GMV came in at ₹263 crore — 6% below forecast, attributed by finance to mobile conversion, not the checkout path. The CPO said the pre-briefing was what kept the broader org calm during go-live; she had the right framing before anyone asked. What I’d have done differently earlier in my career: I used to wait until I had the answer before going to executives. Now I go with the framework. The call changes, but the credibility doesn’t.


S5 — Judgment Layer
#

1. The cost of delay is always part of the calculus — name it explicitly. At EM/Director level, failing to account for the cost of not deciding is a red flag. Strong leaders show they understood that waiting has a price, not just acting. The trap: describing only the risk of acting, implying that gathering more data was cost-free. The upgrade: “Waiting another ten minutes would have meant X. That’s why I cut the decision window.”

2. Reversibility is the first filter, not the last. Before any other analysis, strong decision-makers ask: “If I’m wrong, how quickly can I undo this and at what cost?” Reversible decisions can be made faster and with less information. Irreversible ones require more process. The trap: treating all decisions as if they require the same confidence threshold. The upgrade: explicitly classify the decision as reversible or irreversible before describing your process.

3. Name the consultation you skipped and why. The mark of a mature leader is knowing which inputs they didn’t have time for and being honest about that gap. The trap: describing a clean, comprehensive consultation process that implies everyone relevant was in the room. The upgrade: “I didn’t loop in legal because their cycle time was 48 hours and I had 30 minutes. I accepted that risk consciously.”

4. “I wasn’t sure” is a quality signal, not a weakness. Interviewers scoring at EM+ expect you to name a moment of genuine doubt. Candidates who never express uncertainty appear either unaware of complexity or performatively confident — both are red flags. The trap: presenting the decision as logical and inevitable. The upgrade: “There was a window where I genuinely wasn’t sure if cutting over was the right call. Here’s what resolved it for me.”

5. The Director answer must show second-order thinking. An EM solves the immediate problem. A Director asks: “What does this decision do to the organisation’s confidence in its own judgment next time?” The answer should show you were building institutional muscle, not just closing an incident. The trap: a Director-level candidate describing only a personal decision with no reference to how they communicated it or what it modelled for their teams. The upgrade: “I was also aware that how I made this call would set the template for how my leads make similar calls six months from now.”

6. Tripwires are the mark of a decision-maker who plans to be wrong. Strong decision-makers define — in advance — the leading indicators that will tell them within the shortest viable timeframe whether they were wrong. This is what separates confident from reckless. The trap: describing a decision and its outcome with no mention of how you monitored whether it was working. The upgrade: name the specific metric and timeframe: “I told the team: if heap growth exceeds X in the first 30 minutes, we execute the rollback plan.”


S6 — Follow-Up Questions
#

1. “Looking back, what would have changed your decision?” Why they ask: retrospective quality — tests whether you can isolate variables and reason counterfactually. Model response: “If I’d known the aggregator’s issue was a queue problem, not network, I might have held 10 more minutes. But I didn’t have that, and my decision was based on what I could verify. That’s the honest answer.” What NOT to do: Say “I wouldn’t change anything” — it signals low self-awareness and makes the result sound lucky rather than earned.

2. “Who did you consult, and who didn’t you consult? Why?” Why they ask: depth — tests whether your consultation was deliberate or ad hoc. Model response: “I consulted the payments lead because they owned the one factual gap I needed closed. I didn’t loop in the VP because the decision was within my authority and getting approval would have cost 15 minutes I didn’t have. I informed her immediately after.” What NOT to do: List everyone you talked to without noting who you skipped.

3. “How did you communicate the decision — to your team and to leadership?” Why they ask: empathy + communication — tests whether you understand that a decision isn’t complete until it’s framed correctly for each audience. Model response: “To my team, I gave them the call and the reasoning in two sentences — they needed to act, not deliberate. To leadership, I was explicit about what I didn’t know and what I was watching to know if I was wrong. I didn’t project false certainty upward.” What NOT to do: Conflate communication with announcement — communicating the call and framing the call are different things.

4. “What was the pattern — have you made calls like this before? What have you learned across them?” Why they ask: pattern recognition — tests whether this is one data point or an established capability. Model response: “I’ve made maybe a dozen calls like this over four years of on-call leadership. The consistent pattern: the first 60 seconds of a high-stakes incident are almost always wasted on ‘what happened?’ instead of ‘what do we do now?’ I’ve learned to name the decision type early — ‘we’re in a do-or-hold situation, here’s what I need to know in the next five minutes’ — which collapses the deliberation time.” What NOT to do: Treat this as an invitation to list other stories. Stay meta and pattern-level.

5. [Scope amplifier — EM→DIR reframe] “If this decision had affected five teams instead of one, what would you have done differently?” Why they ask: tests Director readiness by reframing an EM answer into a larger canvas. Model response: “At five-team scale, the decision framework itself becomes a product. I’d need a pre-agreed RACI for payment-critical decisions — who can call a failover at 11 PM without a full approval chain — and that needs to be written down before the next crisis, not improvised during it. The actual decision logic would be similar, but the input structure and communication cascade would be pre-built.” What NOT to do: Say “I’d get more people involved” — that’s the opposite of the right answer under time pressure.

6. “What did your team think of the call at the time? Did anyone disagree?” Why they ask: empathy — tests whether you were aware of dissent and how you handled it. Model response: “The payments lead thought we should hold another five minutes. His argument was that the backup hadn’t been proven at scale. He was right about the risk. I acknowledged it explicitly: ‘You’re right that this is unproven. I’m making this call because the asymmetry favours switching.’ He executed without friction. We debriefed afterward and his concern was validated — it was a risk I accepted, not one I missed.” What NOT to do: Claim no one disagreed, or dismiss the dissent as unfounded.

7. “What did you put in place afterward so you’d have better information next time?” Why they ask: systems thinking — tests whether you treat one-off decisions as inputs to systemic improvement. Model response: “Two things. We mandated quarterly load tests on all payment routes, not just the primary. And I built a one-page decision playbook for payment failover scenarios — not to remove judgment, but to make the knowns-vs-unknowns checklist something any senior engineer could run at 2 AM without calling me. Within three months, we had a similar situation and the on-call lead made the call themselves. That was the real outcome.” What NOT to do: Stop at the single tactical fix. The systemic improvement is the Director-level signal.


S7 — Decision Framework
#

flowchart TD
    A["High-stakes trigger:\ndeadline makes waiting costly"] --> B["Is this decision reversible\nwithin a viable timeframe?"]
    B -->|"Yes - lower confidence bar"| C["Set tripwire metric +\ntimeframe before acting"]
    B -->|"No - raise confidence bar"| D["What one fact changes\neverything? Go get it."]
    C --> E["Map knowns vs unknowns\nexplicitly — out loud"]
    D --> E
    E --> F["Who owns the one\nfactual gap I need closed?\nCall them directly."]
    F --> G["Time-box consultation:\nset a hard decision deadline now"]
    G --> H["Name the option not taken\nand cost accepted — for the record"]
    H --> I["Communicate: call + reasoning\n+ tripwire to team AND leadership"]
    I --> J["Monitor tripwire.\nIf triggered: execute rollback plan"]

S8 — Common Mistakes
#

Mistake What it Sounds Like Why it Fails Fix
Low-stakes laundering “I had to decide which framework to use under a tight sprint” Doesn’t demonstrate leadership judgment at risk-bearing scale Pick a decision with real revenue, people, or compliance exposure
We-washing “We decided to cut over to the backup” Hides your individual judgment and role in making the call Use “I” for the decision; “we” only for execution
Story too old “Five years ago at a previous company…” Signals this isn’t a live capability — it was a one-off Aim for within the last 18–24 months; explain context if older
No tension named “I gathered the data, consulted the team, and made the call” Sounds process-perfect, not real — every hard decision has a moment of doubt Name the one thing you weren’t sure about and what resolved it
Reflection-free close “It worked out, the metric improved, done” Misses the growth signal the interviewer is probing for End with what you’d do differently or what you now know that you didn’t then
EM answering DIR question “I made the call and the team executed” At Director scope, the decision also models behaviour for the org Add: how you communicated confidence without false certainty, and what framework you left behind
DIR answering EM question “I redesigned the decision-making framework across the org” Over-scoped for EM — sounds like you weren’t personally in the trenches Match scope to the level being interviewed for; stay in the room where the decision happened
Naming the option not taken without explaining the cost “I could have waited; I chose not to” Doesn’t show the asymmetric reasoning that makes the decision defensible Explain the specific cost of the unchosen path: “waiting would have meant X, and that was a worse bet than Y”

S9 — Fluency Signals
#

Phrase What it Signals Example in Context
“The cost of delay was…” You understand inaction has a price, not just action “The cost of waiting 10 more minutes was 20 minutes of degraded deposit success at peak — asymmetrically worse than acting on incomplete data.”
“I separated knowns from unknowns explicitly” Structured process, not gut instinct “I ran through what I knew — failure rate trending up, not stable — and what I didn’t know: root cause and the backup’s ceiling under that load.”
“I set a tripwire before I made the call” You plan for being wrong; you don’t just decide and hope “Before committing, I told the team: if heap growth exceeds 200MB in the first 15 minutes of sale, we execute the rollback playbook.”
“The decision was reversible within X minutes” You classify decisions by reversibility, not just by stakes “I chose this path partly because the rollback was instrumented and executable in 12 minutes — that lowered the confidence bar I needed to act.”
“I acknowledged the risk I was accepting” Intellectual honesty — you didn’t pretend the risk wasn’t real “I told my payments lead directly: you’re right the backup is unproven at this scale. I’m accepting that risk because the alternative is worse.”
“I informed upward immediately after, not before” You understand your decision rights; you don’t create unnecessary escalation loops “The call was within my authority, so I made it and informed the VP immediately after — not seeking approval, keeping her in the loop.”
“I asked: what’s the leading indicator in the first 30 minutes?” You operationalise risk monitoring as part of the decision, not after “Before switching, I asked each lead: what metric will tell us in the first half-hour if this is failing? That became our watch list.”

S10 — Interview Cheat Sheet
#

Time target: 4–5 minutes. Don’t rush the Action beat — it carries 60–70% of the scoring weight.

EM vs Director calibration:

  • EM = your decision, your process, one metric in the result, genuine reflection.
  • Director = all of the above + how you communicated confidence without false certainty + what decision framework or tripwire structure you left behind for the organisation to use next time.

Opening formula: “This was [context] — [deadline that made waiting untenable] — and the decision was mine to make. Here’s how I worked through it.”

The one thing that separates good from great on this question: naming the option you didn’t take and the explicit cost you accepted by not taking it. Most candidates describe what they chose. Strong candidates describe what they rejected — and why — showing they understood the trade-off space, not just the winning move. That’s the cognitive structure the interviewer is looking for.

If you blank: Start with the stakes and the clock. “The revenue exposure was X. The window was Y minutes. I had to decide by Z.” That anchor re-grounds you and gives you a concrete thread to pull.

Leadership - This article is part of a series.
Part : This Article

Related

Led a Team Through a Significant Technical Change They Were Resistant To

S1 — What the Interviewer Is Really Probing # The scoring dimension here is change leadership under resistance — not change management in the HR-training sense, but your ability to drive conviction-led transformation while preserving the trust of the people who are pushing back. Interviewers care about whether you understand why resistance exists. Is it fear of irrelevance? A legitimate technical objection? Loss of ownership over something engineers spent years building? Leaders who conflate all resistance as “people being difficult” and steamroll it create short-term compliance and long-term resentment. Leaders who can diagnose and address root cause create lasting followership.