USA
Canada
UK
Europe
Australia
Singapore
Japan
IndiaQ1. What are SLIs, SLOs and error budgets?
Short answer: SLIs measure reliability, SLOs set targets, and the error budget is the allowed unreliability.
Strong answer: An SLI is a measured indicator (e.g., success rate, latency). An SLO is the target for that SLI (e.g., 99.9% success). The error budget is 1 − SLO — the acceptable amount of failure. When the budget is healthy you can ship faster; when it is exhausted you slow down and prioritize reliability. It aligns dev velocity with reliability.
Likely follow-up: What should a team do when it burns through its error budget?
What the interviewer is checking: Core SRE philosophy.
Common mistake: Chasing 100% reliability instead of a meaningful SLO.
Q2. How do you approach incident response?
Short answer: Detect, triage, mitigate, communicate, resolve, then a blameless postmortem.
Strong answer: Acknowledge the alert, assess severity and blast radius, mitigate first (rollback, failover, scale, feature flag) before root-causing, assign clear roles (incident commander, comms), keep stakeholders updated, then fix and verify. Afterward run a blameless postmortem with concrete action items so it does not recur.
Likely follow-up: Why mitigate before finding the root cause?
What the interviewer is checking: Operational maturity.
Common mistake: Debugging root cause while users remain down.
Q3. What is toil and how do SREs manage it?
Short answer: Toil is manual, repetitive, automatable operational work; SREs cap and automate it.
Strong answer: Toil is manual, repetitive, tactical work that scales with service size and has no lasting value (e.g., manual restarts, hand-run runbooks). SRE practice caps toil (often ~50%) and invests the rest in automation and engineering that eliminates it — otherwise ops work grows unbounded with the system.
Likely follow-up: How do you decide what toil to automate first?
What the interviewer is checking: SRE engineering mindset.
Common mistake: Accepting endless manual ops instead of automating.
Q4. How do you design effective monitoring and alerting?
Short answer: Alert on user-facing symptoms (SLOs), keep alerts actionable, and use the four golden signals.
Strong answer: Monitor the four golden signals — latency, traffic, errors, saturation — and alert primarily on symptoms users feel (SLO burn) rather than every cause. Every alert should be actionable and urgent; page-worthy alerts need a runbook. Reduce noise to avoid alert fatigue, and use dashboards for diagnosis.
Likely follow-up: What is the danger of alerting on causes instead of symptoms?
What the interviewer is checking: Observability design.
Common mistake: Paging on every metric, drowning on-call in noise.
Q5. What is the difference between reliability and availability?
Short answer: Availability is uptime; reliability is performing correctly over time under real conditions.
Strong answer: Availability measures whether the service is up (e.g., 99.9%). Reliability is broader — the service does the right thing correctly and consistently, including correctness, latency and durability, over time. A system can be "up" but unreliable (slow, returning errors). SLOs usually capture more than raw uptime.
Likely follow-up: Give an example of an available but unreliable system.
What the interviewer is checking: Conceptual clarity.
Common mistake: Equating a green uptime check with reliability.
Q6. How do you make deployments safe?
Short answer: Progressive delivery (canary/blue-green), health checks, automated rollback and feature flags.
Strong answer: Roll out gradually with canary or blue-green, gate on health/SLO checks, and automate rollback on regression. Decouple deploy from release with feature flags so you can turn features off without redeploying. Small, frequent, reversible changes are safer than big-bang releases.
Likely follow-up: How do feature flags reduce deployment risk?
What the interviewer is checking: Release-engineering knowledge.
Common mistake: Big, infrequent releases with no automated rollback.
Q7. What is capacity planning and how do you approach it?
Short answer: Forecast demand, load-test to find limits, and provision headroom with autoscaling.
Strong answer: Capacity planning forecasts future load from growth and events, load/stress tests to find real limits and bottlenecks, and provisions headroom plus autoscaling to absorb spikes. Track saturation signals and cost. The goal is meeting SLOs under peak load without wasteful over-provisioning.
Likely follow-up: What saturation signals warn you that capacity is running out?
What the interviewer is checking: Scalability planning.
Common mistake: Reacting to outages instead of planning capacity.