Clarifying Questions and Scoping Questions

Covers the practice of turning vague or open ended prompts into well scoped problems by asking targeted clarifying questions and setting explicit assumptions. Candidates should show how they surface constraints, stakeholders, success metrics, timelines, dependencies, and edge cases; balance seeking information with moving forward; translate discovery into acceptance criteria or an initial experiment; and sequence inquiry to reduce risk. Interviewers evaluate the quality of the questions, the candidate's ability to frame sensible assumptions, and how the candidate converts discoveries into actionable next steps or measurable outcomes.

EasyTechnical

81 practiced

Design a one-week experiment to validate the hypothesis: 'Adding a cache in front of the API will reduce CPU usage by 40%.' What clarifying questions do you ask (baseline CPU, cache hit expectations, cache consistency model), what assumptions will you record, what metrics and sample size are required, and what are the success criteria?

Sample Answer

Clarifying questions- What is the current baseline CPU: 95th/median CPU usage per host, %-utilization, and CPU time breakdown by process/container?- What API endpoints and traffic split should the cache cover? (all endpoints or read-heavy subset)- Expected cache hit ratio and TTLs per endpoint; are responses cacheable (user-specific, auth)?- Consistency and invalidation model: stale-while-revalidate, TTL-only, or explicit invalidation?- Can we run the cache only on a fraction of traffic or hosts? Any rollout/deploy constraints?- Acceptable impact on latency and error rates?

Assumptions to record- Traffic pattern for the week is representative.- Cache capacity and eviction policy sufficient to reach target hit ratio.- No other concurrent infra changes.- CPU usage reduction is primarily for API application layer (not DB).

Metrics & sample size- Primary: aggregate CPU usage (avg, p50, p95) per API host, CPU cores consumed.- Secondary: cache hit/miss rate, request latency (p50/p95), error rate, RPS, downstream DB CPU.- Collect per-minute samples; compare two cohorts (control vs cache) over 7 days. Use at least N=20 hosts per cohort or traffic split ensuring >100k requests/day per cohort to get stable estimates.- Statistical test: two-sample t-test or bootstrapped CI on mean CPU reduction; target power 0.8 to detect 40% reduction.

Experiment plan (one week)- Day 0: baseline 48–72h metrics collection.- Day 3: deploy cache to 50% of traffic (A/B by request hashing) — cohort A = cached, B = control.- Days 3–9: collect metrics; monitor health dashboards and alerts; rollback criteria defined (errors spike, latency regressions).- Analysis: compute mean CPU per host, percent reduction, 95% CI, and p-value.

Success criteria- Measured mean CPU for cached cohort shows ≥40% reduction vs control with 95% CI entirely above 40% and p < 0.05.- Cache hit rate meets expectation (e.g., ≥60% for covered endpoints).- No adverse impact: p95 latency increase <10% and error rate unchanged.- No hidden costs (e.g., increased DB load elsewhere) that negate benefits.

If criteria not met, collect diagnostics (cache misses by key, TTL churn, hot keys) and iterate (tune TTLs, capacity, or scope).

MediumTechnical

76 practiced

A PM emails: 'Why did the system slow down yesterday?' with no additional context. What clarifying questions will you ask to bound a postmortem (specific time window, affected user flows, expected impact, data sources), to set a deadline for initial findings, and to scope the depth of the investigation?

Sample Answer

I’d respond with a focused set of clarifying questions and a clear timeline/scoping plan so we can produce useful, timeboxed findings.

Clarifying questions (grouped):- Time window: Exactly when did you observe the slowdown? First report time, start/end times, timezone, any intermittent vs continuous behavior.- Affected users/flows: Which user segments or flows seemed slow (API, web checkout, reports, background jobs)? Is it all users or a subset (region, account tier)?- Expected impact: What business impact did you see or expect (failed transactions, increased latency, customer complaints, revenue loss)? Any SLA/SLO breaches?- Data sources & signals: Which dashboards/alerts did you check? Can you share relevant Grafana/NewRelic/Datadog links, logs, traces, and incident IDs?- Recent changes: Were there deploys, config changes, infra changes, traffic spikes, or scheduled jobs around then?- Scope & priority: Do you want a quick triage (root-cause hypothesis) or a full investigative postmortem with timeline, RCA, fix plan?- Access & stakeholders: Who should be looped in (on-call, dev leads, product, infra)? Who owns follow-ups?

Proposed timeboxing & deliverables:- Initial findings (triage): 2 hours — confirm time window, immediate mitigation, top 1–2 hypotheses with supporting metrics.- Intermediate report: 24 hours — reconstructed timeline, primary evidence, temporary mitigation if needed.- Full postmortem: 3–5 business days — detailed RCA, root causes (causal chain), contributing factors, corrective actions, owners, and rollout plan.

Scoping options (choose based on priority):- Triage only: evidence + mitigation (2 hrs)- Triage + detailed RCA: add timeline, config diffs, traces (24–48 hrs)- Deep dive: include load-testing, code review, capacity modeling, and long-term fixes (3–5 days)

Why this approach: it bounds work, matches SLO/business priority, ensures early value (mitigation/hypotheses) while allowing a deeper investigation if impact warrants.

EasyTechnical

85 practiced

A PM says 'make the system faster.' What clarifying questions would you ask to define 'faster' in measurable terms (which user journeys, which latency percentiles p50/p95/p99, workload patterns, acceptable regressions), and how would you scope an experiment to prove the improvement?

EasyBehavioral

79 practiced

