Site Reliability Engineer Interview Questions UK: 8 Real Questions and What Interviewers Want

Most Site Reliability Engineer interviews in the UK follow a pattern, and knowing it beats guessing. Below are eight questions from our bank of 16, each with a note on what the interviewer is really after.

Eight Site Reliability Engineer interview questions, and what the interviewer is thinking

1. How do you decide what to alert on, and what have you done to reduce alert fatigue?

Why they ask: Tests whether you design monitoring around user impact rather than raw metrics.

2. A pod is stuck in CrashLoopBackOff in Kubernetes. Talk me through how you would diagnose it.

Why they ask: Checks practical Kubernetes troubleshooting skills rather than theory.

3. What counts as toil in SRE, and how do you decide what to automate first?

Why they ask: Looks for understanding of the Google SRE concept of toil and sensible prioritisation.

4. What should a good blameless post-incident review contain, and how do you make sure the actions are actually completed?

Why they ask: Tests incident-learning discipline and cultural maturity.

5. How do you manage Terraform state in a team, and how do you deal with configuration drift?

Why they ask: Assesses real infrastructure-as-code practice in a collaborative environment.

6. After a deployment, p99 latency has doubled but error rates are flat and every dashboard looks green. What do you do?

Why they ask: Tests ability to investigate degradation that SLIs and basic health checks miss.

7. Tell me about a time you reduced on-call noise or improved the experience for engineers on the rota.

Why they ask: Looks for evidence you care about sustainable operations, not only uptime.

8. How would you explain the difference between SRE and a traditional DevOps or operations role, and why does SRE appeal to you?

Why they ask: Checks understanding of the discipline and genuine motivation for it.

A sample answer to question 1

How do you decide what to alert on, and what have you done to reduce alert fatigue?

I alert on symptoms users feel, not every cause. In practice that means paging on SLO burn rate, such as a fast burn over five minutes and a slow burn over six hours, rather than on CPU or memory thresholds. Causes go on dashboards or low-priority tickets. In Prometheus I write multi-window burn-rate rules in Alertmanager, group and inhibit related alerts so one outage produces one page, and route by severity to PagerDuty or Slack. Every page must be actionable and link to a runbook. To cut fatigue I review pages monthly, tag each as useful, noisy or duplicate, and delete or downgrade anything that did not need a human. At my last company that approach took weekly out-of-hours pages from around forty to under ten without missing a genuine incident. I also check that an alert still fires by testing it in staging.

Common mistake to avoid: Paging on CPU or disk thresholds alone; claiming more alerts means better coverage

Want the rest?

Full model answers, key points and common mistakes for all 16 questions are on the Site Reliability Engineer interview questions page. The first five are free, no sign-up needed.