Decision with Incomplete Information

“Tell me about a time you made a decision with incomplete information.”

Engineering is a constant game of imperfect information. This question tests whether you can act decisively under uncertainty without being reckless — whether you know how to reduce ambiguity and make a call with whatever data is available.

---

Why Interviewers Ask This

• Risk assessment: Can you identify what you don’t know and quantify the risk? Do you distinguish between known unknowns and unknown unknowns?
• Decision framework: Do you have a process for making decisions under uncertainty, or do you rely on intuition?
• Outcome ownership: Can you make a call, own the result, and learn from it regardless of success or failure?

---

The Common Traps

The Paralysis

“I didn’t have enough data to make a confident decision, so I waited. Two weeks later, we still hadn’t decided.” The Interviewer’s Perspective: You can’t operate without perfect information. In fast-moving environments, you’ll be a bottleneck.

The Gambler

“I went with my gut. It felt right.” The Interviewer’s Perspective: You don’t do risk assessment. When your gut is wrong, there’s no safety net.

---

The Blueprint for The Calculated Risk

Phase 1: What Was Unknown

What information was missing and why? Was it technical uncertainty (unknown performance characteristics), business uncertainty (unclear user behavior), or resource uncertainty (team availability)?

Phase 2: How You Reduced Uncertainty

What did you do to shrink the unknown? Did you run an experiment, consult an expert, build a prototype, or gather analog data from similar systems? Show that you actively reduced risk, not just accepted it.

Phase 3: Decision Criteria

What framework did you use to decide? Minimum viable threshold, cost of delay vs. cost of being wrong, or a simple pros/cons weighted by probability.

Phase 4: Outcome and Retrospective

What happened? If it worked, what did you learn? If it didn’t, what would you do differently? The best answers include a genuine lesson.

---

High-Impact Answer Example

[Unknown] “We needed to choose a database for a new real-time analytics feature. We had usage projections but no real traffic data. Both a time-series DB and a general-purpose relational DB with partitioning were contenders.” [Reducing Uncertainty] “I set up a proof-of-concept for both options with synthetic traffic at 10x our projected load. The time-series DB handled it easily; the relational DB started showing latency issues at 50x. I also interviewed two teams at the company who had experience with each.” [Decision Criteria] “My bar was: handles 50x projected load and requires no more than one dedicated on-call rotation. The time-series DB cleared both bars; the relational DB failed the latency threshold.” [Outcome] “We chose the time-series DB. Six months in, actual load hit 30x projections — and performance was still solid. The one thing I’d do differently is benchmark with write-heavy patterns earlier; our initial tests were read-biased, and we later had to tune write throughput.”

---

Checklist for Your Response

• The Uncertainty: Did I clearly describe what was unknown and why it mattered?
• The De-risking: Did I show specific actions I took to reduce uncertainty before making the call?
• The Criteria: Did I state my decision threshold explicitly (e.g., “if latency stays under X, we proceed”)?
• The Learning: Did I include a lesson learned or something I’d do differently?