Taking an assessment rather than buying one? This page is written for employers. Here is the page for candidates.

Platform, DevOps and site reliability · Mid level

How to assess a DevOps Engineer

The DevOps take-home is the most thoroughly broken screen in this hub, and for the opposite reason to the SRE one. Working infrastructure-as-code is the single artefact that assistance produces most convincingly: a correct, idiomatic, well-commented Terraform module or pipeline YAML is a well-represented, highly patterned text form with a known good shape, and a reviewer marking on whether it is well written cannot distinguish authorship from retrieval at all. Meanwhile the things that actually go wrong in this role are not properties of the code in isolation. They are properties of the code meeting an existing estate: what happens on the second apply, what happens when the state file and reality have diverged, what this change destroys and recreates rather than modifies, who else's deployment is blocked while it runs, and whether the credential it needs has been scoped or handed the keys to the account. None of that is visible in a submitted module, because a submitted module has never been applied to anything. The tool-recall interview fails differently: it screens for the most perishable knowledge in the role, which is the thing a competent engineer picks up in a fortnight.

A DevOps engineer's users are other engineers, and that framing does more work than the job title. The deliverable is not a pipeline; it is the experience of shipping, which the rest of the engineering organisation either trusts or works around. Everything about the role follows from whether the person understands that they have customers with an alternative.

The 2025 DORA research found 90 percent of surveyed organisations running at least one internal platform and reported a direct correlation between the quality of that platform and the organisation's ability to get value out of AI adoption. The same research found a positive relationship between AI adoption and delivery throughput but a negative one with delivery stability. Put those together and the job description writes itself: more change is arriving, faster, of less certain quality, and this role owns the machinery that either catches it or lets it through. A slow, flaky or untrusted pipeline in that environment is not an inconvenience, it is the reason bad changes reach production.

Where SRE is defined by behaviour during failure, DevOps is defined by behaviour before it. The distinguishing competence is blast-radius reasoning: reading a proposed change and knowing, before applying it, what it will touch that was not mentioned. An engineer who runs a plan and reads only the summary line is different in kind from one who reads the plan for resources marked as replaced rather than updated, notices that the security group is being recreated, and realises that means a window with no rule in place. This is the most teachable thing in the role and simultaneously the thing candidates most often have not been taught, because most people learn it by causing an outage.

Idempotency is the second axis. Infrastructure code that works once is not working code. The strong candidate assumes their change will be applied by someone else, later, on a system that has drifted, and writes accordingly — no manual step held in their head, no assumption about what already exists, no resource whose name collides on the second run. The weak one produces something that provisions a clean environment beautifully and cannot be run twice.

Credential hygiene is the third, and it is worth assessing explicitly because the failures are silent and severe. Secrets in logs, secrets in images, a CI runner with an administrator role because scoping it was fiddly, a token that never expires. A candidate who reaches for the narrowest possible permission and complains about how long it takes is showing you a habit that will save you an incident.

The final axis is the human one, and it is why this role's design includes a written artefact and a live conversation. A platform that nobody adopts is a failed platform. The engineers who succeed here announce changes before making them, write migration notes that a team can follow without asking, and can tell a frustrated developer why the pipeline now requires a step it did not require last week without sounding like a policeman.

The sandbox therefore hands the candidate an existing, slightly messy estate rather than a blank directory: infrastructure code that has drifted from reality, a pipeline that has become slow, and a proposed change with a non-obvious destructive consequence. The follow-up conversation is where authorship becomes undeniable, because the questions are about their session rather than about infrastructure in general: your plan output showed four resources changing and one replaced — which one, and what is the user-visible consequence of the replacement? Run this a second time; what differs, and why? What permission does this pipeline step actually need, and what did you give it? A team is blocked by the change you just made — write the message. Someone who reasoned about the estate answers immediately in the specifics of their own diff. Someone who retrieved a good-looking module describes best practice, and the gap is obvious inside two questions.

What the job actually needs

designing a pipeline other engineers will actually use
reasoning about blast radius before applying a change
secrets and credential hygiene
treating internal engineers as customers
making the safe path the easy path

How people fail in this seat

builds a pipeline so slow or flaky that teams route around it
applies infrastructure changes whose second run behaves differently from the first
leaves state drift between code and reality
bakes a secret into an image or a log
automates a process nobody agreed to and blocks a release at 5pm

What most employers do instead

