DevOps Engineer

Four jobs wearing one title

DevOps Engineer, Site Reliability Engineer, Platform Engineer, Infrastructure Engineer, Cloud Engineer. Companies use these interchangeably, and the same title covers work that has little in common.

At one company you are building the internal platform other engineers deploy on, which is a software engineering job. At another you are on-call for production, which is an operations job with a heavy incident load. At a third you are migrating infrastructure to a cloud provider, which is a project with an end date. At a fourth you are maintaining build pipelines, which is closer to developer tooling.

People apply to all of them with one resume and wonder why the response rate is poor. The postings look similar because the tools overlap. The jobs do not.

What the posting tells you about which one it is

Read for the thing they are worried about, which is usually visible in what they list first.

Kubernetes, Terraform and a service mesh near the top, with language about self-service and developer experience, is platform work. You will be judged on whether other engineers can ship without you.

Incident response, error budgets, observability and service level objectives means reliability. You will be judged on uptime and how you handle the worst night of the quarter.

Migration language, a named cloud provider, and cost optimisation means an infrastructure project. Ask what happens after it lands, because plenty of these roles have no clear second act.

Jenkins, build times and release process is developer tooling. Real work, often undervalued, and worth confirming whether the company sees it that way.

Ask about the on-call rota in the first conversation. It tells you the truth about the job faster than any part of the posting.

Your resume should read like a system, not a toolbox

The standard resume for this role is a long list of technologies followed by bullets that mention them again. Every applicant has that list, and after the first few the reader stops seeing it.

What separates candidates is describing an environment. How many services, what scale, what the deployment frequency was, who was on-call, what the failure modes were.

"Ran the platform for 40 services on Kubernetes across three regions, with about 200 deploys a week and a five-person on-call rota."

An experienced reviewer learns more from that sentence than from twenty tool names, because it tells them what problems you have actually met. A candidate from a three-service environment and one from a three-hundred-service environment have different instincts, and neither is fixed by knowing the same tools.

The incident story is the interview

Somewhere in the loop you will be asked about an outage. It is the most reliable signal in this discipline, and it is worth preparing properly.

Interviewers are listening for a specific sequence: how you found out, what you did to stop the bleeding, how you found the cause, and what changed afterwards so it could not happen the same way twice.

The two answers that go badly are the one where the candidate is the hero who fixed everything alone, and the one where the cause was somebody else's mistake. Both suggest a person who has not internalised that reliability is a property of a system rather than of individuals.

Include a mistake of your own if you have one. An engineer who has taken down production, understood why, and built the guardrail is more trusted than one who claims never to have broken anything, because the second is either inexperienced or not being straight.

Automation you can point at

The word automation appears on every resume in this field and means nothing on its own.

Make it concrete by naming what was manual, what it cost, and what it looks like now. Provisioning that took three days and a ticket now takes fifteen minutes in a pipeline. A release process that needed two people on a call at midnight now runs on merge.

Toil reduction is the whole discipline, so quantifying it is the closest thing to a universal currency here. Time saved per week, incidents avoided, or steps removed from a runbook are all more persuasive than the tool you used to do it.

Coming in from system administration or support

A large share of people in this discipline arrived from sysadmin, network operations, or a technical support role, and the transition has a predictable shape.

What transfers is the part nobody can teach quickly: knowing how systems actually fail, having been woken up by them, and having the instinct to check the boring cause first. Engineers who came into infrastructure from a software background often lack this and take years to acquire it.

What is missing is usually treating infrastructure as software. Version control for everything, code review on changes, testing, and a pipeline rather than a person applying changes by hand.

The gap is closeable and the evidence is easy to produce. Take something you currently do manually at work, put it in a repository as code, and run it through a pipeline. One real example is enough, because it demonstrates the shift in approach rather than familiarity with a tool.

On the resume, describe your operations background in engineering terms. "Maintained 200 servers" is a sysadmin line. "Managed a 200-host fleet, moved patching from a manual runbook to a scheduled pipeline, cut the patch window from two days to four hours" is the same work described by someone who has made the transition.

Tooling ages, and the interview knows it

The specific tools in this field turn over faster than in most engineering work. Configuration management gave way to containers, containers to orchestration, orchestration to a layer of abstractions on top of orchestration.

That has two consequences for how you present yourself.

Recency matters. Deep experience in a tool that has fallen out of use counts for less than current experience with what teams run now, and interviewers will probe for whether your knowledge is live or remembered.

The transferable part is the reasoning, not the syntax. Whichever tools you have used, you have made decisions about state management, rollback, secrets, and the boundary between what developers control and what you control. Talk about those decisions and your experience travels across tool changes. Talk only about the tools and it expires with them.

The security overlap nobody assigns

At most companies, a large share of practical security lands on this role by default. Secrets handling, network boundaries, access control, patching, supply chain of the base images.

This is rarely in the job description and almost always in the job. It is also the fastest way to become difficult to replace, because it sits between two teams and neither owns it entirely.

If you have done this work, put it on the resume explicitly rather than leaving it implied. If you want to move toward platform or reliability roles at larger companies, it is worth deliberately acquiring, because at that size the expectation is assumed rather than stated.

On-call and pay travel together

We do not print salary figures, because a number from Amsterdam means nothing in Toronto, Bangalore or Nairobi.

What holds across markets is that compensation in this discipline tracks the production responsibility you carry. An engineer who is on-call for revenue-critical systems is paid differently from one who maintains build pipelines during business hours, at the same title and years of experience. That is the largest structural factor and it is rarely stated openly.

After that: the scale of what you run, whether you build tooling other engineers depend on rather than operating what exists, and moving from a local company to a multinational in the same city.

Before accepting anything, ask how often the rota comes round, whether on-call is compensated separately, and how many pages a typical week produces. Those answers change the value of an offer more than a difference in base.

For what the role pays where you live, our salary calculator takes your city and your years of experience.

What to fix first

Take the top of your resume and replace the tool list with two sentences describing the environment you ran. Scale, services, deploy frequency, on-call. Anyone senior reading it will know immediately whether to keep going, which is the whole job of the first ten lines.

Our job search builder searches every board you trust at once, and the ATS scanner shows what a filter reads first.