DevOps Engineer interview loops

A DevOps engineer is an engineer who owns the automated route a code change takes to production, built from continuous integration and delivery (CI/CD) pipelines and infrastructure as code. Google's Site Reliability Workbook (2018) describes DevOps as a way of working that joins up development and operations, and argues that site reliability engineering, which puts part of that way of working into practice, is somewhat closer to a defined job than the title DevOps engineer.

As of October 2026 the title covers three overlapping jobs. One is the whole platform a product runs on: a Zscaler posting has its senior DevOps engineer owning the cloud infrastructure, Kubernetes clusters, Terraform code and CI/CD pipelines behind a group of security products (Zscaler). Another is the release path: a Webflow posting has its staff DevOps engineer owning how releases move from the CI pipeline into production, with canary and blue-green releases, feature flags and automatic rollback (Webflow). The third is site reliability work under the DevOps title: a Fivetran posting places its staff DevOps engineer on a site reliability team, responsible for incident response and the reliability of production infrastructure along with the deployment pipeline (Fivetran). The title also turns up on business systems, as in an Elastic posting whose Salesforce DevOps engineer runs releases for its Salesforce systems (Elastic). The loop below is written for the second job and the infrastructure code beneath it, which is also the part the other two share. Service levels, alerting and on-call are a site reliability engineer's to interview for, so a team hiring for the third job will need rounds this loop does not have. The layout of a cloud estate across accounts is a cloud architect's, and keeping a company's own servers, directory and backups working is a system administrator's.

The point of hiring a DevOps engineer is that changing production stops being an event. Other engineers merge a pull request; what happens between that merge and customers running the change is this person's work — the pipeline that builds and tests it, the deploy that puts it on servers, the infrastructure code those servers come from, and the credentials each of those runs with.

The trouble with interviewing for this role is that its vocabulary is easy to acquire. Immutable artifacts, blue-green, least privilege and drift detection can all be recited in the right order by someone who has never owned a pipeline. What cannot be recited is the specific defect in the thing on the table: a pipe that turns a failed build into a green deploy, sixteen planned changes of which one deletes the production database, a canary gate that promotes a release because the release is the only thing still working. So every round below gives the candidate an artifact with defects the interviewer planted and knows, and scores what the candidate finds and what they do about it.

Employers draw the line on AI in the interview in different places. Datadog, whose posting for a CI/CD security engineer linked to its guidelines in October 2026, runs AI-assisted coding interviews for some engineering roles, announced in advance, and otherwise keeps AI out of live interviews; on a take-home, AI may help with research, but the candidate answers for the work live as their own (Datadog, updated May 2026). Anthropic keeps AI out of take-home assessments and live interviews for every role unless it says otherwise (Anthropic, updated July 2025). None of the plans below says either way, and the coding test lets the candidate look anything up without saying whether that includes an assistant. Allowing one would change more than how each round opens, where an assistant reading the deploy script, pipeline pack, Terraform plan or design document could find the planted defects for the candidate. Most of the coding test's hour, and part of the infrastructure as code review, is code the candidate writes, which would become code they direct and check. The pipeline review sends its pack a day ahead and the design review its document two days ahead, and every question in both runs on that material, so an assistant used on it could prepare most of either round, arithmetic included. Decide before the loop starts, and tell the candidate where an assistant may be used, the material sent ahead included.

A loop is a set of round plans in order. Each round scores one to three competencies, every must-have is scored in at least two rounds, and the debrief is held competency by competency rather than round by round, so no single interview decides the hire. How these plans work covers the rest of the method.

Further reading, as of October 2026. Humble and Farley's Continuous Delivery (Addison-Wesley, 2010) argues for building software once and promoting that same build through every environment, rather than building it again for each, which the pipeline review tests with one commit built three times. HashiCorp's Terraform documentation on refactoring modules explains that a resource moved to a new address is planned as a destroy and a create unless a moved block says otherwise, the trap the infrastructure as code review is built on. Google's Site Reliability Workbook has a chapter on canarying releases that covers how large a canary should be, how long it should run and at what time of day, and why it is compared with the rest of the service rather than with the hours before it, the questions the design review asks of a canary that sees about 360 requests. DORA's guide to database change management describes adding new columns beside the old ones, so a release can be reverted while the schema stays as it is, which is how the same round expects a column to be renamed.