Behavioral: Tell me about a time when you inherited an ambiguous SRE project (for example, 'make our system reliable'). Using the STAR format, describe the clarifying questions you asked, the assumptions you set when information was missing, how you turned discovery into acceptance criteria or an experiment, and the outcome including measurable results.

Sample Answer

Situation: I joined a team that handed me a one-line ticket: "Make our system reliable." The service had frequent user-facing errors, noisy alerts, and no SLOs; stakeholders expected improvement but gave no specifics.

Task: Define a concrete plan to improve reliability in 8 weeks and deliver measurable gains without disrupting feature delivery.

Action:- Clarifying questions I asked: - What user journeys/endpoints matter most? (Which SLAs exist?) - Current availability, incident cadence, and MTTR baselines? - Who are the stakeholders and what risk is acceptable? - What tooling and telemetry are available (metrics, logs, tracing)? - Are there upcoming releases or planned changes?- Assumptions I stated when info was missing: - Assume top 3 endpoints cover 80% of user impact. - Assume existing monitoring captures errors but lacks latency SLO. - Assume team can allocate 20% sprint capacity to reliability work.- Discovery → acceptance criteria / experiment: - Ran a 2-week discovery: mapped call paths, identified top failure modes, and measured baseline: 99.2% availability, mean MTTR 72 minutes, error budget burn of 35%/week. - Converted findings into concrete SLOs (99.9% availability for checkout, 95th latency <300ms), alert thresholds, and three experiments: 1) Implement circuit breakers and retries for dependency failures (canary rollout). 2) Add targeted dashboards + SLO-based alerts to reduce noise. 3) Automate a rollback and runbook-trigger for the top two incident types. - Acceptance criteria: SLOs defined and onboarded into alerting; canary shows <1% degradation; MTTR <30 minutes within 4 weeks.- Execution: I implemented the circuit breaker library, added SLO-driven alerts, wrote runbooks, and shipped a canary to 10% traffic then ramped.

Result:- Within 6 weeks availability for checkout improved from 99.2% to 99.94%.- MTTR dropped from 72 to 22 minutes.- Weekly error budget burn fell from 35% to 5%.- Alert noise reduced by 60% (fewer paging incidents); engineers reclaimed ~10% weekly capacity.This experience reinforced that clear questions, explicit assumptions, and short experiments with measurable acceptance criteria turn vague mandates into reliable outcomes.

MediumSystem Design

99 practiced

Leadership asks for a 20% reduction in p99 latency across a set of microservices. What clarifying questions will you ask to agree scope (which services and user journeys), constraints (budget, timelines, can we change client code), success metrics, and how would you propose a phased plan (pilot, scale, verify)?

Sample Answer

Clarifying questions — scope- Which services are in scope (all microservices, a subset, or a service mesh)? Provide a list or tag.- Which user journeys/end-to-end flows matter (login, checkout, search)? For each, what percentage of traffic or business value do they represent?- Are we optimizing client-perceived latency (end-to-end p99) or service-side p99s? Do we need cross-service tail latency guarantees?- Is 20% reduction target absolute or relative per-service and across which window (5m, 1h, daily p99)?

Constraints- Timeline: target date / milestones?- Budget: allowed infra changes, instance types, CDN costs, APM licenses?- Can we change client code, clients' retries/backoff, or is only server-side allowed?- Risk tolerance: acceptable regression in throughput or error rates?- Compliance/rollback windows and maintenance windows for experiments?

Success metrics & telemetry- Primary: end-to-end p99 for specified user journeys (value + baseline).- Secondary: p50/p90, error rate, throughput, CPU/memory, GC time, queue lengths, tail of RPC latencies.- Observability: trace sampling, distributed tracing, histograms with high-resolution buckets, SLOs and dashboards.- Success threshold: 20% reduction sustained for X days without increased errors; quantify acceptable trade-offs.

Phased plan1) Pilot (2–4 weeks)- Pick 1 high-value, high-traffic journey and 1 representative service.- Baseline: capture detailed traces, flame graphs, service maps, resource utilization under realistic load.- Quick wins: tune timeouts/retries, reduce synchronous calls, add caching, optimize DB queries, enable connection pooling, reduce payloads, add compression.- Measure impact in canary environment and small-percentage production traffic.

2) Scale (4–8 weeks)- Roll successful changes to other services. Implement shared improvements: client-side timeouts, bulkheads, circuit breakers, async patterns, CDN for static content.- Infrastructure: autoscaling policy tuning, instance types, network tuning, placement groups.- Introduce CI gates: performance tests and regression checks.

3) Verify & steady state (2–4 weeks)- Run production A/B or progressive rollout to validate 20% p99 improvement across journeys over defined period.- Update SLOs, alert thresholds, runbooks.- Document changes, knowledge transfer, and schedule follow-up to monitor for regressions.

Trade-offs & risks- Some optimizations (e.g., aggressive caching) may increase staleness; weigh against business requirements.- Avoid single large change—prefer iterative, measurable improvements with rollback plans.

Deliverables- Agreed scope/matrix of services + journeys- Baseline report and dashboard- Pilot results and action list- Rollout plan with timelines, owners, and rollback criteria- Post-rollout verification and updated SLOs

I’d start by getting the scope and constraints answers, run an immediate low-effort baseline and small pilot to prove value, then expand iteratively with strong observability and rollback controls.

Unlock Full Question Bank

Get access to hundreds of Clarifying Questions and Scoping interview questions and detailed answers.

Join thousands of developers preparing for their dream job.