How do you decide with limited information?

Behavioral Question

Describe a time you had to make an important decision with incomplete, ambiguous, or conflicting information.

Include:

• What decision needed to be made and why it mattered.
• What information you had vs. what was missing.
• How you assessed risk and uncertainty.
• What options you considered and how you chose.
• How you communicated the decision and got buy-in (if relevant).
• The outcome and what you learned.

Follow-up prompts the interviewer may ask:

• What would you do differently if you had more time?
• How did you balance speed vs. correctness?
• How did you validate your assumptions?
• What signals would have caused you to reverse the decision?

Solution

What a strong answer looks like (STAR + uncertainty handling)

1) Use a clear structure: STAR (Situation–Task–Action–Result)

• Situation: 1–2 sentences of context (team, product/system, stakes).
• Task: The decision you owned (or co-owned) and constraints (time, cost, safety, customer impact).
• Action: The core of the answer—how you reasoned under uncertainty.
• Result: Measurable outcome + what you learned.

2) Demonstrate an explicit decision framework under uncertainty

Interviewers want to see how you think, not just what you decided.

A. Clarify the decision and success criteria

• Define what “good” means (e.g., reduce outages, meet launch date, control spend, reduce risk).
• Identify non-negotiables (security/compliance, SLOs, customer harm).

B. Decompose unknowns into assumptions and risks

• List key assumptions (e.g., demand level, latency tolerance, vendor reliability).
• For each assumption, estimate:
  • Impact if wrong (high/medium/low)
  • Likelihood of being wrong
• Prioritize learning on the highest impact × likelihood items.

C. Gather the minimum critical data (“disconfirming evidence”)

• Time-box investigation (e.g., “I spent 2 hours pulling logs and 1 day running a small experiment”).
• Prefer low-cost signals:
  • quick customer/user sampling
  • log/metrics analysis
  • prototype/spike
  • small A/B or canary release

D. Choose a reversible vs. irreversible approach

• If decision is reversible, bias toward speed + iteration.
• If irreversible (data migration, security model change), invest more in validation and reviews.

E. Make risk visible and propose mitigations Examples:

• rollback plan, feature flag, staged rollout
• guardrails (rate limits, circuit breakers)
• monitoring/alerts with clear thresholds
• contingency resources (on-call coverage, budget buffer)

F. Align stakeholders and document

• Communicate: options, trade-offs, chosen path, assumptions, and mitigation.
• Write a short decision record (1 page) so others can audit later.

3) Include concrete trade-offs and metrics

Strong answers mention measurable checks, e.g.:

• “Success = p95 latency < 200ms, error rate < 0.5%, cost < $X/month.”
• “We agreed to revisit after 2 weeks or if churn increased by >0.3%.”

4) Show accountability and learning

• If outcome was good: why it worked and what you’d reuse.
• If outcome was mixed: what signal you missed, what process you improved (e.g., added canaries, better dashboards).

5) Common pitfalls to avoid

• Saying “I just went with my gut” without a validation plan.
• Not naming assumptions explicitly.
• No mitigation/rollback plan.
• No stakeholder communication.

6) A concise template you can reuse

Situation: … Task: I needed to decide … by … with limited info about … Options: A/B/C with trade-offs … Action: I identified key unknowns, time-boxed data gathering, ran a small test, and made assumptions explicit. I chose … because … and set mitigations (canary/rollback/alerts). I aligned stakeholders by … Result: … (metrics). Learning: … and next time I would …

If you share your specific story details (domain, stakes, your role), I can help rewrite it into a crisp 2–3 minute interview-ready response.