Tell me about a time you were on-call for a large-scale customer-facing service and had to investigate and resolve an issue — how did you assess severity and coordinate engineering engagement?
Try This Question Yourself
Practice with feedback and follow-up questions
What is this question about
This question tests whether you can operate calmly and effectively under production pressure, especially when the problem is user-facing and time-sensitive. Interviewers are listening for how you triage incomplete information, decide how serious the issue is, and bring in the right people without creating either chaos or delay. At higher levels, they also want to hear how you balanced immediate mitigation with structured coordination and business impact awareness.
Key Insights
- You should not tell an incident story as a purely technical debugging sequence. The hidden question is whether you understood impact, made sensible severity judgments, and coordinated people in proportion to the situation.
- Be explicit about how you knew the issue was severe enough to escalate. Strong candidates ground severity in customer impact, blast radius, duration, and risk of continued harm rather than in gut feel or who happened to complain first.
- You do not need a dramatic outage to answer well. A strong story can be a partial degradation if you clearly show disciplined triage, timely communication, and thoughtful engineering engagement.
What interviewers probe atlevel
Top Priority
At junior level, interviewers mainly want to see that you did not treat every alert the same and that you used available signals to understand user impact.
Good examples
🟢I first checked error rates, traffic, and whether the failures were isolated to one endpoint or widespread, so I could tell it was affecting checkout for a subset of users rather than the whole site.
🟢Before escalating, I compared the alert with dashboards and recent deploys and confirmed customer requests were timing out in one region, which made the issue both real and user-facing.
Bad examples
🔴I saw the pager and immediately restarted the service because that usually fixes things, then I checked later whether customers were affected.
🔴A sales person said the issue was urgent, so I assumed it was a top-severity incident and pulled in a bunch of engineers right away.
Weak answers react to noise or habit; strong answers show a deliberate first pass to establish real customer impact and scope.
Valuable
Example answers atlevel
Great answers
I was secondary on-call for a payments service when an alert fired for elevated 5xx errors. I first checked dashboards and saw the issue was limited to card authorization requests in one region, so it looked customer-facing but not a full outage. I compared recent changes and logs and noticed failures started right after a configuration update to a dependency, so I paged the primary owner and sent a short summary of impact, timeline, and what I had already checked. While they looked at the dependency side, I confirmed other payment paths were healthy and kept the incident channel updated every few minutes with what we knew and what was still a hypothesis. We rolled back the config, watched error rates return to normal, and then I helped write up the timeline and added a dashboard view that made regional issues easier to spot next time.
I was on-call for a customer support chat platform that smaller businesses used on their websites, and one evening we started getting alerts that message delivery was slowing down. I checked the customer-impact dashboard first to see whether this was a broad outage or a smaller degradation, and it looked like only new conversations were backing up while existing chats were still going through, so I marked it as high priority but not a full stop-the-world incident. I then pulled recent logs and saw our database connections were climbing, so I posted a short update in the incident channel with the symptoms, affected feature, and the checks I’d already done, then asked the backend engineer on call to join because I didn’t want to guess at the root cause alone. While they reviewed the database side, I helped verify that the queue workers were still running and kept support informed so they could answer customers honestly. We found a stuck job was holding connections open, restarted the worker process, and watched the backlog drain within minutes. Afterward I wrote a simple runbook note about the symptom pattern and the first checks I used, because as a junior on-call engineer I found it really helpful to make the next person’s decision faster.
Poor answers
I got paged overnight because our service was having errors, so I started trying the usual fixes like restarting instances. It was still acting up, so I sent a message to a senior engineer and told them the system seemed broken. A few more people joined and we eventually found it was related to a config change, and once that was reverted things were fine. I think it went well because I reacted quickly and stayed online until it was resolved.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Late July, 2026
Hello Interview Premium
Your account is free and you can post anonymously if you choose.