DevOps engineer job description

This role gets opened for two different reasons. Sometimes deployment is painful and nobody owns it. Sometimes an engineering team wants a platform built. The first needs judgement about what not to run, the second needs somebody who enjoys building infrastructure, and they are not the same person. Advertise one and interview for the other and you end up with a well-engineered platform sitting on top of a deployment process that still hurts. Here is a description you can post, and how to tell the two candidates apart.

The job description

We are looking for a DevOps engineer who makes shipping boring and keeps the platform small enough to understand. You will own how code reaches production and what happens when it misbehaves once it is there.

What you will own

The path from commit to production, and how much confidence people have in it
Infrastructure as code, in a state where somebody other than you can change it safely
Monitoring and alerting, including retiring the alerts nobody acts on
Incident response, and the follow-up work that stops the same page repeating
Access, secrets and the security hygiene nobody else treats as urgent

What the job needs

Production ownership of a system that had users on it
One cloud provider in depth, and the judgement to take a managed service instead of running your own
Enough software engineering to be useful inside a code review rather than adjacent to one

Signals we weight heavily

You can name a page that stopped happening because of something you changed
You have chosen the boring option and defended it
You have built something a developer uses without asking you first

What a DevOps engineer is actually accountable for

The visible work is infrastructure. The outcome is that shipping is boring, recovery is quick, and none of it depends on one person being reachable.

Deploys unremarkable enough that nobody waits for a quiet afternoon to do one
Time to recovery when something breaks, which matters more than how rarely it breaks
Alerts that mean something, so people are still reading them three months later
Guard rails developers actually use, rather than a process they route around
Knowing what the infrastructure costs and what that spend is buying

Four ways a DevOps engineer hire looks right and is not

Every one of these passes a resume screen. Ladders eye-tracking study timed the average initial scan at just 7.4 seconds, which is long enough to check the four signals below and not long enough to check anything that would contradict them.

Looks right

Professional-level cloud certification

Cloud certifications test service breadth against exam questions and are genuinely good preparation for naming the right service. They correlate weakly with working out why deploys started failing after a change nobody connected to deploys, which is the situation the seat exists for.

Looks right

Built the full platform: orchestration, service mesh, progressive delivery

Some of the most impressive platform work was never needed. An engineer who has only built platforms has often built them for a team of eight that required none of it. The judgement worth paying for is the one that says a managed service and a single pipeline is enough here, and it rarely appears on a resume because nobody lists what they chose not to build.

Looks right

Extensive on-call experience

Being on the rota is not the same as owning what caused the pages. Somebody paged repeatedly for a year who changed nothing structural has experience of alarms rather than of reliability. The question that separates them is what got quieter, and when.

Looks right

Automated everything, infrastructure as code across the whole estate

Automation that only its author can operate is a second system to maintain and a fresh single point of failure. The test is whether a developer can ship late on a Friday without them. A DevOps hire who concentrates all the knowledge in one head recreates the bottleneck they were brought in to remove.

What to ask for evidence of instead

Four questions, and what the answer actually tells you. Take these into your own process whether or not you ever talk to us.

What page stopped happening because of something you changed?: What it tells you: The cleanest signal available in this interview, and impossible to answer from theory. It separates operators who absorb pain gracefully from engineers who remove the cause of it.
Describe your worst outage. What was the recovery, and what does the follow-up say you changed?: What it tells you: Listen for a timeline, a decision made under pressure, and a change that actually shipped afterwards. Candidates who can describe the cause but not the change were near the incident rather than responsible for it.
How does a developer get a change into production without you?: What it tells you: Whether they build self-service or a ticket queue. An engineer who is proud of being in the middle of every deploy is describing the problem you are hiring them to solve.
What did you decide not to run yourselves, and why?: What it tells you: Build against buy judgement and cost awareness in one question. The best answers include something they would have enjoyed building and deliberately did not.

How Continuity1 runs this funnel

The screening above is the job. These are the numbers it produces when a function owns it end to end, set against the published benchmarks for the same market.

1 in 3: Shortlisted candidates you meet who become the hire; Aligned engagements run nearer 1 in 2, distant ones nearer 1 in 10. The market takes about 180 applicants to make one hire, and that sifting lands on your team rather than ours.; Continuity1 tracked engagements
~3: Interviews your team sits in, per hire; Ashby puts technical roles at 17.6 interviews per hire across the whole process, up 52% since 2021. The rest of that load sits with the function, not with you.; Ashby talent-trends report
1 in 9: Accepted offers that ghost before joining; Indian employers report nearly 4 in 10 offers dropped. We lose 1 in 9.; nasscom community
95%: Offers that close inside your stated band; 20 of the last 21. A flat fee earns nothing from an inflated offer; a percentage of CTC earns more.; Continuity1 tracked engagements

Every brief becomes a success profile before sourcing starts, calibrated with the people who will manage the role. That calibration is the step most hiring skips, and it is why a shortlist either matches the job or matches the job advert.

You review a scored shortlist and make the calls. The filtering never lands on your calendar.

Share a role See the workings and the citations

Questions teams ask

DevOps engineer, site reliability engineer or platform engineer?

The titles overlap and companies use them loosely. Reliability engineering usually implies error budgets and a measurement culture. Platform engineering implies internal tooling run as a product with developers as its users. If what you need is deployment, monitoring and infrastructure owned by somebody competent, say that plainly and let the titles sort themselves out.

Do we need one at our size?

Ask how much engineering time goes into deployment, environments and infrastructure each week, and who is spending it. If the answer is your best engineer, you are already paying for the role at a worse rate. If the answer is nobody, the debt is accumulating quietly and it usually announces itself during an incident.

Should they sit inside the engineering team or separately?

Inside, while you only have one. A separate function at small scale becomes a ticket queue, which recreates the handoff the discipline exists to remove. Separation starts to make sense once there are enough of them to run internal tooling as a product.

How do we test for this in an interview?

Walk them through your actual deployment process and ask what they would change first and what they would leave alone. The second half matters more. Candidates who want to replace everything in week one are the most common and most expensive failure in this hire.