MidTroubleshooting

An app is slow but CPU, memory and disk all look normal. Where do you look next?

What they are really testing: Whether you know that the classic resource metrics miss most real bottlenecks. They want to see you think about waiting rather than consuming.

A real interview question

An app is slow but CPU, memory and disk all look normal. Where do you look next?

What most people say

drag me

If the resources look fine then the application code must be inefficient.

It jumps to a conclusion that is expensive to act on and usually wrong. Blaming code before checking pools, locks and dependency latency sends a team to optimise algorithms while the real problem is a connection pool of size 10.

The follow-ups they ask next

  • How do you confirm connection pool saturation?

    Instrument pool metrics: active connections, idle, and time spent waiting to acquire. Wait time above zero under load is the direct proof, and most pool libraries expose it.

  • Why does CPU throttling hide in average utilisation?

    The quota is enforced per short period. A container can burn its quota in the first part of each period and be frozen for the rest, which averages to low usage while adding real latency to every request.

What the interviewer is listening for

  • Reframes as waiting rather than consuming
  • Names connection pool saturation first
  • Knows throttling hides in averages

What sinks the answer

  • Blames application code immediately
  • Only knows the classic host metrics
  • No tracing instinct

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.

Normal resources with bad latency means [waiting, not working]. So I check [connection and thread pool saturation, the most common cause], [dependency latency, which host metrics never show], [lock contention], and [CPU throttling against a cgroup quota, which averages out invisibly]. I would [get a trace of a slow request] rather than checking all five.

Keep going with troubleshooting

All 87 devops 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