Hire DevOps Engineers: Rates, Red Flags and Engagement Models

The Kubernetes trap, and what the job really is

Here is a scene from a real handover. A Series A company had shipped for two years on a single EC2 box with a deploy script called deploy_final_v2.sh. They hired a DevOps engineer who arrived, looked at it, and spent four months migrating everything to Kubernetes on EKS with Helm charts, Istio, ArgoCD and a service mesh. It worked. Then he left. Nobody else on the team could read a Helm values file. The first time a pod started CrashLoopBackOff at 2am, three engineers spent six hours on a Zoom call reading kubectl docs. They ended up paying a contractor to rip Istio out.

That is the central failure mode of this role. DevOps engineers are drawn to infrastructure that is interesting, and the interesting thing is almost never the correct thing for a fifteen person company. The job is to make deploys boring, make failures visible before customers notice, and make sure whoever is still around in two years can operate what got built. Sophistication is not the goal and usually works against all three.

The actual work, on a real project, looks like this. Writing the Terraform or Pulumi that defines your VPC, RDS instance, load balancers and IAM roles, with remote state in S3 and DynamoDB locking so two engineers do not corrupt it. Building the GitHub Actions or GitLab CI pipeline that runs tests, builds a Docker image, pushes to ECR and rolls it out with a health check and an automatic rollback. Setting up Prometheus and Grafana, or Datadog, with alerts that fire on symptoms your users feel, latency and error rate, rather than on CPU sitting at 80 percent, which nobody should be woken up for. Managing secrets in AWS Secrets Manager or Vault so that credentials are not sitting in a .env file in a Slack thread. Writing the runbook that says exactly what to do when the queue backs up.

Where hiring goes wrong is the resume filter. Certifications and a list of tools tell you almost nothing. The person who lists Kubernetes, Terraform, Ansible, Jenkins, Docker, Prometheus, ELK, Istio and Kafka has probably touched all of them and owned none of them. The signal you want is different: has this person been on call for something they built, and did they change what they built because of what happened at 3am?

Which engagement model fits

An in-house hire makes sense when infrastructure is genuinely part of your product surface. If you are a data platform, if you sell an SLA, if you have compliance auditors asking about access control, you need someone who owns this every day and carries a pager. The catch is retention. A DevOps engineer at a company with six services and a stable deploy cadence runs out of work within a year. They then either invent complexity to stay interested, which is the Istio story above, or they leave for somewhere with harder problems. You are hiring for a permanent stream of infrastructure work. Confirm that stream exists before you commit.

A freelancer works well for a bounded build. Migrate from Heroku to AWS. Get SOC 2 evidence collection automated. Set up the CI pipeline. The trade-off is that infrastructure is the code you understand least and depend on most, and a freelancer who disappears after delivery leaves you owning Terraform you cannot read. If you go this route, make the handover a deliverable with the same weight as the infrastructure itself: architecture diagram, runbooks, and a session where your team destroys and rebuilds a staging environment from the Terraform, unaided, while the freelancer watches.

An agency fits when you want the infrastructure decided as well as built. A good agency has seen forty deployments and will tell you that you do not need Kubernetes, which is advice a freelancer paid by the hour is less motivated to give. You also get continuity, so the person who set up your alerting is reachable in six months. You pay more per hour, and you get less of the deep company context an employee accumulates.

Staff augmentation is the middle ground and, honestly, what most companies at this stage should use. You get an engineer embedded in your standups and your Slack, working your backlog, without a full-time salary commitment or a hiring cycle. It fits the reality of DevOps work: bursty. Heavy for a quarter while you build the platform, then quiet. Ten hours a month of maintenance and upgrades is a bad job description and a great engagement.

Rates and what this actually costs

These ranges come from Digital Heroes delivery and from what we see when clients tell us what they were quoted elsewhere. They move with region and seniority more than with anything else.

Offshore, primarily India and Southeast Asia, mid-level DevOps sits around $35 to $60 per hour. Eastern Europe and Latin America run roughly $50 to $95. The US, UK, Canada and Western Europe run roughly $90 to $180 per hour for contract work, with genuinely senior platform engineers, the ones who have run infrastructure at meaningful scale and have opinions about why, above that. Agencies price above individual contractors because the rate carries account management, backup coverage and the architectural judgment.

The number founders miss is the true cost of the in-house hire. Base salary is not the cost. Employer taxes, health insurance, equipment, software licenses and general overhead push the loaded cost meaningfully above base, and in our own budgeting we plan on roughly 1.25x to 1.4x of base. Then add recruiting, which is either an agency fee at a percentage of first-year salary or roughly six weeks of your engineering leader's attention. Then add ramp: a DevOps engineer is not useful until they understand your architecture, and that is usually two to three months, not two weeks, because the knowledge is tacit and lives in whoever handled the last outage.

Run it end to end and a mid-level in-house DevOps hire in the US frequently costs more in year one than a fully loaded staff-augmented senior engineer at 25 hours a week. That is not an argument against hiring. It is an argument for being honest about the comparison instead of comparing a salary number to an hourly rate.

One thing worth pricing separately: cloud spend. A competent DevOps engineer usually finds enough waste in an unmanaged AWS or GCP account, oversized instances, orphaned EBS volumes, NAT gateway traffic nobody understands, missing savings plans, to offset a real chunk of their own cost in the first quarter. Ask candidates about this directly. The ones who have done it have specific stories.

How to vet a DevOps engineer

Skip the trivia. Nobody needs to recite the difference between a Deployment and a StatefulSet in an interview. Here is what actually separates people.

