Describe a time you improved on-call for your team. What was actually broken?
What they are really testing: Whether you treat on-call as a system to design rather than a burden to endure. They want to know whether you fixed the causes or just redistributed the pain.
A real interview question
Describe a time you improved on-call for your team. What was actually broken?
What most people say
drag me
“I added more people to the rotation so each person was on call less often.”
It spreads the pain without reducing it, and it makes each person less practised because they see the system less often. If the underlying cause is 40 nightly pages, more people means more tired engineers rather than fewer incidents.
The follow-ups they ask next
How do you keep it from drifting back?
Review page volume in the same forum as other metrics, make every page have an owner and a follow-up, and treat a rising trend as a defect rather than as normal fluctuation.
What if the recurring causes need work the roadmap will not fund?
Quantify the cost in engineer hours, incident time and attrition risk, and present it as a trade rather than a request. On-call load is a business cost that is usually invisible until someone counts it.
How should on-call work for a team that just took over a system they did not build?
Shadowing first, runbooks written by the outgoing team, an explicit escalation path back to them for a period, and no expectation of solo ownership until the team has actually seen the system fail a few times.
What the interviewer is listening for
- Categorises pages before changing anything
- Fixes recurring causes rather than redistributing
- Deletes non-actionable alerts first
- Measures the outcome in both volume and sentiment
What sinks the answer
- Adds people to the rota as the fix
- No data behind the diagnosis
- Treats pages as inevitable
- Ignores the human cost
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 measured first: [pages per week, how many at night, how many actionable, and how concentrated the causes were]. It turned out to be [an alerting and reliability problem, not a rota problem]. So [deleted non-actionable alerts], [fixed the top 3 recurring causes], and only then [improved the rota and handover]. Result: [pages dropped from 11 a week to 2].”
Keep going with behavioural
Mid
Tell me about a time you broke production. What happened and what did you do?
Mid
Tell me about a time you disagreed with a developer about how something should be deployed.
Mid
Tell me about a time you were on call and it went badly.
Mid
Tell me about a mistake that cost the company money.
Mid
Walk me through a time you inherited a system nobody understood. Where did you start?
Mid
Tell me about something repetitive you automated. How did you decide it was worth it?
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