SRE Interview Questions, and What a Strong Answer Shows

What is the difference between an SLI, an SLO, and an SLA? The indicator is a measurement, such as the proportion of requests served successfully under 300 milliseconds. The objective is the target for that measurement over a window. The agreement is a contract with consequences, usually looser than the internal objective.

How would you choose an SLO for a service? A strong answer starts from users: which journeys matter, what latency or failure they notice, and what the service has actually delivered historically. It avoids picking nines for their own sake and explains that a target stricter than users need spends engineering effort for nothing.

What do you do when the error budget is exhausted? Show that the budget drives decisions: slowing risky releases, prioritising reliability work, and agreeing that policy in advance with product owners so it is not negotiated during an outage.

Expect open scenarios: a host is slow, a service returns intermittent errors, a disk is full, DNS resolution fails for some clients.

The interviewer is watching your method. Start with scope: one host or many, one endpoint or all, since when, what changed. Check the obvious resources, CPU, memory, disk, file descriptors, network, before exotic causes. Use the tools you would really reach for and say why: load averages versus CPU usage, memory pressure and the OOM killer, disk space versus inode exhaustion, connection states, packet loss, resolver configuration.

A classic: a disk is full, but deleting files does not free space. The answer is that a process still holds the deleted file open. Finding it and restarting or signalling the process releases the space. Knowing why matters more than the command.

Another: what happens when you request a URL? Use it to show depth where you have it, such as DNS resolution and caching, TCP and TLS handshakes, load balancers, and where each step can fail.

• Retries. When do retries help, and when do they make an outage worse? Strong answers mention exponential backoff with jitter, retry budgets, and idempotency.
• Timeouts. How do you set them across a chain of services? The caller's timeout must exceed the callee's, and every hop needs one.
• Cascading failure. How does one slow dependency take down a fleet? Thread and connection pool exhaustion, queue growth, and retries amplifying load. Mitigations include load shedding, circuit breakers, and bulkheads.
• Consistency. What happens during a network partition, and what does your system choose to give up?

Design questions, such as building a rate limiter or a job scheduler, test the same instincts at larger scale. State requirements, sketch the simplest design, then find where it fails.

Describe an incident you handled, start to finish. Structure matters: detection, impact, your role, mitigation, diagnosis, communication, and what changed afterwards. Be honest about what went wrong, including your own mistakes. Interviewers distrust stories where the candidate was the hero and nothing was learned.

You are paged at 3am and the site is down. What do you do first? Acknowledge, assess impact, and mitigate before you diagnose: roll back a recent change, fail over, or shed load. Declare an incident and pull in help early. Root cause can wait until users are served.

What makes a good postmortem? Blameless framing, an evidence-based timeline, contributing causes rather than a single culprit, and actions with owners that actually get done.

SRE coding rounds usually involve practical tasks: parse logs and summarise errors, write a script that safely rotates or cleans files, implement a small rate limiter, or poll a health endpoint with backoff. Write readable code, handle errors, and think about what happens when the script runs twice or fails halfway. Idempotency and safety are the SRE-specific signals.