DevOps Engineer Job Description Template (2026)

Why Generic Skill Lists Backfire

A DevOps engineer job description that lists “CI/CD, Kubernetes, Terraform, AWS, Azure, GCP, Docker, Ansible, Helm, and 3+ years of experience” attracts exactly the wrong candidates. Engineers who match all of those requirements equally are rarely strong practitioners on any single tool. Engineers who have deep expertise in your actual stack, however, will disqualify themselves when they see a JD that looks nothing like the job.

This template corrects that problem. It gives you a ready-to-customize structure built around three decisions that determine whether your DevOps JD works:

• Which CI/CD system your team actually uses
• What container orchestration platform owns your production workloads
• What the engineer will inherit versus build from scratch

Use it directly, or adapt it section by section for your environment.

What DevOps Engineers Actually Own

Before writing a single requirement, clarify what your DevOps engineer will actually own at your company. The scope varies dramatically by organization size and engineering maturity. As a result, a JD that does not reflect the real job creates mismatches that surface within the first 60 days of a placement.

At most companies, a DevOps engineer owns some combination of the following:

• Designing and maintaining CI/CD pipelines
• Managing container orchestration on Kubernetes (EKS, AKS, or GKE)
• Writing infrastructure as code with Terraform or Ansible
• Configuring and operating the observability stack (Prometheus, Grafana, Datadog, PagerDuty)
• Managing secrets and access controls
• Owning on-call rotation for infrastructure-layer incidents

Some organizations also expect DevOps engineers to handle cloud cost optimization and Reserved Instance coverage.

At larger engineering organizations with dedicated SRE or platform engineering teams, the DevOps engineer’s scope narrows to pipeline ownership and developer tooling. In that model, SRE owns incident response and platform engineering owns cluster operations. At smaller companies, by contrast, one DevOps engineer often owns the full stack from the Dockerfile to the production alert. State which model applies clearly, because candidates with SRE experience will evaluate your JD differently from candidates with startup DevOps experience, and both are valuable in the right context.

Core Technical Requirements

Requirements should reflect what is actually needed to be productive in your environment on day 60, not a wish list assembled from the last three job postings you reviewed. Separate hard requirements from preferences, and list no more than 6-8 hard requirements. For each one, describe the depth you actually need rather than just naming the tool.

CI/CD Toolchain

Name the specific CI/CD system your team runs and the depth of ownership required. For example, “2+ years building and maintaining GitHub Actions workflows for production deployments across 5+ microservices” is a real requirement, while “experience with CI/CD pipelines” only describes a category. When your team runs Jenkins, say Jenkins, and specify whether the engineer will own the Jenkins server itself or only write pipeline definitions in Groovy. For GitLab CI shops, specify whether it is self-hosted or SaaS and whether the engineer will manage GitLab runners. If you use CircleCI instead, note the orb ecosystem complexity you need them to navigate.

Container Orchestration

Kubernetes experience varies enormously in depth. Distinguish between an engineer who has written Helm charts and applied them with kubectl, and one who has managed a full EKS or AKS cluster. That deeper profile covers node group configuration, cluster autoscaler tuning, network policy enforcement, and persistent volume management. If your clusters run workloads with specific requirements (GPU nodes for ML inference, spot instance node pools, multi-tenant namespace isolation), list those requirements explicitly so candidates can self-select accurately.

Infrastructure as Code Depth

Terraform experience is not homogeneous. An engineer who has written Terraform by running terraform apply from a local directory is very different from one who has designed and maintained a modular Terraform codebase. That more advanced profile typically includes remote state in S3, state locking via DynamoDB, environment-specific workspaces, and a CI/CD-integrated plan-and-apply workflow. Describe the complexity level you need, and state whether the engineer will inherit existing modules or greenfield the IaC codebase. If your team uses Ansible for configuration management alongside Terraform for provisioning, include both explicitly.

Observability and Monitoring

Specify which observability tools your team uses and what the engineer will own. If you run Prometheus and Grafana self-hosted on Kubernetes, the engineer needs operational knowledge of the Prometheus operator, alertmanager configuration, and Grafana dashboard management. Datadog shops should instead call out integration and APM configuration experience, since that skill set looks different. When PagerDuty handles on-call routing, note whether the DevOps engineer will be in the rotation and own escalation policies.

Nice-to-Have Skills

Separate preferences from requirements and keep the list to three to five items. Otherwise, a preference list longer than five reads as additional requirements and filters out strong candidates who do not tick every box.

Common genuine preferences for DevOps engineering roles include:

