A service is suddenly returning 500s in production. Walk me through how you would troubleshoot it.
What they are really testing: Whether you reason from symptom to cause like someone who has run an incident, or just recite tools. They want scoping, a hypothesis, prioritization of the cheapest signal, and an instinct to restore service before chasing root cause.
A real interview question
A service is suddenly returning 500s in production. Walk me through how you would troubleshoot it.
What most people say
drag me
“I would check the logs and look at the events to see what is going wrong.”
No scoping, no hypothesis, no prioritization. Logs are expensive and noisy; reaching for them first signals you have read docs, not run an incident. It never mentions what changed, restoring service, or prevention.
The follow-ups they ask next
The logs show nothing obvious. What now?
Widen and check the boundary: are the 500s from your app or the LB/ingress in front of it? Pull a distributed trace for one failing request and find which hop fails, often a downstream dependency or a saturated pool, not your code.
How do you make sure this does not page you at 3am again?
A symptom/SLO-based alert (error-budget burn, not just CPU), a regression test for the specific failure, and a release gate (canary + automated rollback on error spike).
What the interviewer is listening for
- Scopes the blast radius before acting
- Asks "what changed" early
- Restores service before chasing root cause
- Closes the loop with prevention
What sinks the answer
- Jumps straight to "read the logs"
- No instinct to roll back
- Debugs forward in prod mid-outage
- Never mentions prevention
If you genuinely do not know
Say this instead of freezing. Reasoning out loud from what you do know beats silence every single time, and a good interviewer is listening for exactly that.
“Before I touch anything, I'd scope it, [all traffic or one endpoint, and since when]. My first hypothesis: [the most recent change, usually a deploy]. I'd confirm cheaply by [error rate by version + recent deploys] before logs. If a deploy lines up, I'd [roll back first], then root-cause from the diff, and finally [add an alert/test so it can't recur].”
Keep going with reliability
Foundation
What is a Region versus an Availability Zone, and why does the difference matter?
Foundation
What is the difference between vertical scaling and horizontal scaling, and when would you reach for each?
Foundation
What does "highly available" actually mean, and how do you achieve it?
Foundation
Why are stateless services easier to scale and make reliable than stateful ones?
Junior
How should a service retry a failed call to a dependency, and what is a retry storm?
Junior
What is idempotency, and why does it matter for reliable distributed systems?
Knowing the answer is not the same as recalling it under pressure
Sign in to send the questions you fumble to spaced recall, so they come back right before you would forget them, and learn the concepts behind them with hands-on labs.
Start free