Cohesyve · Practice for candidates
Preparing for a Site Reliability Engineer role? Start by finding out where you stand.
Import the actual job you're going for, run a simulation built from it, and get a scored report showing which of these areas you're weakest in — before you spend weeks studying the wrong thing.
3
free assessments
$0
no card required
Full
scored report every run
Every
question type included
3 free assessments · No card required · Pro from $16/mo
Overview
Site reliability engineering interviews test a specific kind of judgement: how you decide what reliability is worth, and what you do in the first ten minutes of an outage. Expect a debugging exercise on a system you have never seen, a distributed systems design round, a coding round, and an interview built entirely around an incident. The candidates who do best are not the ones with the widest tool knowledge but the ones who can reason clearly under an interviewer's deliberate ambiguity and who put mitigation before curiosity.
The hiring process, stage by stage
Recruiter and hiring manager screen
Establishes the scale of systems you have supported, your on-call history, and whether you lean towards software engineering or operations. SRE teams differ sharply in that balance.
How to prepare: Prepare a concise account of the largest system you supported, its traffic profile, your on-call frequency, and one reliability improvement you led. Be honest about whether you write production code regularly.
Troubleshooting or debugging exercise
You are given a degraded system with partial information — dashboards, logs, a description of symptoms — and asked to find the cause. The scenario is usually designed so the obvious answer is wrong.
How to prepare: Practise a repeatable method: establish the blast radius and start time, correlate with deploys and config changes, then work down the request path narrowing by evidence. Rehearse asking for specific data rather than guessing.
Distributed systems design
Design a system for a stated availability target, then defend it against failure injection: a region loss, a dependency slowing down, a cache falling over, a retry storm.
How to prepare: Prepare to lead with the reliability requirement rather than the architecture. Have crisp answers on timeouts, retries with jitter, circuit breaking, backpressure, graceful degradation and what happens when the cache is cold.
Coding round
Practical programming rather than puzzles: parse logs, write a health-checking tool, implement rate limiting or exponential backoff, or automate a remediation. Usually Python or Go.
How to prepare: Practise writing small, correct command-line tools under time pressure, with error handling and no external dependencies. Implement exponential backoff with jitter and a token bucket from scratch until it is automatic.
Incident and reliability culture interview
A structured conversation about a real outage you handled, plus questions about postmortems, error budgets, and how you push back on feature launches that would breach a reliability target.
How to prepare: Prepare one incident in forensic detail with a timeline in minutes. Practise describing your own mistakes without defensiveness, and prepare an example where you argued for or against a launch on reliability grounds.
What to study
Service level objectives and error budgets
This is the conceptual core of the discipline, and interviewers use it to separate SRE candidates from general operations candidates.
Failure modes in distributed systems
Design rounds are built around cascading failure, and the wrong retry policy is the most common cause interviewers probe.
Observability in practice
The debugging round hands you a system you do not know, and your speed depends entirely on how well you use telemetry.
Capacity, load and performance
Interviewers ask how you would survive a traffic spike, and vague answers about autoscaling are marked down.
Incident command and postmortems
A large part of the job is behaviour during an outage, and every SRE loop contains an interview about it.
Cohesyve for candidates
Practise a Site Reliability Engineer assessment before the real one
Run the same AI job simulations companies use to evaluate applicants. You get a scored report showing where you're strong and where you're not, plus what to work on.
Your preparation plan
Four weeks out
Rebuild the theory you use implicitly but cannot articulate
- •Revise service level objective design until you can propose an indicator and a target for an arbitrary service in two minutes
- •Work through cascading failure patterns and write out how you would prevent each one
- •Refresh your primary language enough to write a small tool without reference
- •Document the largest incident you handled, minute by minute, while you still remember the detail
Two weeks out
Practise debugging and design aloud under ambiguity
- •Run three unfamiliar-system debugging scenarios out loud, forcing yourself to state a hypothesis before requesting data
- •Design two systems to a stated availability target, then have someone inject a failure halfway through
- •Implement exponential backoff with jitter and a token bucket rate limiter from scratch
- •Rehearse describing your own error in an incident without defensiveness
The final week
Full-length rehearsal and calibrating your pacing
- •Sit one complete timed assessment covering debugging, design and coding rather than isolated drills
- •Prepare your questions about their on-call load, error budget policy and postmortem follow-through
- •Practise saying what you would check next when you do not know the answer, since interviewers create dead ends deliberately
- •Tighten the weakest of the three rounds instead of revising what already works
The day before and the day of
Arrive calm with a method rather than a memorised list
- •Test your setup: terminal, editor, screen share and a whiteboard tool for the design round
- •Reread your incident timeline once and stop taking in new material
- •Write your debugging opening on a card: blast radius, start time, what changed
- •Plan to mitigate first in every scenario, and say so explicitly before diagnosing
Questions to expect
“Latency has risen sharply for one service. Where do you start?”
What they're really asking: Whether you narrow the problem by evidence or start restarting things.
How to answer: Begin by scoping: is it all users or a subset, all endpoints or one, when exactly did it start. Correlate that timestamp with deploys, config changes and feature flags first because that resolves the majority of cases. Then move down the request path with traces, looking at percentile latency rather than averages, and separate the service's own time from time spent waiting on dependencies. Say what you would mitigate with while investigating.
“How would you set a service level objective for a checkout service?”
What they're really asking: Whether you derive a target from user impact or pick a number of nines that sounds respectable.
How to answer: Choose an indicator the user experiences — the proportion of checkout requests that succeed within a latency threshold — measured as close to the client as you can. Set the target from what users tolerate and what the business needs, not from what the system currently does. Then define the error budget policy: what specifically stops when the budget is exhausted, and who has the authority to enforce that.
“A dependency is slow but not down. How do you stop it taking your service with it?”
What they're really asking: Whether you understand that partial degradation causes worse outages than clean failure.
How to answer: Explain that unbounded waiting exhausts your own request capacity, so the first defence is a timeout tighter than your own latency budget. Add circuit breaking so you stop sending traffic to a failing dependency, bounded retries with jitter so you do not amplify the problem, and a degraded response path — cached, partial or default — so the user gets something. Mention isolating the dependency's resource pool so it cannot starve unrelated requests.
“Tell me about an incident where you made things worse.”
What they're really asking: Whether you can be honest about your own errors, which is a prerequisite for a blameless culture.
How to answer: Pick a real one and give the timeline plainly: what you believed at the time, the action you took, how you noticed it was wrong, and how you recovered. Do not soften it with hedging. Close on the system-level lesson — the missing guardrail or the confusing signal that made your action reasonable — rather than only on personal resolve.
“How would you handle a traffic spike ten times normal volume?”
What they're really asking: Whether you know that scaling has limits, and which parts of your system will not scale.
How to answer: Separate what you do in advance from what you do live. In advance: load test to find the real bottleneck, ensure headroom, cache aggressively and decide the degradation order for non-essential features. Live: shed load at the edge, protect the critical path, and prioritise the paths that make money. Name the things autoscaling will not fix — database connection limits, cold start times, and third-party rate limits.
“What makes a good postmortem?”
What they're really asking: Whether you see postmortems as organisational learning or as paperwork after the fact.
How to answer: Describe a factual timeline including detection and mitigation times, contributing factors rather than a single root cause, and an honest account of what made diagnosis slow. Emphasise that actions need owners and scheduling like any other work, and that the quality signal is whether last quarter's actions actually landed. Add that a good postmortem is safe to write, which requires a genuinely blameless culture rather than a stated one.
What to bring as evidence
A detailed incident timeline you can walk through in minutes, including your own missteps
A reliability improvement you led with a measurable change in availability, latency or page volume
A service level objective you defined, including the indicator, the target and the reasoning behind it
Tooling or automation you wrote that reduced manual response work during incidents
An example of alert pruning or on-call load reduction, with figures for before and after
A capacity or load-testing exercise where you found a bottleneck before it caused an outage
Common mistakes
Diagnosing root cause while the service is still down instead of mitigating first
Proposing retries without jitter, budgets or circuit breaking, which turns a slowdown into an outage
Quoting availability targets with no error budget policy behind them
Answering debugging questions with tools rather than hypotheses
Describing incidents in a way that quietly blames another team or an individual
Ignoring the coding round on the assumption that SRE interviews are purely operational
Questions to ask them
- ?
How many pages does a typical on-call week generate, and what proportion are actionable?
- ?
Do you have error budgets, and has a launch ever actually been delayed because one was exhausted?
- ?
Who writes postmortems, and what proportion of last quarter's action items were completed?
- ?
How much of the team's time is spent on reliability engineering versus reactive operational work?
- ?
How is on-call compensated and rotated, and what is the handover process?
- ?
Where does the boundary sit between this team and the product teams for production ownership?
Frequently Asked Questions
How much coding is in an SRE interview?
More than most candidates expect. Many loops include a practical programming round — parsing, tooling or implementing a rate limiter or backoff — and treat weak coding as disqualifying regardless of operational depth.
What is the difference between SRE and DevOps in interviews?
SRE interviews concentrate on reliability as a measurable target: service level objectives, error budgets, cascading failure and incident command. DevOps interviews lean more towards delivery pipelines and automation. There is real overlap, so read the responsibilities and ask about on-call expectations.
I have not worked at very large scale. Am I out of the running?
Not necessarily. Interviewers care whether your reasoning generalises. Be specific about the scale you did operate at, and show that you understand which of your practices would break at ten times the traffic and why.
How should I answer a design question when I do not know the answer?
Say what you would measure to find out, and name the trade-off you are weighing. Interviewers construct dead ends on purpose. A structured 'here is how I would narrow this down' scores far better than a confident guess.
Is it worth rehearsing the assessment round in advance?
It is, because the debugging and coding rounds are timed and reward method over recall. Cohesyve lets you run a simulation built from a real SRE posting and gives three free scored assessments, with a report on where your approach cost you time.
Practice
What a Site Reliability Engineer assessment tests, and how it's scored →
Career guide
What a Site Reliability Engineer actually does, and where the path leads →
Prepare for another role
Cohesyve · Practice for candidates
Don't walk in guessing. Find out where you stand first.
Three free scored practice runs, a full report on every one, and a learning pathway built from what you actually got wrong. No card required.
3
free assessments
$0
no card required
Full
scored report every run
Every
question type included
3 free assessments · No card required · Pro from $16/mo
For hiring teams
Hiring for a Site Reliability Engineer role? See how your applicants perform before you spend interview time.