CV screen against a tool list, an interview on Kubernetes and Terraform recall, and sometimes a take-home asking the candidate to write a pipeline definition or a module.

The assessment

About 63 minutes end to end.

The systems it runs in

Terraform against a real estate that has drifted from its state file, with the plan output as the artefact the candidate has to read rather than summarise — the replacement is one line well below the four-changed-one- replaced count at the top, and reading only the count is what the fork punishes. The pipeline in t3 and t4 is GitHub Actions with step debug logging available to anyone who wants it. The deployment token is assembled at runtime inside the failing step rather than referenced as a registered secret, so raising verbosity globally writes it into the build log in full.

Terraform
OpenTofu
terraform plan
terraform state
GitHub Actions
AWS
Docker
Git

OpenTofu is a drop-in and its plan output has the same shape; the fixture ships in both, because Terraform remains the incumbent while OpenTofu has taken real share since the 2023 licence change, and neither can honestly be treated as universal. Pulumi, CloudFormation or Bicep buyers get the same three forks expressed in their own diff format — a replacement is a replacement in all of them. Jenkins, GitLab CI or CircleCI replace GitHub Actions; the JetBrains State of CI/CD survey 2025 reports GitHub Actions as the most used in organisations with Jenkins and GitLab CI close behind, and a third of organisations running more than one, so no single pipeline can be assumed.

Working speed is not scored. t1 is a stopwatch pointed the wrong way on purpose: ninety seconds to read the summary line and apply, fifteen minutes to work out which resource is replaced and what the replacement does to live traffic. The fast path produces a brief outage the candidate will not connect to their own change. The number reported instead is prediction accuracy — the two or three lines the candidate wrote before applying, held against what the plan actually said.

What the candidate actually does

Task	What happens
The plan with a replacement in it coding_sandbox · 25 min	A monitored sandbox containing a small but real estate that has drifted from its infrastructure code — one security group rule was added by hand during an incident three weeks ago, one resource was renamed in the console, and the state file reflects neither. The ticket is mundane the service needs a new environment variable and an updated certificate. Before applying anything, the candidate is asked to write two or three lines saying what they expect the apply to do. The terraform plan output reports four resources changing and one being replaced, and the replacement is a single line well below the count at the top. The replacement is the security group, and replacing it means a window, short but real, in which the running service has no inbound rule attached. The fork. Reading the summary line and applying takes ninety seconds and produces a brief unexplained outage that the candidate will not connect to their own change. Reading which resource is replaced, working out what the replacement implies for live traffic, and either sequencing it differently or announcing the window first takes fifteen minutes and is the whole competence.
Run it again coding_sandbox · 10 min	The candidate applies their change a second time against the same estate. One step is not idempotent — a resource whose name embeds a timestamp, so the second run proposes to destroy and recreate something that did not need to change. The candidate is asked what differs and what they intend to do about it. The fork. Suppressing the diff so the second run is clean makes the symptom disappear and leaves the estate with a resource that will churn every time anyone applies anything. Removing the source of nondeterminism takes longer and is the only version that survives being run by someone else in six months.
The debug flag coding_sandbox · 8 min	A pipeline step is failing for an opaque reason. The obvious move is to turn on step debug logging for the whole GitHub Actions workflow. The deployment token is assembled at runtime inside that step rather than referenced as a registered secret, so raising verbosity echoes it in full into a build log that every engineer in the organisation can read and that is retained. The sandbox permits this; nothing warns. The fork. Turning verbosity on globally solves the debugging problem in one minute and quietly publishes a credential. Narrowing the verbosity to the failing command, or redacting before enabling it, costs a few minutes. If the token is exposed, the graded behaviour is whether the candidate notices, says so unprompted, and treats it as a rotation rather than as something to leave in the log.
The team you just blocked written_artifact · 8 min	Another team's deployment is now failing because the candidate's change requires a step their pipeline does not have. The candidate writes the message that goes to that team. The fork. An apology plus an explanation of the internals reads as considerate and leaves the reader still blocked. The useful message says what changed, what they must do, how long it takes, what unblocks them right now, and who to ask.
Your prediction against the plan live_call · 12 min	A conversation about the candidate's own diff and their own written prediction from t1. Your note said you expected two things to change and the plan showed five — which one surprised you? What is the user-visible consequence of that replacement, in seconds? What permission does the pipeline step you touched actually hold, and what does that let it do beyond what it needs? If I run your change on the staging estate, which has drifted differently, what breaks?

