Back to General STAR Scenarios
Q10Question 10 of 10

Making a Decision With Incomplete Information: how did you proceed?

Key Concepts
  • Gather what you can quickly, then decide rather than freezing.
  • Favor the safest reversible option when stakes are high and information is incomplete.
  • Assess the worst-case cost of each option before choosing.
  • Communicate your assumptions explicitly so the team can challenge them.
  • Set a checkpoint to revisit and adjust as new data arrives.
  • One-way-door decisions deserve more deliberation; two-way-door decisions deserve less.
  • Calibrated action under uncertainty is the mark of a senior engineer.

Definition

When information is incomplete, gather what you can quickly, favor the reversible safe option, decide, and adjust as new facts arrive.
  • Act, do not freeze – Decide with the best available information rather than waiting for perfection.
  • Reversibility bias – Under uncertainty, favor the option that is easiest to undo.
  • Worst-case assessment – For each option, ask: what is the worst that happens if I am wrong?
  • Explicit assumptions – State what you are assuming so others can challenge it.
  • Checkpoint – Set a time to revisit and adjust as new data arrives.
  • One-way vs two-way – Invest more deliberation in irreversible decisions.

Imagine during a production incident at National Bank of India, you must decide whether to pause all transfers while investigating a suspected double-charge on Priya's account, but you do not yet know how widespread it is. You weigh the cost of acting versus waiting, favor the reversible safe option, and refine as you learn more.

Understanding the Concepts

What is this question really testing?

Decision-making under uncertainty. The interviewer is checking that you do not freeze waiting for perfect information, and that you do not gamble carelessly.

JAVA
package com.bank.interview;
public class UncertaintyTest {
    enum Behavior { CALIBRATED, FROZEN, RECKLESS }
    public static Behavior evaluate(boolean gathered, boolean assessedRisk, boolean decided) {
        if (!decided) return Behavior.FROZEN;
        if (!assessedRisk) return Behavior.RECKLESS;
        return Behavior.CALIBRATED;
    }
    public static void main(String[] args) {
        System.out.println(evaluate(true, true, true)); // CALIBRATED
    }
}

What was the situation?

Monitoring showed a spike in failed transfers at National Bank of India, with early signs some might be double-processing. I did not know how many accounts were affected or the root cause.

JAVA
package com.bank.service;
import java.util.logging.Logger;
public class UncertainSituation {
    private static final Logger log = Logger.getLogger(UncertainSituation.class.getName());
    public static void main(String[] args) {
        log.warning("Failed transfers spiking");
        log.warning("Possible double-processing on some accounts");
        log.info("Unknown: how many accounts? What is the root cause?");
        log.info("Decision needed: keep running, throttle, or pause?");
    }
}

How did you assess each option?

For each option, reason about the worst case if you are wrong and whether the choice is reversible.

JAVA
package com.bank.interview;
public class OptionAssessment {
    public static void main(String[] args) {
        System.out.println("Keep running: worst case = widespread double-charge (irreversible)");
        System.out.println("Throttle: worst case = slow transfers (partially reversible)");
        System.out.println("Pause: worst case = brief availability hit (fully reversible)");
        System.out.println("Under uncertainty with money: safest reversible option wins.");
    }
}

Why did you choose to pause?

A short pause is easy to undo. An uncontrolled double-charge is not. Under uncertainty with money on the line, the safest reversible option wins.

JAVA
package com.bank.service;
import java.util.logging.Logger;
public class PauseDecision {
    private static final Logger log = Logger.getLogger(PauseDecision.class.getName());
    public static void main(String[] args) {
        log.info("Decision: PAUSE transfers");
        log.info("Reasoning: safest reversible option; brief availability hit is cheap to undo");
        log.info("Assumption: issue may be widespread; trading availability for safety");
        log.info("Checkpoint: revisit in 15 minutes when we know the blast radius");
    }
}

How did you communicate your assumptions?

Explicitly stated what you were assuming so the team could challenge it.

JAVA
package com.bank.interview;
public class ExplicitAssumptions {
    public static void main(String[] args) {
        System.out.println("Assumption 1: double-processing may be widespread");
        System.out.println("Assumption 2: pausing is safer than letting possibly-bad transfers through");
        System.out.println("Assumption 3: root cause will be identified within 30 minutes");
        System.out.println("Team can challenge any of these.");
    }
}

