You get paged at 2am. Checkout latency has gone from 200ms to 4 seconds and it started right after the 11pm deploy. Walk me through what you do.
What they are really testing: Whether you protect the user before you protect your curiosity, and whether you can name a repeatable order of moves instead of guessing.
A real interview question
You get paged at 2am. Checkout latency has gone from 200ms to 4 seconds and it started right after the 11pm deploy. Walk me through what you do.
What most people say
drag me
“I would look at the logs and try to find the error, then I would fix the bug and redeploy.”
It leaves the customer bleeding while you read logs, it has no rollback instinct, no blast radius check, and treats every incident as a single bug hunt rather than a stop the pain, then find the cause sequence.
The follow-ups they ask next
What if the rollback does not fix it?
Say that out loud as information, not failure. It kills the deploy hypothesis, so widen to dependencies, database, and a change someone else made in the same window.
How would you have caught this before production?
Talk about a canary or staged rollout with a latency gate, so 5 percent of traffic sees it first and an automatic check trips.
What the interviewer is listening for
- Rolls back before diagnosing, and says why in one sentence
- Checks blast radius with a specific signal, not a vibe
- Names a concrete metric like p95 or queries per request
- Verifies recovery for a set time before declaring it over
What sinks the answer
- Starts reading logs line by line while users are still failing
- Cannot name a single dashboard or metric they would open
- Assumes the cause instantly and never tests the assumption
- Says they would wait for the developer who wrote the code to wake up
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.
“I have not been paged for exactly this, but here is the order I would work in: stop the bleeding by rolling back the change in the window, then confirm how wide the damage is, then look at what changed, and only then chase root cause.”
Keep going with troubleshooting
Junior
It is 3am and you get paged: the primary application server is at 100% disk usage and the app is throwing write errors. You are the only one online. Walk me through exactly what you do.
Junior
You push a new version of a service and within two minutes the pods are all showing CrashLoopBackOff. The team is watching you share your screen. Walk me through exactly what you do.
Junior
A developer pings you: the checkout service cannot reach the payments service, the calls just hang and time out. You have never worked on either service. Walk me through what you do.
Junior
A developer messages you: 'My app suddenly gets Access Denied writing to the S3 bucket. Nothing changed.' It worked yesterday. Walk me through what you do.
Mid
Your load balancer shows 5xx errors jumping from 0.1 percent to 12 percent of requests over ten minutes. There was no deploy. What do you do?
Mid
One of your containers keeps getting OOM killed. It restarts, serves traffic for about twenty minutes, then dies again. Talk me through how you handle it.
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