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

88 practiced

You need to prioritize three concurrent feature requests that each have ambiguous ROI. Describe the clarifying questions you would ask to determine business value and technical effort, the assumptions you would document, and a prioritization framework you would apply to sequence delivery.

EasyTechnical

127 practiced

You're scoping a developer-facing feature: a new webhook for partners. The engineering lead warns about rate limits and retry semantics. What clarifying questions and acceptance criteria would you write to capture reliability, security, versioning, and developer experience (DX) expectations? Include at least five acceptance criteria.

Sample Answer

**Context / goal (as TPM)**I’d clarify requirements so engineering can implement webhooks that are reliable, secure, versionable, and pleasant for partner developers to integrate.

**Clarifying questions**- Volume & SLA: expected events/sec per partner and peak patterns? Required delivery SLA (e.g., 99.9% within 30s)?- Rate limits: per-partner and global rate limits; burst allowance and backoff policy?- Retry semantics: how many retries, interval strategy (exponential with jitter?), when to dead-letter events?- Delivery guarantees: at-least-once, at-most-once, or exactly-once? Are duplicate suppression/ids required?- Security: preferred auth method (HMAC signatures, mTLS, OAuth2)? Required rotation cadence for signing keys?- Versioning: contract versioning strategy (URL versioning, header versioning), deprecation windows, and migration support?- Observability: required logs, delivery dashboards, webhook test endpoints, replay ability?- Developer UX: sample SDKs, interactive docs, webhook simulator, error payload format?- Throttling behavior: what HTTP status codes should partners receive when throttled?- Compliance: data residency, PII handling, and retention rules?

**Acceptance criteria** (minimum five)1. Delivery guarantee: Webhook delivers events with at-least-once semantics; each event includes a unique id and timestamp for idempotency.2. Retry & backoff: Failed deliveries retried using exponential backoff with jitter up to N attempts (configurable, default 5); after final failure events go to a dead-letter queue and are visible in partner dashboard.3. Rate limiting: Per-partner rate limit documented (e.g., 100 req/sec) with 429 response and Retry-After header; burst allowance and throttling behavior documented.4. Security: All deliveries are signed with HMAC-SHA256 header; signing keys rotatable via API; optional mTLS support for high-security partners.5. Versioning & compatibility: Webhook payloads are versioned in URL and a X-Webhook-Version header; breaking changes require 90-day deprecation window and automated migration guides.6. Observability & DX: Partners have access to a replay API, delivery logs with timestamps and status codes, a sandbox/test endpoint, and clear error codes + human-readable messages in docs.7. Monitoring & SLA: System emits metrics (success rate, latency, retries) to SLI dashboard; alerting if success rate < 99.9% over 5m.

These questions and criteria ensure reliability, secure delivery, clear versioning, and a smooth developer experience.

MediumTechnical

80 practiced

You're scoping an effort to refactor an internal API used by multiple teams. Some teams rely on undocumented behavior. What clarifying questions would you ask to uncover unstated dependencies and edge cases? Describe how you'd convert findings into formal acceptance tests and a migration plan minimizing breakage.

HardTechnical

141 practiced

You're building acceptance criteria from a discovery session that left the 'error reporting' behavior unspecified. Demonstrate how you'd convert qualitative feedback into 6 concrete, testable acceptance criteria that cover observability, user-facing messages, retry behavior, and alerting thresholds.

Sample Answer

Clarifying assumption: this is for an HTTP API endpoint used by clients; "error reporting" means how the system logs, surfaces, retries, and alerts on failures. Acceptance criteria are written to be testable by QA/engineering.

Scope & approach:- Convert qualitative notes into measurable outputs (logs, metrics, messages, retries, alerts).- Each criterion specifies input, expected system behavior, observable outputs, and test steps.

Acceptance criteria

1) Structured logs- When an error occurs, system emits a JSON log with keys: timestamp, request_id, user_id (if present), endpoint, error_code, error_message, stack_trace (when server error), and retry_count.- Test: trigger each error type and assert log contains all keys.

2) Metric emission- Every error increments a Prometheus metric api_errors_total{endpoint, status_code, error_code, region}.- Test: cause a 500 and 4xx; verify metric label values and delta = 1.

3) User-facing message- Client receives clear, localized JSON error: { code: "PAYMENT_TIMEOUT", message: "Payment service timed out. Try again in 30s or contact support with request_id: X" } for transient errors; message templates stored in i18n.- Test: simulate transient error and assert status code, code field, message contains retry guidance and request_id.

4) Retry behavior- For idempotent POST/PUT, system automatically retries up to 2 times with exponential backoff (200ms, 800ms) for network/timeouts only; non-idempotent requests must not be retried automatically.- Test: simulate transient network failure and assert retry attempts and timing in logs; assert no retry for non-idempotent.

5) Alerting thresholds- Create alert when api_errors_total rate > 5% of requests for any endpoint sustained over 5 minutes OR absolute error rate > 50 errors/min.- Test: emit synthetic errors to cross thresholds and verify PagerDuty alert fires.

6) Error classification & paging- Errors are classified as TRANSIENT, CLIENT, or SYSTEM. Dashboard shows top 10 error_codes per endpoint in last 24h; severity mapping drives alerting rules.- Test: produce mixed errors, verify dashboard counts, classifications, and that SYSTEM errors map to high severity.

Notes: include request_id propagation, instrumentation ticket, and link to runbook for PagerDuty responders.

MediumTechnical

85 practiced

A legal team flags potential data residency compliance issues for an upcoming API feature. You have limited info. What clarifying questions do you ask to scope required work, what assumptions might you make to proceed cautiously, and how would you sequence tasks to minimize compliance risk while keeping momentum?

Sample Answer

**Clarifying questions (to scope work)**

- Which data fields will the API collect, store, or transmit? (PII, payment, health, metadata)- Where does data originate and which geographic regions will customers and us reside in?- What is intended data lifecycle (real-time pass-through, persistent storage, log retention)?- Are any downstream systems, analytics, backups, or third-party processors involved and where are they hosted?- Which compliance regimes are implicated (GDPR, APAC data-residency laws, sector-specific rules)?- What SLAs, latency or availability constraints must remain unchanged?- Are there preferred mitigations/legal controls already proposed (consent, pseudonymization, contractual clauses)?

**Conservative assumptions to proceed**

- Assume flagged fields are sensitive until proven otherwise.- Assume data may be replicated to any connected system unless explicitly restricted.- Assume legal/regulatory timelines may be short; prioritize measures that reduce exposure quickly (e.g., stop-gap routing).

**Task sequencing to minimize risk while keeping momentum**

1. Triage (0–48h): Rapid impact map—catalog fields, flows, hosts; flag high-risk paths and stop-gap mitigations (feature toggle, geo-blocking).2. Define requirements (2–5 days): With legal/engineering, convert needs to concrete product requirements (data-at-rest locations, encryption, audit trails).3. Design & estimate (1 week): Lightweight architecture options (regional endpoints, data tagging, routing, processor contracts) and effort/risk trade-offs.4. Implement minimal safe path (sprints): Deploy quick controls (endpoint geofencing, retention limits, logging) while parallel-designing full solution.5. Validate & document: Legal sign-off, automated tests, monitoring, and developer docs; plan migration for existing data.6. Iterate: Roll out fully regionalized storage or configurable residency policies, tracking metrics (compliance incidents, latency, dev velocity).

This approach balances caution (assume sensitivity, stop-gap controls) with product momentum through parallel tracks: quick mitigations + parallel design/implementation of robust residency 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.