Interview prompt
A specific endpoint is fast for most users but extremely slow for a small group. What do you investigate first, and how do you reach a safe fix?
The first strong observation
The asymmetry is the strongest clue. The same code path behaves differently, so start by comparing the affected users' data shape, request parameters, tenancy, region, and cache behaviour instead of immediately rewriting the endpoint.
Evidence to inspect first
- ◆Latency grouped by account or user, not only the global p95.
- ◆Row counts and data age for fast versus slow accounts.
- ◆Different EXPLAIN ANALYZE plans for representative production inputs.
- ◆Pagination limits, response sizes, cache hit rate, and downstream calls.
A strong step-by-step approach
Confirm the segment
Use tracing and logs to identify exactly which users, tenants, regions, or request shapes are slow. Compare one slow request with one fast request end to end.
Measure data skew
Check whether affected accounts own orders of magnitude more rows or older data. A query returning 50 rows in the common case may return 500,000 for a long-lived account.
Inspect the real query plan
Run EXPLAIN ANALYZE with production-like parameters. Cardinality can make the planner choose a sequential scan or a poor join strategy even when an index exists.
Bound the work
Verify pagination, response limits, N+1 queries, serialization cost, and downstream fan-out. Put a hard bound on work before attempting broad infrastructure changes.
Ship and verify safely
Test the fix against both normal and worst-case accounts, release gradually, and watch segmented latency and error rate rather than only the global average.
Structure your answer in this order
- 01State the user-specific clue
- 02Compare request traces and data cardinality
- 03Validate the query plan
- 04Apply a bounded fix
- 05Describe rollout and monitoring
Weak-answer signals
- ×Scaling every server before finding why only some users are affected.
- ×Testing EXPLAIN with a small or synthetic account.
- ×Adding an index without checking write cost and the actual access pattern.
Likely follow-up questions
- ?What if the slow users are all in one region?
- ?How would you detect this before users report it?
- ?When would partitioning be justified?
Quick FAQ
What is the interviewer evaluating in this scenario?
The interviewer is not looking for one technology name. They are evaluating how you gather evidence, limit risk, choose a safe action, and verify the outcome under uncertainty.
How long should the answer be?
Use the first two minutes to state your priority and initial hypothesis, then move through signals, diagnosis, mitigation, and verification. Go deeper when the interviewer asks follow-up questions.