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.
What they are really testing: Whether you can tell the difference between a limit that is too low and an application that leaks, and whether you buy stability first instead of philosophising about memory.
A real interview question
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.
What most people say
drag me
“I would just increase the memory limit, that fixes OOM kills.”
It is the right first move said as if it were the last move. Raising the limit on a real leak only changes how long you wait for the same page, and the interviewer is listening for you to know that.
The follow-ups they ask next
How would you tell a leak from a limit that is just too low, in one graph?
Look at the trough. A correctly sized service returns to a stable baseline when traffic drops. A leaking service never returns to its baseline.
What if it only OOMs in production and never in staging?
Talk about traffic shape and data size. Production payloads, cardinality, and concurrency are usually the missing ingredient, so replay real request sizes.
What the interviewer is listening for
- Raises the limit as containment while naming it as containment
- Uses the shape of the memory curve to separate leak from undersizing
- Names the concrete evidence, OOMKilled and exit code 137
- Adds an alert at a threshold so the next occurrence is caught early
What sinks the answer
- Raises the limit and calls the incident closed
- Cannot say what a leak looks like on a graph
- Jumps straight to reading source code without any runtime evidence
- Blames the platform or Kubernetes without checking the application's own memory profile
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 an OOM kill in production, but the reasoning I would use is: give it more memory and a spare replica so it stops dropping traffic, then read the memory curve, because a flat plateau and a straight climb mean two very different problems.”
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 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?
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