• Experience with GitOps tooling (ArgoCD, Flux)
• Prior work with service mesh architectures (Istio, Linkerd)
• Container image scanning and supply chain security (Trivy, Snyk, Cosign)
• Cost optimization experience with a FinOps framework
• A relevant professional certification, such as the Certified Kubernetes Administrator (CKA), AWS DevOps Engineer Professional, Azure DevOps Engineer Expert, or HashiCorp Terraform Associate

Certifications belong in the preferred section, not the requirements list, unless a regulatory context makes a specific certification a contractual deliverable. In that case, name the certification and the required completion timeline in the JD. Otherwise, listing a CKA as required will filter out engineers with strong Kubernetes production depth who simply have not sat the exam yet.

The Full JD Template

The template below is built for a senior DevOps engineer role targeting a nearshore or remote hire. Customize the bracketed fields for your environment. Remove sections that do not apply rather than leaving them blank or generic.

Compensation Ranges

Publishing a salary range in your DevOps engineer JD increases qualified application volume by reducing time wasted on candidates with misaligned expectations. For nearshore DevOps engineers hired through a staffing partner in Costa Rica, the ranges below reflect 2026 all-in placement costs through Kore BPO. Full salary data by experience level is available in the Nearshore DevOps Engineer Salary Guide.

These ranges cover salary, benefits administration, and account management support. There are no upfront search fees. All-in costs remain 40 to 60% below the equivalent US-based senior DevOps engineer role, where total compensation for the same experience level typically runs $130,000 to $175,000 annually.

Remote-Ready JD Considerations

A JD written for a nearshore or remote DevOps engineer requires several additions that are not standard in domestic postings. These additions signal to strong candidates that your team has built distributed infrastructure engineering roles before and that the role is genuinely remote-first, not a hybrid role with an optional WFH day.

State the Timezone Requirement Precisely

“Full availability during US Central hours (9 am to 5 pm CT, UTC-6)” is unambiguous. “US timezone overlap” is not. Costa Rica operates UTC-6 year-round without daylight saving time. As a result, there is no seasonal shift and no ambiguity about whether Central Time is 5 or 6 hours behind depending on the month. Engineers hired through Kore BPO in Costa Rica have full overlap with US Central and near-full overlap with US Eastern.

Clarify the On-Call and Onboarding Model

Describe your incident response model for a distributed team. If your DevOps engineer will be in the primary on-call rotation, specify the expected on-call frequency and how incidents outside business hours are compensated. If the engineer will be secondary on-call or excluded from overnight rotations, state that clearly instead. Ambiguity around on-call is one of the leading causes of early attrition in DevOps placements, regardless of geography.

State the onboarding structure explicitly, too. “First two weeks are read-only access to all systems; no production access or deployment permissions until day 15” signals that your team understands the cost of rushing a DevOps engineer into critical infrastructure without adequate context. It also attracts candidates who do careful work rather than fast work, which is the correct tradeoff for someone who can take down a production cluster.

Common JD Mistakes

Listing Every CI/CD System as an Equivalent Requirement

Requiring experience with GitHub Actions, GitLab CI, Jenkins, and CircleCI simultaneously signals that you have not thought clearly about what your team actually uses. Engineers who claim deep expertise in all four are rarely credible at the senior level. Instead, pick the system your team runs, require depth there, and note the others as preferred experience.

Conflating DevOps, SRE, and Platform Engineering

These are distinct roles with different ownership models and different seniority profiles. A DevOps engineer who has spent their career on CI/CD pipelines and build tooling will struggle in an SRE role that requires probabilistic error budget reasoning and service level objective design. Because of that gap, if your role requires genuine SRE practices (SLOs, error budgets, toil elimination), say so explicitly in the title and requirements.

Using Kubernetes Requirements That Ignore Cluster Complexity

“Experience with Kubernetes” is not a requirement. Specify whether the engineer will manage cluster infrastructure, write application Kubernetes manifests, or both. Note the cluster scale, including the number of nodes, the number of workloads, and whether the cluster is multi-tenant, since this determines whether a candidate’s prior experience maps to your environment.

Omitting the Infrastructure State Honestly

A DevOps engineer inheriting a Jenkins server with 200 hand-crafted pipeline scripts operates in a very different environment from one greenfielding a GitHub Actions workflow library. Both roles are legitimate. However, the one that is described honestly attracts candidates who understand the challenge and have experience with it, while the one described generically attracts candidates who assume greenfield and disengage on day three.

Frequently Asked Questions