A team tells you their service is slow and asks for more CPU. Their dashboard shows CPU usage at only 40 percent. They are convinced the platform is broken. How do you run this?
What they are really testing: Whether you can hold your ground against a confident wrong hypothesis, and whether you understand that CPU utilisation and CPU throttling are two completely different numbers.
A real interview question
A team tells you their service is slow and asks for more CPU. Their dashboard shows CPU usage at only 40 percent. They are convinced the platform is broken. How do you run this?
What most people say
drag me
“The CPU is only at 40 percent so it is not a CPU problem, it must be their code. I would tell them to profile it.”
It is technically defensible and operationally useless. It ends the conversation, leaves the service slow, and misses the fact that a container can be throttled hard while its average utilisation looks calm and healthy.
The follow-ups they ask next
They ask why the limit exists at all. Should you just remove it?
Explain the trade off honestly. Removing limits stops throttling but lets one noisy service starve its neighbours, so the answer is usually a correct limit and a request that reflects real usage.
How do you handle it if you were wrong and it is the platform?
Say so plainly and quickly. Credibility comes from being the person who follows the number, not the person who defends their team.
What the interviewer is listening for
- Grants headroom immediately as a cheap experiment, not as a surrender
- Knows throttled periods is a different number from CPU utilisation
- Connects throttling to a bad p99 with a healthy p50
- Is genuinely willing to be proven wrong by the data
- Fixes the dashboard so the next team does not repeat the confusion
What sinks the answer
- Dismisses the team because the utilisation graph looks fine
- Cannot name any signal beyond CPU percentage
- Removes all limits everywhere as a blanket fix
- Turns a technical disagreement into an ownership argument
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 diagnosed CPU throttling before, but here is how I would reason about it: give them the extra CPU first so it stops hurting, then look for a signal that is not average utilisation, because an average over a minute can hide a container being frozen inside every 100ms window.”
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