How to hire DevOps, platform and cloud engineers

What the role is for

Before writing a job description, write down the problem. Teams usually hire into this area for one of four reasons, and each one points to a different person:

• Releases are slow or risky, and developers wait on manual steps. You need someone to automate build, test and deployment for the teams you already have.
• Several teams are rebuilding the same infrastructure in different ways. You need someone to build a shared platform that those teams can use without asking for help each time.
• A live service has outages, noisy alerts or no clear picture of its health. You need someone who treats reliability as engineering work, with monitoring, incident response and fixes that stick.
• You are moving to the cloud, changing provider or bringing cloud costs under control. You need someone who has done that kind of change before, often for a defined period.

Write the six-month outcome in a sentence, for example “every service deploys through one pipeline with automated tests” or “we know within minutes when the product is down, and why”. That sentence does more to attract the right engineer than any list of tools, and it gives you a fair way to compare candidates later.

DevOps, platform, SRE or cloud engineer: what the titles usually mean

The titles are used loosely, and candidates know it. Many people have held two or three of them while doing similar work. The table shows how the terms are most often used, as a guide to the conversation rather than a rule.

If your role mixes these, say so plainly in the brief. “A platform engineer who will also share the on-call rota” is clearer than a combined title, and it stops candidates guessing at what the job involves.

Essential skills and what can be learned

Most briefs in this area list far more technologies than the work requires. Every extra essential requirement removes good engineers from the field, so separate the two lists honestly.

Usually essential

• Confident Linux and networking fundamentals: how services talk to each other, and how to find out why they have stopped.
• Infrastructure defined as code and kept in version control, whichever tool was used.
• Hands-on experience with at least one major cloud provider in a live environment.
• Building and maintaining continuous integration and deployment pipelines.
• Scripting or programming well enough to automate their own work and read the application code they deploy.
• Calm, methodical troubleshooting under pressure, and clear written communication about what went wrong.

Usually trainable

• Your specific cloud provider, if they have used another one in depth.
• A particular infrastructure-as-code tool, CI system, monitoring stack or container orchestrator.
• The details of your product, your domain and your internal conventions.
• Formal reliability practices such as service level objectives, if they already treat incidents as engineering problems.

Two areas need more care. Security and compliance experience matters where you handle sensitive or regulated data, and it is worth stating as essential there. Container orchestration at scale is a real skill, but many roles need someone who can run it sensibly rather than someone who has built a large estate from scratch.

Why these roles can be hard to fill

• The people you want are usually employed, valued and busy. Many are not reading job adverts, so a role that relies on applications alone reaches only part of the market.
• Unclear titles and long tool lists make good engineers assume the role is not for them, or that the employer does not yet know what it needs.
• On-call expectations put people off when they are vague. Candidates want to know how often, how it is paid or recognised, and how noisy the alerts are.
• Competing offers often arrive during a slow process. A strong engineer with several conversations will not wait weeks between stages.

How long a search takes depends mostly on things you control: how specific the essential list is, how competitive the package is for your location and working pattern, and how quickly you move once you meet someone good. Narrow requirements, a fully office-based pattern or a below-market package each lengthen a search more than the title does.

Salary and package: what moves it

Pay for these roles varies widely, and published averages hide most of the variation. The factors that move it most are the level of ownership (running a platform for many teams pays differently from supporting one), on-call responsibility, the depth of cloud and security experience required, location and working pattern, and how many other employers want the same profile at the same time.

Rather than relying on a general salary survey, check your range against the specific profile you need before you advertise. If you want a benchmark built around your role, our salary benchmarking service does that. Be explicit about on-call pay or time off in lieu, flexibility and learning budget: for experienced engineers these often decide between two similar offers.

How to assess DevOps and platform engineers

The aim is to see how someone thinks about real systems, in a process short enough that people in demanding jobs will finish it. A process that works well usually looks like this:

• A first conversation about the role and the problem, with the hiring manager rather than a script.
• A technical discussion where the candidate walks through infrastructure they built, a change they made and an incident they handled, with follow-up questions on the trade-offs.
• One short practical exercise close to your real work, such as reviewing a deployment pipeline, reading an infrastructure definition or diagnosing a broken environment together.
• A conversation with the people they would support, because this role succeeds through other teams.

Avoid long unpaid take-home builds and puzzle-style coding tests unrelated to the job. They mostly measure how much spare time a candidate has, and the strongest people withdraw. Agree in advance what a strong answer looks like for each stage, so interviewers compare candidates against the role rather than against each other's impressions.

Why good candidates drop out

• Too many stages, or long gaps between them, while another employer moves faster.
• An on-call commitment that is only explained at the offer stage.
• A role described as platform engineering that turns out to be a ticket queue of manual requests.
• Interviewers who cannot explain the current infrastructure or why the role exists.
• A package that only becomes clear late, after the candidate has invested time in the process.

Most of these are fixed before the search starts: an honest description of the current state, the on-call pattern and the range in the first conversation, and interview slots agreed in advance.

Adjacent backgrounds worth considering

If the field is thin, widen the backgrounds you consider rather than lowering the bar on the essentials:

• Backend software engineers who have owned their own deployment and infrastructure, and want to do more of it.
• Systems administrators and infrastructure engineers who have moved their work into code and automation.
• Network or security engineers with strong automation experience, for roles where those areas carry weight.
• Engineers from build and release or test automation roles, for pipeline-heavy work.

Each of these brings part of the role and needs support with the rest. Say in the brief which gaps you are happy to train, so these candidates know they are welcome.

Permanent, contract or leadership search

Contract engineers suit work with an end: a migration, a new environment, a cost or security review, or cover while you recruit. A permanent hire suits ongoing ownership of the platform, the on-call rota and the knowledge that builds up around them. Many teams use both, one after the other. Our contract or permanent guide sets out the test we use, and the contract recruitment and permanent recruitment pages explain how each works with us.

For a head of platform, head of infrastructure or a similar leadership role, the search is different: fewer people, more confidentiality and more weight on how they have built and led teams. That is usually a retained leadership search rather than an advertised role.

What a strong brief contains

• The problem and the six-month outcome, in a sentence each.
• What the person will own, and what they will not.
• The current estate: cloud provider, main tools and how mature they are.
• The short essential list and the separate list of things you will train.
• The on-call pattern and how it is recognised.
• The team they join, who they report to and who they support.
• Location, working pattern and the salary range.
• The interview stages and who runs each one.

Our hiring brief builder walks through these points and shows where a brief is likely to narrow the field.

When specialist recruitment support is useful

You probably do not need outside help if your adverts already bring you strong, relevant applicants and your own team can run the process quickly. Specialist support is more useful when the role needs someone who is not looking, when the profile is unusual, when you have several of these roles at once, or when the brief itself needs testing against the market before you commit to it.

Humand recruits DevOps, platform and cloud engineers for technology employers across Oxfordshire and the UK, with permanent, contract and leadership search run as separate services. Our DevOps recruitment page sets out the roles we cover, and the software engineering page covers the teams these engineers support.