Role: DevOps Engineer, CI/CD and infrastructure as codeFull interview loop

Use this loop to hire the engineer who will own the route from a merged pull request to production, at a team that deploys its own services to its own infrastructure several times a week. It assumes the route already exists in some rough form — a deploy script, a CI configuration, a Terraform repository — and that the first months of the job go into making it trustworthy, not into building a platform from nothing. The artifacts are written in Bash, GitHub Actions, Terraform and a GitOps setup on Kubernetes because those are common; nothing in the rounds turns on knowing them, and each translates to your own tools without changing what it finds.

Each round covers a different stretch of that route. The coding round is the last step: a script that puts a build onto servers and has already caused two incidents. The pipeline review is the first, where the build is made and tested, read from a week of run data. The infrastructure review is the ground the build runs on, changed through a pull request whose plan quietly deletes a database. The design review is the route as a whole, redrawn by an engineer on a product team who wants releases to stop being manual. In every round the candidate is given the thing itself, with defects the interviewer planted and knows, because in this job the expensive mistakes are the ones that read well in a description.

Release safety is read three times, because it is where a mistake costs most to undo, and because the damage looks different in each place it is read: a script that can leave a fleet half-deployed, a change to a resource that holds data, and a release that moves the schema and the code at different speeds. The other must-haves are read twice, from different sides. CI/CD pipeline design is diagnosed from run data in the second round and drawn fresh as a promotion path in the fourth. Infrastructure as code is one risky diff in the third round and the definition every environment comes from in the fourth. Pipeline security is what CI will run on behalf of a stranger in the second round, and what the infrastructure pipeline will let any branch do in the third.

The two nice-to-haves are read once each, and both are choices to check against your team. Scripting and automation is read only in the coding round, so the loop will pass a candidate whose code is plain but fails loudly and runs safely twice over one who writes more polished tooling and reasons less carefully about what it does to production; if this hire will mostly build internal tools, add a second coding round and make scripting a must. Developer experience is read only in the pipeline review, so someone who would make every release safe and every pipeline slow can pass; if the problem you are hiring against is engineers routing around the pipeline, read it again in the design review, where the author of the proposal is that engineer. Pipeline security, by contrast, is a must rather than something left to a security team, because a delivery pipeline holds more production access than anyone on the team, and at a company hiring its first DevOps engineer there is usually nobody else looking at it.