How did you adjust as new information arrived?

Within minutes confirmed the issue was limited, fixed the root cause, and resumed transfers.

JAVA
package com.bank.service;
import java.util.logging.Logger;
public class AdjustWithData {
    private static final Logger log = Logger.getLogger(AdjustWithData.class.getName());
    public static void main(String[] args) {
        log.info("15 min later: confirmed issue limited to 12 accounts");
        log.info("Root cause: race condition in new retry logic");
        log.info("Fix deployed, transfers resumed");
        log.info("No widespread double-charge thanks to early pause");
    }
}

What is the one-way vs two-way door framework?

A one-way-door decision (database engine, public API) deserves deep deliberation. A two-way-door decision (feature flag, internal config) deserves speed.

JAVA
package com.bank.interview;
public class DoorFramework {
    public static void main(String[] args) {
        System.out.println("One-way door (irreversible): invest more in reducing uncertainty");
        System.out.println("Two-way door (reversible): move fast, adjust later");
        System.out.println("Pausing transfers is two-way: easy to resume = fast decision");
    }
}

What was the outcome?

Prevented any large-scale double-charge. Brief pause, quick fix, transfers resumed.

JAVA
package com.bank.interview;
public class UncertaintyOutcome {
    public static void main(String[] args) {
        System.out.println("Double-charges prevented: 0 widespread impact");
        System.out.println("Downtime: ~15 minutes (brief, fully reversible)");
        System.out.println("Root cause fixed permanently");
    }
}

What are common interview follow-up questions?

JAVA
package com.bank.interview;
public class UncertaintyFollowUps {
    public static void main(String[] args) {
        System.out.println("What if you were wrong to pause? -> Brief availability hit, easily resumed");
        System.out.println("What if you had not paused? -> Possible widespread double-charge");
        System.out.println("Would you do the same? -> Yes, safest reversible option under uncertainty");
    }
}

Visual Overview

DIAGRAM
┌────────────────────────────────────────────────────────┐
│         Decision Under Uncertainty                     │
├────────────────────────────────────────────────────────┤
│  ┌──────────────────┐                                  │
│  │ 1. GATHER quickly │  What do I know? What don't I?  │
│  └────────┬─────────┘                                  │
│           ▼                                            │
│  ┌──────────────────┐                                  │
│  │ 2. ASSESS options │  Keep / Throttle / Pause         │
│  │    worst-case +   │  Worst case + reversibility      │
│  │    reversibility  │                                  │
│  └────────┬─────────┘                                  │
│           ▼                                            │
│  ┌──────────────────┐                                  │
│  │ 3. DECIDE         │  Pause: safest reversible option │
│  │    + assumptions  │  State assumptions explicitly     │
│  └────────┬─────────┘                                  │
│           ▼                                            │
│  ┌──────────────────┐                                  │
│  │ 4. CHECKPOINT     │  Revisit in 15 minutes            │
│  │    + ADJUST       │  Confirmed limited, fixed, resumed│
│  └──────────────────┘                                  │
└────────────────────────────────────────────────────────┘

Key Takeaway

At National Bank of India, our monitoring showed a spike in failed transfers with signs of possible double-processing on accounts like Priya's. I did not yet know how widespread it was or the root cause. I had to decide quickly whether to keep running, throttle, or pause transfers.

I assessed each option by worst-case cost and reversibility. Keeping the system running had the highest worst-case cost : a widespread double-charge is hard to undo. Pausing had the lowest worst-case cost and was fully reversible. So I chose to pause, communicated my assumptions explicitly, and set a checkpoint to revisit in fifteen minutes.

Within that time we confirmed the issue was limited, fixed the root cause, and resumed transfers, having prevented any large-scale double-charge. The brief pause was a small availability cost that prevented a much larger financial one.

What I learned is that decisions with incomplete information are not about guessing. They are about gathering what you can quickly, weighing worst-case cost and reversibility, choosing the safest reversible path, and adjusting fast as facts arrive.

Remember one sentence: Under uncertainty, favor the safest reversible option, state your assumptions explicitly, and set a checkpoint to adjust as new data arrives.

---

Share
Use ← → arrow keys to navigate