How do you decide with limited information?

## 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.