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.
What they are really testing: They want to see whether you have a repeatable path-walking method instead of guessing, and whether you can debug a system you have never seen before without panicking.
A real interview question
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.
What most people say
drag me
“I would check the logs and see if there is an error, and then probably ask the senior engineer or the networking team to take a look.”
It outsources the thinking immediately and shows no mental model of how a request actually travels between two services, so the interviewer cannot tell if you could make progress alone.
The follow-ups they ask next
You run nc and it hangs. What is your single best hypothesis?
Say packets are being dropped, so a security group, NSG or NACL, and name the rule you would check first.
DNS resolves and TCP connects, but the call still times out after 30 seconds. Now what?
Move up a layer. The network is fine, so look at the payments service itself: thread pool, database, downstream dependency.
How would you prove your fix worked?
Same command that failed, now succeeding, plus the error rate on the dashboard back to its normal baseline.
What the interviewer is listening for
- Asks about customer impact before touching a terminal
- Names a specific ordered path: DNS, then TCP, then TLS, then application
- Knows that a hang and a refusal mean different things
- Writes the finding down so the next person does not repeat it
What sinks the answer
- Jumps straight to restarting the service with no hypothesis
- Cannot say what command they would actually type
- Assumes it is a code bug without checking reachability
- Escalates immediately without gathering a single signal
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 debugged this exact pair of services, but here is the path I would walk and what each result would tell me: first DNS, then TCP, then the service itself.”
Keep going with troubleshooting
Junior
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.
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 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