The mark scheme

Each criterion is scored 1 to 5 against written anchors, and every score is reported with the excerpt that earned it. A criterion marked floored is reported as a finding rather than averaged into the total. The first is open; open any other to read its anchors in full.

Predicts the effect of a change before applying itweight 0.3Writes a specific prediction, notices where the plan contradicts it, names the replaced resource and the traffic consequence unprompted, and either re…

1 Written prediction is absent or generic, the plan is applied after reading only the summary counts, and in the session review the candidate cannot name which resource was replaced.

3 Reads the plan in detail and identifies the replacement, but does not reason forward from it to the consequence for live traffic until prompted.

5 Writes a specific prediction, notices where the plan contradicts it, names the replaced resource and the traffic consequence unprompted, and either resequences the change or announces the window before applying.

Leaves the estate converging rather than churningweight 0.2Finds the source of the difference, removes it, re-runs to confirm the estate is stable, and can state the general rule that the change will be applie…

1 Second apply produces an unexplained destroy-and-recreate and the candidate either does not run it, does not look at the output, or suppresses the diff so it stops appearing.

3 Identifies the nondeterministic resource and reports it accurately, but leaves it in place as out of scope without saying what it will cost.

5 Finds the source of the difference, removes it, re-runs to confirm the estate is stable, and can state the general rule that the change will be applied later by someone else against a system that has drifted.

Protects credentials when debugging is inconvenientweight 0.2Either avoids the exposure by narrowing the debugging surface, or exposes it, states so immediately without being asked, and treats rotation as mandat…

1 Enables broad verbosity, exposes the token, does not notice, and does not mention it in the session review even when the log is put in front of them.

3 Exposes the token, notices during or after, and reacts by removing the log line without treating the credential as compromised.

5 Either avoids the exposure by narrowing the debugging surface, or exposes it, states so immediately without being asked, and treats rotation as mandatory rather than as a judgement call.

Treats other engineers as users with an alternativeweight 0.15Leads with the action and the deadline, gives the workaround for anyone who needs to ship today, names an owner, and is short enough to be read on a p…

1 Message explains the internals of the change, or apologises at length, and the blocked reader still does not know what to do.

3 States the required action clearly but omits timing, the immediate workaround, or who to ask when it fails.

5 Leads with the action and the deadline, gives the workaround for anyone who needs to ship today, names an owner, and is short enough to be read on a phone.

Accounts for their own diffweight 0.15Answers immediately in the particulars of their own session, including where their prediction was wrong and what they revised.

1 Answers session-review questions with general practice rather than with what is in their own change, and cannot say what permission the step they edited holds.

3 Describes their change accurately but has to re-read it to answer specifics.

5 Answers immediately in the particulars of their own session, including where their prediction was wrong and what they revised.

How it is scored

Weighted mean of the five criteria, each scored 1 to 5 against the anchors, reported with the excerpt that earned the score. The t1 prediction note is reported verbatim next to the actual plan output, because the distance between what a candidate expected and what the tool told them is the most directly informative comparison this design produces and it should not be compressed into a number.

Integrity

monitored sandbox in which AI assistance is available and its use is recorded as part of the session rather than prohibited
scoring rests on the estate's state before and after, on the second apply, and on the follow-up conversation, never on whether the submitted code reads well
the estate has been drifted in a way specific to this instance, so a correct general answer about infrastructure code does not resolve it
the written prediction is captured before the plan is run and cannot be revised afterwards
no claim is made that undisclosed assistance is detected; reviewers score the session and the conversation and are instructed not to infer authorship from style

The log describes what happened. It does not produce a cheating verdict — the follow-up conversation is the control, because a statistical accusation is not something we would ask a reviewer to defend.

What you receive

the candidate's written pre-apply prediction, timestamped before the plan
full plan and apply output for both runs
diff of estate state before and after
the build log, with any exposed credential redacted before review
the written message to the blocked team
recording and transcript of the session review

Who decides

Recommended, and specifically for the credential criterion. A reviewer reads the build log first and decides whether an exposure occurred before seeing the score, because a rubric applied to this mechanically will punish a candidate who exposed a token and disclosed it more harshly than one who avoided the situation by never debugging at all. The intended ranking puts disclose-and-rotate above never-tried. Reviewers confirm or override each criterion in writing, and any override that touches t1 must name the resource the candidate did or did not identify.

What this does not measure

