DevOps Engineer Assessment

Why DevOps Engineers are hard to hire well

The title does not describe a job. It describes a compromise. In one company it means the person who owns Terraform and the AWS bill. In the next it means the person who fixes the build when it breaks. In a third it means an SRE with a different reporting line, and in a fourth it means the only engineer willing to carry a pager. Candidates arrive shaped by whichever version they last did, and hiring managers interview against whichever version they need, and the two are matched more or less by accident.

The work also has the awkward property of being invisible when it is going well. A platform engineer who spends six months removing failure modes produces no artefact anyone outside the team can point at. The one who builds a bespoke deployment framework produces something visible, demoable and impressive, and frequently something that becomes the single largest liability on the team within two years. Interviews reward the second candidate almost every time, because they have more to talk about.

Then there is the tooling trap. This is a discipline with an unusually fast-moving surface, and a candidate can accumulate an extraordinary list of technologies without ever having been responsible for any of them at three in the morning. Knowing Kubernetes and having operated a cluster through a control plane upgrade that went wrong are different qualifications, and a CV cannot tell them apart.

What separates the best from the rest

The strongest candidates treat toil as a defect, not as the job. When something is done manually twice, they are already asking whether it should be done at all before asking how to script it. That second question matters more than the first: a great deal of automation exists to make an unnecessary process faster, and the engineer who deletes the process outperforms the one who automates it.

They also behave differently under failure. Weaker engineers reach for the fix they understand; stronger ones reach for the action that restores service, which is very often a rollback they find unsatisfying. They separate mitigation from diagnosis, and they do the diagnosis afterwards with the pressure off. In an incident, the ability to say “we are reverting, we will find out why later” is a competency, and it is a surprisingly rare one.

The third marker is how they treat the developers they serve. Platform work is a product with internal customers, and the failure state is a golden path so opinionated that teams route around it. Good candidates ask what developers currently do to avoid the platform, then fix that, rather than adding a policy that forbids the workaround.

Why interviews alone fall short

Technical screens for this role tend to become trivia. Explain the difference between a StatefulSet and a Deployment. Describe how a rolling update works. These are answerable from documentation, and they select for candidates who have recently revised rather than candidates who have recently operated. Nothing in that format touches the judgement the job is actually made of.

Whiteboard architecture goes wrong the other way. Asked to design a deployment pipeline on a blank page, a candidate produces the pipeline they would build with unlimited time, no legacy, and a team that agrees with them. That is not the problem you are hiring for. Your problem is a half-migrated estate, two teams doing it differently, and a compliance requirement nobody can explain. Situational scenarios put the constrained version of the decision in front of every candidate identically, so what you compare is priority-setting under real conditions rather than an idealised diagram.

Common hiring mistakes in DevOps recruitment

• Hiring the tool list rather than the operating experience - a candidate can list nine observability products and have never tuned an alert threshold that was waking someone up
• Testing infrastructure as code as if it were syntax - writing Terraform is easy, and deciding what belongs in a module, what belongs in state, and what should never be codified at all is the part that takes years
• Skipping incident behaviour entirely - the interview loop discusses building and never asks what the candidate did the last time they made things worse under pressure
• Treating cost as somebody else’s problem - infrastructure decisions land on an invoice, and engineers who have never seen the invoice make consistently expensive choices
• Confusing platform work with permission - hiring someone to run the platform while giving them no authority to change how teams deploy produces a frustrated leaver within a year

The work this role is assessed against

• Build Terraform modules and manage cloud resources across environments
• Configure and operate Kubernetes clusters, including networking, security, and scaling
• Implement and maintain pipelines in Jenkins, GitLab, or GitHub Actions with automated testing and deployments
• Set up dashboards and alerts with Prometheus and Grafana, and integrate logs via ELK or Datadog
• Automate secrets management, image scanning, patching, backups, and disaster recovery tests

Tools and outputs this role works with

AWS, Microsoft Azure, Google Cloud Platform (GCP), Linux, Docker, Kubernetes, Terraform, AWS CloudFormation, Pulumi, Ansible, Jenkins, GitLab CI/CD, GitHub Actions, Argo CD, Flux, Helm, Prometheus, Grafana, Elastic Stack (ELK), Datadog, New Relic, Splunk, HashiCorp Vault, AWS Secrets Manager, Git, Python, Bash, Go, Artifactory, Nexus Repository, OpenTelemetry, and Azure DevOps.