Site Reliability Engineer
Latency for one API has doubled, but CPU and memory look normal. How would you narrow down the cause?
What the interviewer is looking for
- This question tests systems troubleshooting. Methodically narrows problems using tools for CPU, memory, disk, network and application traces, forming and testing hypotheses.
- Strong answers: Checks traces for slow downstream calls, database queries, locks, connection pools, garbage collection, network and recent changes, and tests hypotheses one at a time.
- Likely follow-up: What tooling would make that investigation faster next time?
Another way it may be asked: One endpoint got twice as slow, but the servers look fine. What would you investigate next?
A structure to follow: Answer, explain, example, limits
- Step 1
Answer
Give your direct answer in the first sentence so the interviewer knows where you are going.
- Step 2
Explain
Say how it works or why you would do it that way, in plain words before jargon.
- Step 3
Example
Anchor it in something you have actually done or seen, with the detail that shows hands-on experience.
- Step 4
Limits
Say when your approach would not be the right one. It shows judgement.
This is guidance on shape, not a script. Use your own real experience and facts; never invent details to fill a gap. See the STAR guide and answer frameworks.
Common slips
- Reciting a definition without showing you have applied it.
- Using terms you cannot explain if asked a level deeper.
- Claiming experience beyond what you can discuss in detail.
How to practise it
Say the answer in 90 seconds, then answer the follow-up as if it were a new question.
Related questions
- A Linux server is suddenly very slow. What are the first things you would check, and what would each one tell you?
- What is the difference between a service level indicator, a service level objective and a service level agreement, and why would a team care about the difference?
- You are on call, and at two in the morning you get paged that the checkout page is returning errors. What do you do in the first ten minutes?
- How do you decide what deserves to page a human at night versus what can wait for a ticket in the morning?
- Your service has burned most of its error budget halfway through the month. What happens next, and how do you talk to the product team about it?