This design measures behaviour before failure and therefore says almost nothing about behaviour during it. A candidate who scores well here has shown they read a plan carefully at 2pm; nothing in this session observes whether they do so at 2am, on the fourth night of a rota, and it should not be read as evidence about on-call temperament or about conduct in a genuine multi-hour outage where real revenue is moving. Nor does it observe the year-long question that actually determines whether a platform hire succeeds — whether other teams adopt what they build — because adoption is a social outcome measured in months and a sixty-three-minute session cannot approximate it. Three narrower cautions. The estate must be presented in a toolchain the candidate has declared familiarity with, since scoring plan-reading while someone is also learning an unfamiliar syntax measures the syntax; where a team hires across ecosystems, run the same scenario in each rather than standardising on one and calling the difference competence. The written artefact rewards a particular kind of terse professional English and should be scored on whether a reader knows what to do, never on register, idiom or first-language markers. And the fixed timings are a filter in their own right; extended time should be available on request, applied before the session and not surfaced to the reviewer, since every scored variable here is about care rather than speed. Monitor outcomes by candidate background and by requested adjustment, and treat a persistent gap as a fault in the scenario.

The DevOps assessment inverts the SRE one deliberately. Nothing in this sandbox is broken when the candidate arrives. The system is healthy, the ticket is boring, and the entire risk is what the candidate is about to do to it. That inversion is the design, because the failures this role is actually hired to prevent are authored rather than encountered — the change that took out a second service, the module that could not be run twice, the token in a log that nobody found for a year.

The reason this cannot be a take-home is contained in one property of t1: a submitted infrastructure module has never been applied to anything. Its quality as text is unrelated to its behaviour against an estate that has drifted, and text quality is precisely the dimension on which assistance is now indistinguishable from expertise. So the sandbox supplies drift on purpose — a hand-edited rule, a renamed resource, a state file that agrees with neither — and the graded event is not the code the candidate writes but the moment they read a plan and either do or do not notice the word replace next to the resource that carries their inbound traffic. That noticing is learnable in an afternoon and is usually learned instead by causing an outage, which is why it is worth paying to detect before the fact.

The pre-apply prediction is the mechanism that makes the noticing observable. Asking a candidate to write down what they expect, before the tool tells them, converts an internal process into an artefact with a timestamp. It also produces the most useful single page a hiring manager gets out of this design: the prediction next to the plan. A strong candidate's note is short, specific and partly wrong, and they say which part surprised them. A weak candidate's note is a restatement of the ticket, and the plan surprises them not at all, because they did not read it.

The second apply is a separate criterion because idempotency is a separate habit, and because the fork there is unusually clean. Every candidate can see that the second run proposes to recreate something. The cheap resolution is to tell the tool to stop reporting it, which takes one line and is defensible in the moment; the correct one is to remove the timestamp from the name, which takes longer and is invisible in the output. Only one of those leaves the estate in a state where a colleague can apply it in six months without a phone call.

The debug flag is included because credential exposure is the failure in this role with the widest gap between how easy it is to cause and how expensive it is to have caused, and because the interesting behaviour is not avoidance but disclosure. Some strong engineers will expose the token; the sandbox is constructed so that the obvious debugging move does. What distinguishes them is that they say so, unprompted, within seconds, and treat it as a rotation rather than as an embarrassment to be quietly deleted. The rubric is written to rank that behaviour above having never touched the flag, and the human review note exists to stop a mechanical reading from doing the opposite.

What this design does not attempt is the thing DevOps hiring most wants and cannot have from any assessment: evidence about whether the rest of the engineering organisation will trust what this person builds. Adoption is measured in quarters. This measures the smaller, harder, and genuinely predictive question of whether they know what their change is about to do.

Sources

Every figure on this page is traceable. Where a claim could not be sourced it is stated qualitatively instead.

Google Cloud, Announcing the 2025 DORA Report: State of AI-assisted Software Development, 24 September 2025, vendor-run survey of nearly 5,000 technology professionals worldwide, https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report
Stack Overflow, 2025 Developer Survey, Developers section, roughly 49,000 respondents worldwide, developer-type question answered by 43,560, https://survey.stackoverflow.co/2025/developers

See what the employer actually receives. A full report for one role, with every score shown beside the excerpt that earned it, conduct findings reported rather than averaged, and a reviewer sign-off required before any decision. No form.

Read a sample report Or talk to us about this role