MidNetworking

A user reports your service is unreachable or slow. How do you systematically debug the network path?

What they are really testing: Whether you have a layered routine (name, route, connect, app) and the right tools, instead of guessing. This is daily incident work.

A real interview question

A user reports your service is unreachable or slow. How do you systematically debug the network path?

What most people say

drag me

I would ping the server, and if it does not respond I would restart the service.

Ping alone tests only ICMP, which is often blocked, and restarting skips diagnosis entirely. It cannot distinguish a DNS problem from a firewall drop from an app error.

The follow-ups they ask next

  • curl gives "connection refused" versus a hang/timeout. What does each tell you?

    Refused = reached the host but nothing is listening on that port (app down or wrong port). Timeout = packets dropped in transit, almost always a firewall, security group, or routing issue.

  • ping fails but the website works in a browser. Why?

    ICMP is often blocked by firewalls while TCP 443 is allowed. Ping failing does not mean the service is down; test the actual port with curl instead.

What the interviewer is listening for

  • Layered DNS -> route -> port -> app routine
  • Interprets refused vs timeout
  • Checks both ends and the bind address

What sinks the answer

  • Relies on ping alone
  • Restarts before diagnosing
  • No tool beyond ping

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 go layer by layer: [dig for DNS], [ping and traceroute/mtr for the path], [curl -v or nc -vz for the port]. I read [refused = nothing listening, timeout = firewall dropping]. Then I [separate network vs app and check both ends, listening on 0.0.0.0, healthy targets, rules allow the port].

Keep going with networking

All 336 cloud engineer questions

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