Free Site Reliability Engineer Practice Assessment (2026)

Cohesyve · Practice for candidates

Going for a Site Reliability Engineer role? Find out how you'd actually score.

Run a Site Reliability Engineer simulation built the same way employers build theirs, and get a full report showing exactly where you lost marks — before it counts.

free assessments

no card required

Full

scored report every run

Every

question type included

3 free assessments · No card required · Pro from $16/mo

Overview

SRE assessments centre on how you behave when a system is misbehaving and the evidence is incomplete. You are typically given dashboards, logs and an alert, and asked to restore service, then explain what you would change so the same failure cannot recur quietly. Coding appears, but the weight sits on diagnosis, prioritisation and the discipline of the write-up afterwards. This page covers the formats and the marking.

Why employers assess this role

Reliability work is judged by what happens in the worst hour of the quarter, and that is not something a conversation can establish. Employers assess practically because the difference between an engineer who mitigates first and one who starts reading code during an outage is enormous, entirely behavioural, and visible within minutes of a realistic scenario.

What gets tested

Incident diagnosis from partial evidenceMitigation before root-cause investigationSLOs, error budgets and alert designObservability — metrics, logs and tracesCapacity, load and failure modes at scaleAutomation and toil reductionBlameless postmortem writingSystems and networking fundamentals

The format

Duration

60–120 minutes

Question types

Live or written incident scenario with supplied evidence
Design or repair an alert and its underlying SLO
Debug a systems-level problem from logs and metrics
Write a postmortem or a reliability improvement proposal

Levels

Entry · Mid · Senior

What you'll be asked to do

Work an incident

The defining format. You are given a symptom and a set of dashboards and asked what you do next, in order. The order is what is being marked.

•Error rate rises sharply after a deploy; decide the first three actions
•Latency climbs on one region only while the others are unaffected
•A dependency is timing out and requests are queueing upstream

Reason about SLOs and alerting

Assessors want to see alerts tied to user-visible impact rather than to component metrics, and a defensible position on when a page is justified.

•Define an SLI and an SLO for a checkout service and say what you would page on
•Reduce a noisy alert without losing coverage of the failure it was meant to catch
•Decide whether to halt a release when the error budget is nearly exhausted

Diagnose systems behaviour

Problems that live below the application: saturation, connection exhaustion, retry storms, memory pressure. Reasoning about the mechanism is scored heavily.

•A service degrades progressively over days and recovers on restart
•A retry policy turns a partial outage into a total one
•Connections exhaust after an upstream slowdown despite low CPU

Write it up afterwards

A postmortem or a proposal. Marked on whether it identifies contributing factors without blaming individuals and produces actions someone could actually complete.

•Write the timeline and contributing factors for a supplied incident
•Propose three actions and rank them by reduction in recurrence risk
•Explain why the alert did not fire before customers noticed

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.

Sample tasks — and what strong looks like

Error rates jump to a fifth of all requests immediately after a release. Describe what you do, in order.

Entry

What strong looks like: Mitigates first by rolling back or shifting traffic, communicates status while doing so, and only then investigates the cause with the release as the leading hypothesis. Weak answers open the diff and begin reading code while the error rate stays elevated.

A service becomes progressively slower over several days and returns to normal after a restart. Explain how you would identify the cause.

Mid

What strong looks like: Recognises the signature of a resource that accumulates — memory, connections, file descriptors, an unbounded cache — and confirms with the relevant metric over the full period rather than the last hour. Weak answers schedule a nightly restart and treat the problem as solved.

An alert pages the on-call engineer several times a week and is almost always resolved as no action needed. Fix it.

Mid

What strong looks like: Traces the alert back to whether it reflects user-visible impact, replaces a threshold on a component metric with a burn-rate alert against an SLO, and states clearly what will now be a ticket rather than a page. Weak answers raise the threshold until it stops firing and lose the coverage entirely.

Write a postmortem for an outage in which a database failover took forty minutes because the runbook was out of date.

Senior

What strong looks like: A factual timeline, contributing factors covering both the technical and the process failure, and actions with owners that address detection and recovery time rather than only the immediate trigger. Weak answers name the individual who ran the stale runbook and stop there.

How to prepare

#1
Practise saying the mitigation step out loud before the diagnosis step, because the ordering is the clearest single signal assessors look for.
#2
Rehearse reading a dashboard under time pressure and stating what you would rule out first, since a method beats a lucky hypothesis in the marking.
#3
Learn to express reliability in terms of an SLI, an SLO and an error budget, as component-level thinking reads as junior regardless of technical depth.
#4
Study the classic saturation failure modes — connection pools, thread exhaustion, retry amplification — because they recur across almost every scenario bank.
#5
Write a postmortem for a real incident you have lived through and check that it contains no individual blame and no action nobody owns.
#6
Sit one full timed scenario including the written section, since candidates commonly run out of time before the part that shows seniority.

Common mistakes

Investigating the root cause while the outage continues instead of mitigating first.
Alerting on component metrics such as CPU rather than on user-visible symptoms.
Silencing a noisy alert by raising its threshold and removing the coverage with it.
Adding retries without backoff or a circuit breaker and amplifying a partial failure.
Writing a postmortem that identifies a person rather than the conditions that allowed the failure.
Proposing improvement actions with no owner, no scope and no way to tell they were done.

How it's scored

Criterion	What strong looks like
Incident sequencing	Service is restored first, communication happens alongside, and investigation follows rather than precedes mitigation.
Diagnostic reasoning	Hypotheses are stated and eliminated against the available evidence rather than pursued because they are familiar.
Reliability framing	Impact is expressed in terms of users and error budget, and alerting decisions follow from that rather than from component thresholds.
Systems depth	The mechanism behind the failure is explained — saturation, contention, amplification — not merely the component that broke.
Postmortem quality	A clear timeline, contributing factors without blame, and prioritised actions that reduce detection and recovery time.

Frequently Asked Questions

How much coding is in an SRE assessment?

Usually some, but less than in a software engineering assessment. Expect a scripting or automation task alongside the scenario work, with the heavier weighting on diagnosis and the written reasoning.

What if I do not recognise the technology in the scenario?

Say so and reason from the observable behaviour. Scenarios are frequently written against unfamiliar stacks on purpose, because the point is your method for narrowing a failure rather than your familiarity with one vendor.

Is it acceptable to say I would escalate?

Yes, when you also say what you would do while waiting and what information you would hand over. Escalation used as a substitute for any action of your own is what loses marks, not escalation itself.

How is seniority distinguished in these assessments?

Mainly through the write-up and the alerting questions. Restoring service is expected of everyone; framing impact against an error budget and proposing changes that shorten detection time is what reads as senior.

Where can I practise a realistic incident scenario?

Rehearse one that is actually scored rather than one you mark yourself. Cohesyve includes three free assessments with a full report and a learning pathway, which is enough to test whether your incident ordering holds under a timer.

Practise another role

Cloud Architect →Cybersecurity Analyst →Network Engineer →Database Administrator →

Cohesyve · Practice for candidates

Practise a Site Reliability Engineer assessment now — free.

Three free scored assessments, a full report on every run, and a learning pathway built from what you got wrong. No card required.