How do you tackle unfamiliar problems?

## What a strong answer should cover ### 1) Project deep dive (structure + evidence) Use a concise STAR/CARE format to avoid rambling. - **S/T (Situation/Task):** What was the business/user problem? What constraints mattered (latency, cost, reliability, compliance, timeline)? - **A (Actions):** What *you* did. Emphasize decisions, ownership, and technical depth (design, implementation, debugging, rollout). - **R (Results):** Quantify outcomes when possible: performance improvements, cost savings, availability, adoption, incident reduction. - **Learnings:** What you would do differently, what trade-off you revisited, and what you learned. **Good signals:** - Clear ownership boundaries (“I led X; partnered with Y”). - Metrics before/after (e.g., p95 latency 600ms → 220ms, infra cost -18%). - Mentions of risk management (feature flags, canary, rollback plan). - Awareness of stakeholders (PM, SRE, security) and communication. **Common pitfalls:** - Only describing the team’s work (“we did…”) with no personal contribution. - No success criteria or measurable outcome. - Too much implementation detail without stating the problem and impact. --- ### 2) Unfamiliar problem with incomplete information (a repeatable playbook) A strong approach is: **clarify → frame → de-risk → iterate → communicate**. #### Step A: Clarify the objective and constraints Ask targeted questions to turn ambiguity into concrete requirements: - **Goal:** What does “success” mean? Who is the user/customer? - **Scope:** What is in/out of scope for this iteration? - **Constraints:** Deadline, budget, tech stack, compliance, operational requirements. - **Quality bar:** Latency/throughput/availability targets, correctness expectations. If stakeholders aren’t available, state assumptions explicitly and confirm later. #### Step B: Frame the problem and identify unknowns - Break into components and write down what you know vs. what you don’t. - Identify the **highest-risk unknowns** (technical feasibility, dependency readiness, data quality, integration complexity). A useful technique is a quick **risk matrix**: impact × likelihood. #### Step C: Propose hypotheses and minimal experiments Make progress without full information by running low-cost tests: - Build a **spike/prototype** to validate feasibility. - Pull small samples of data to validate distributions and edge cases. - Benchmark key operations (e.g., expected QPS, p95 latency targets). Keep the experiment time-boxed (e.g., “2 days to answer: can we meet p95 < 300ms?”). #### Step D: Deliver an MVP with incremental refinement - Start with a minimal version that meets core requirements. - Add guardrails: input validation, timeouts, retries, rate limits, and monitoring. - Plan iterations: correctness first, then performance, then cost. #### Step E: Communicate clearly and early - Provide a short status update: **current understanding, assumptions, risks, next steps, ETA**. - When blocked, offer options with trade-offs (e.g., “Option A faster but higher cost; Option B slower but cheaper”). #### Step F: Post-solution learning - Document what you learned and update runbooks/design docs. - Add tests/alerts to prevent recurrence. --- ## Example answer skeleton (you can adapt) > “When I face an unfamiliar problem with limited info, I first clarify the success metric and constraints with the stakeholder. Then I list unknowns and prioritize the riskiest ones. I time-box a prototype or data investigation to validate feasibility and key assumptions. I deliver an MVP behind a feature flag with monitoring and a rollback plan, and I communicate assumptions/risks in writing so everyone aligns. After shipping, I document learnings and add tests/alerts.” This hits: requirements, risk management, iterative delivery, and communication—exactly what interviewers look for.