Site Reliability Engineer Interview Question

Half your services start timing out at once and nothing was deployed. How do you run that incident?

What the interviewer is probing, how to structure your answer, and a spoken example you can adapt.

Quick answer

Declare the incident, assign an incident commander, and separate investigation from communication. Then hunt the shared dependency: authentication, DNS, a database, a certificate, the service mesh control plane, or a cloud zone. Check what changed outside deploys, meaning config pushes, feature flags, DNS records, expiring certs, and provider status. Mitigate before you diagnose by shedding load, failing over, or disabling the suspect flag, then verify with user facing SLIs.

Why interviewers ask this

Simultaneous, broad failure is the signature of a shared dependency, and interviewers want to see whether your instinct is to look for the common cause rather than debug ten services in parallel. They are also assessing incident command: role separation, structured communication, and the discipline of mitigating before fully understanding.

How to structure your answer

  • Set up incident structure first: commander, comms, scribe.
  • Reason from the pattern: simultaneous and broad means shared dependency.
  • Enumerate what changed that is not a deploy.
  • Mitigate with the reversible lever you have, before root cause.
  • Confirm recovery against user facing signals, then schedule the postmortem.

Example answer

Spoken example, first person

Broad and simultaneous with no deploy means it is almost never ten independent bugs, it is one thing underneath all of them. So I get incident structure up immediately, commander and a comms person, then start on the shared layer list: auth service, DNS, the primary database, the mesh control plane, certificates, and cloud provider health. In parallel I ask what changed that is not code, because config pushes and feature flags are changes people forget to count. We had exactly this pattern once and it turned out to be an internal certificate authority renewal that had quietly expired an intermediate, so every mutual TLS handshake started failing at the same minute. The tell was that failures were connection level rather than application level. While that investigation runs I want a mitigation lever ready, usually shedding non essential traffic or failing over to the secondary region, because I would rather be degraded and stable than fully broken while we think. Then verify with real user metrics, not just green pods.

Walking into this interview soon? GhostPilot listens to your live call, spots the question the moment it is asked, and puts a structured answer on your screen in real time. Try it on your next mock, or grab a $29 Session Pass, no subscription, for the real thing.

See how it works

Follow-up questions to expect

  • How would you distinguish a DNS problem from a network problem quickly?
  • What is your policy on failing over to another region during an unknown fault?
  • How do you keep stakeholders informed without derailing the responders?

Related site reliability engineer questions

Your interviewer will ask their own version of this. Paste your actual job description into the free Question Predictor and get the 20 questions that role is most likely to ask, with what each one is really probing.

Predict my questions

Rehearse the hard questions before they are asked

Practise with a live copilot, then walk in ready. A $29 Session Pass gets you through the interview with no subscription and no lock-in.

Get GhostPilot