How do you decide with limited information?

Behavioral Question

Tell me about a time you had to make an important decision when the information you had was incomplete, ambiguous, or contradictory. Include:

• What decision had to be made and why it was important.
• What you knew versus what you did not know.
• How you evaluated risk and uncertainty.
• What alternatives you weighed and how you selected one.
• How you communicated the decision and secured buy-in, if applicable.
• The result and what you took away from it.

Follow-up questions the interviewer might ask:

• What would you change if you had more time?
• How did you trade off speed against correctness?
• How did you check your assumptions?
• What signals would have made you reverse the decision?

Overview: This question tests a candidate's ability to make decisions, assess risk, and communicate when important choices must be made with incomplete, ambiguous, or conflicting information in a software engineering setting.

This question is drawn from a software engineering interview.

Solution

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

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

• Situation: Give 1–2 sentences of context: team, product or system, and what was at stake.
• Task: State the decision you owned or co-owned and the constraints, such as time, cost, safety, or customer impact.
• Action: Make this the center of the answer: how you reasoned when information was uncertain.
• Result: Provide a measurable outcome and what you learned.

2) Show an explicit decision framework for uncertainty

Interviewers want to see how you think, not only what you chose.

A. Clarify the decision and success criteria

• Define what “good” means, for example reducing outages, hitting a launch date, controlling spend, or lowering risk.
• Identify non-negotiables such as security/compliance, SLOs, or customer harm.

B. Break unknowns into assumptions and risks

• List the key assumptions, such as demand level, latency tolerance, or vendor reliability.
• For each assumption, estimate:
  • Impact if it is wrong: high, medium, or low.
  • Likelihood that it is wrong.
• Focus learning on the items with the highest impact times likelihood.

C. Collect the minimum critical data, including disconfirming evidence

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

D. Choose a reversible or irreversible approach

• If the decision is reversible, lean toward speed and iteration.
• If it is irreversible, such as a data migration or security model change, invest more in validation and reviews.

E. Surface risk and propose mitigations Examples:

• a rollback plan, feature flag, or staged rollout
• guardrails such as rate limits or circuit breakers
• monitoring and alerts with clear thresholds
• contingency resources such as on-call coverage or a budget buffer

F. Align stakeholders and keep a record

• Communicate the options, trade-offs, chosen path, assumptions, and mitigations.
• Write a short decision record, about one page, so others can audit it later.

3) Give concrete trade-offs and metrics

Strong answers mention measurable checks, for example:

• “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) Demonstrate accountability and learning

• If the outcome was good, explain why it worked and what you would reuse.
• If the outcome was mixed, name the signal you missed and the process you improved, such as adding canaries or better dashboards.

5) Common mistakes to avoid

• Saying “I just went with my gut” without a validation plan.
• Failing to name assumptions explicitly.
• Having no mitigation or rollback plan.
• Skipping stakeholder communication.

6) A short reusable template

Situation: … Task: I needed to decide … by … with limited information 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 such as canary, rollback, or 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.