Ask about a real outage they caused. Not one they responded to, one they caused. Good engineers answer instantly and in detail, because they wrote the postmortem. Listen for whether the fix was a process change or a system change. Someone who says "we added a checklist step" has learned less than someone who says "we made the deploy fail closed if the migration had not run."

Terraform state. Ask what happens when two engineers run terraform apply at the same time, and what they do when state drifts from reality because someone made a change in the console. The answers you want mention remote state with locking, terraform import, and preferably a rule that manual console changes are banned outside of an incident. Push further: ask what they do about a resource that was deleted out of band and now blocks every plan, and whether they have ever run terraform state rm. Someone who has never had a state file get mangled has not managed real Terraform.

Pipeline design. Walk them through your current deploy and ask what they would change first. The good answer is almost always something small and unglamorous: add a rollback path, add a smoke test after deploy, cache the dependency install so the pipeline stops taking eleven minutes. The bad answer is a rearchitecture. Ask specifically how they handle database migrations in a deploy, because that is where CI/CD design either holds up or falls apart. Listen for expand-and-contract, backwards-compatible migrations, and the understanding that a migration and a code deploy should not be atomic. Then ask how a secret gets into the pipeline: OIDC to a cloud role is the answer you want, a long-lived key stored in repository secrets is the one that tells you where they stopped.

Alerting philosophy. Ask what they page on. If the answer includes CPU or memory or disk in isolation, they will give your team alert fatigue within a month. You want symptom-based alerting: error rate, latency at p99, queue depth growing without bound, a synthetic check on the actual user path. Ask what they do when an alert fires and nothing was wrong. The right answer is delete or fix the alert, not ignore it. Ask about Prometheus cardinality if they name it, because anyone who has run it in anger has watched a label with a user ID in it eat the memory on the box.

Kubernetes, only if relevant. If you genuinely run Kubernetes, ask them to explain what happens between a pod being marked Ready and it actually serving traffic correctly, and ask about resource requests versus limits. The specific thing to listen for is whether they understand that setting a CPU limit can throttle you in ways that look like a mysterious latency problem. That detail separates people who ran clusters from people who read about them. If you do not run Kubernetes, ask instead whether you should, and hire the person who says probably not.

The take-home. A good one is small and real. Give them a Dockerfile and a bare app, and ask for Terraform that stands it up on ECS Fargate or Cloud Run behind a load balancer with HTTPS, plus a GitHub Actions workflow that deploys it. Cap it at four hours and pay for their time. What you grade is not whether it works. It is whether the IAM role is scoped or is an admin policy, whether secrets are handled or hardcoded, whether the state backend is remote, whether there is a README you could follow. Then ask them to walk you through the one thing they would have done differently with another day. That conversation tells you more than the code.

If you review a portfolio instead, ask for the postmortem, the runbook or the architecture decision record, not the repo. DevOps quality lives in writing.

Red flags

Kubernetes as the answer before hearing the question. If a candidate proposes EKS for your three-service app that gets 400 requests a minute, they are optimizing their resume. Better question: "What is the simplest thing that would handle our load with room to grow, and at what point would that stop working?" The engineers worth hiring name a threshold.

No opinion on cost. Ask what your cloud bill should be and how they would find out. Someone who has never opened Cost Explorer or looked at a per-service cost breakdown will happily leave three idle RDS replicas running for a year. This is the cheapest question in the interview and it disqualifies a surprising number of people.

Everything is manual and undocumented. If their description of past work involves SSHing into boxes, running scripts by hand, and knowledge that lives in their head, they will make themselves indispensable in the worst way. Better question: "If you were unreachable for two weeks, what breaks and who fixes it?" The good answer is a runbook link.

Secrets casualness. Ask directly how they have handled credentials. If the answer involves committing .env files, sharing keys over Slack, or a long-lived AWS access key on a laptop, that is not a training gap, it is a habit. Ask what they would do with an IAM key that leaked to a public repo, and listen for whether rotate, revoke and audit CloudTrail come out in that order and fast.

Tool list with no failure stories. Someone who has run Prometheus in production has a complaint about it, usually about cardinality blowing up memory. Someone who has run Jenkins has a story about a plugin upgrade breaking everything. Absence of complaints means absence of production. Better question: "What is the tool on your resume you like least, and why is it still on there?"

When to hire this role at all, and how Digital Heroes staffs it

Be honest about whether you have a DevOps problem or a backend problem. If deploys are painful because your app is a monolith with a twelve-minute test suite and no migration strategy, a DevOps engineer will build you a beautiful pipeline around a slow build and the pain will remain. That is work for a backend engineer with good instincts. If your infrastructure is fine but you cannot tell what is happening in production, you may want an SRE mindset rather than a builder, someone focused on observability and reliability rather than provisioning. And if you are pre-launch with one service, a competent full-stack engineer on a managed platform will get you further than a DevOps hire, because your bottleneck is the product, not the infrastructure.

The moment to actually hire is when three things are true together: infrastructure changes more than once a week, somebody is getting paged and it is always the same person, and a decision about your architecture is now expensive to reverse. Before that, you are buying capability you will not use.

At Digital Heroes we staff this as an embedded engineer inside your team rather than an external infrastructure vendor. The engineer works your backlog, joins your standup, and everything they write lives in your repository under your account from the first commit. Code and infrastructure ownership transfers to you, always, and there are no proprietary wrappers you would need us to maintain. Engagements typically start with a two week assessment: we read your current setup, tell you what is actually urgent versus what is merely untidy, and give you a plan you could hand to someone else. Most projects then run heavy for a quarter to build the pipeline, the Terraform and the alerting properly, then step down to a maintenance cadence once your own team can operate it. If the honest answer is that you do not need this yet, we say so, because the alternative is billing you for a platform nobody will use.