An AI assistant can now draft a Terraform module, a GitHub Actions workflow and a Helm chart before the kettle boils. What it cannot do is tell you that the plan it produced will destroy a production database, or that the third-party action it picked runs with your cloud credentials. That shift defines the DevOps engineer skills worth paying for: writing configuration has become cheap, while judging its blast radius has become the real work. Managed Kubernetes has also taken cluster care away from many teams, and attacks on build systems have turned the pipeline itself into something that needs defending.
What follows sets out eight technical skills with a fresh check for each, the working habits that distinguish strong engineers, what is rising and fading in importance, a matrix by level and a way of assessing all of it.
Core technical skills for a DevOps engineer
Pipeline design and feedback speed
A good pipeline gives developers a trustworthy answer quickly. Strong engineers treat flaky tests as defects, split slow suites so they run in parallel, cache dependencies with keys that invalidate correctly, and know when a merge queue will stop two green branches from breaking the main branch together. How to check it: share the stage timings from a real CI run, with one test job retried several times, and ask where they would spend their first afternoon. Look for measuring before changing.
Infrastructure as code with a sense of blast radius
Terraform and its open source fork OpenTofu are simple to start with and hard to run well across a company. Skilled engineers keep state files small enough that one bad apply cannot touch everything, version their modules, and use moved blocks when refactoring so that a rename does not become a rebuild. How to check it: show a plan output in which a harmless-looking change forces replacement of a managed database. Ask what they would do next. You want someone who stops, finds the attribute responsible and looks for a safe route, and who mentions lifecycle protection for stateful resources.
Container image craft
Docker knowledge goes well beyond writing a file that builds. Good engineers use multi-stage builds, order layers so that caching works, keep runtime images minimal and understand what they lose by doing so. How to check it: describe a Go service moved to a scratch image, whose outbound HTTPS calls now fail with certificate errors. Ask why. The answer is that the image no longer carries a CA bundle, and an engineer who has minimised images in practice will usually get there fast.
Kubernetes workload behaviour
For most DevOps roles the useful depth lies in how workloads behave during change, as opposed to how the control plane works. That means requests and limits, readiness probes, graceful termination, disruption budgets and the move from Ingress towards Gateway API. How to check it: say that requests fail for a moment whenever the cluster upgrades its nodes, even though no pod is crashing. Good candidates ask about replica counts, PodDisruptionBudgets and whether the application handles SIGTERM and drains connections before exiting.
GitOps and progressive delivery
Argo CD and Flux make Git the record of what should be running, and Argo Rollouts or Flagger can move traffic in steps while watching metrics. The skill is deciding what happens when reality and Git disagree, and which signals should halt a rollout automatically. How to check it: ask what happens if someone edits a deployment with kubectl during an incident, in an Argo CD application with self-heal switched on, and again with it off. The first reverts the edit and the second only reports drift, so a capable engineer will explain how they would pause automation during an emergency.
Build system security
The pipeline holds the keys to production, so it attracts attackers. Strong engineers replace stored cloud keys with OIDC federation, pin third-party actions, restrict workflow permissions, generate an SBOM and sign images with a tool such as Cosign. How to check it: show a workflow that references a community action by a version tag and has broad write permissions. Ask what could go wrong. Tags can be moved, so listen for pinning to a full commit hash and for narrowing what the token may do.
Configuration management and idempotence
Ansible still earns its place on legacy hosts and network gear. The mark of skill is idempotence: a second run changes nothing. How to check it: hand over a playbook that reports changes on every run because it leans on shell tasks. Ask them to explain why, and to rewrite one task with a proper module or a creates condition.
Linux, networking and scripting foundations
Almost every odd pipeline failure ends up at DNS, TLS, file permissions or a process signal. How to check it: ask them to explain how a Bash script can fail halfway through and still let a pipeline step pass. Then ask what set -e and pipefail change, and where each one falls short.
Working skills that separate good from average
- Making developers self-sufficient. An average engineer takes the ticket and fixes the deployment. A strong one leaves behind a template, so the same ticket never returns.
- Negotiating with security. Scanners produce far more findings than anyone can fix. Good engineers agree which ones block a release, which ones raise a ticket, and who owns the exceptions, so gates stay on and developers do not route around them.
- Finishing migrations. Half-moved estates are worse than either end state, since two systems now need upkeep. Look for people who switched off the old system and can say how they got the last stubborn team across.
- Knowing how the product makes money. Release windows and rollout speed should depend on what the business can tolerate.
DevOps skills that matter more in 2026, and less
Mattering more. Reviewing generated infrastructure code is now daily work, and it asks for more experience than writing it did, because plausible configuration hides its mistakes well. Supply chain controls have moved from specialist concern to routine duty after a run of attacks on build tools and package registries. Platform thinking has grown too: many teams now want paved roads with golden-path templates instead of bespoke pipelines per service. Cloud cost also lands on this role, since a careless autoscaling setting or an unbounded CI runner fleet shows up directly on the bill. The retirement of the community Ingress NGINX controller has also pushed many teams to learn Gateway API.
Mattering less. Running your own Kubernetes control plane is a niche need now that EKS, AKS and GKE handle it. Hand-maintained Jenkins freestyle jobs are migration knowledge, although Jenkins itself remains common. Recalling YAML fields from memory has little value when an assistant supplies them, so interview time is better spent on what happens when that YAML is wrong.
DevOps engineer skills matrix by level
| Skill area | Junior | Mid-level | Senior |
|---|---|---|---|
| CI/CD | Adds steps, fixes failed builds | Designs pipelines, removes flaky stages | Sets shared templates and release policy |
| Infrastructure as code | Edits existing modules safely | Writes versioned modules, reads plans critically | Decides state layout and team workflow |
| Containers | Builds working images | Minimal, cached, traceable images | Base image standards across teams |
| Kubernetes | Deploys and reads events | Tunes probes, limits and disruption budgets | Sets workload standards, plans upgrades |
| Delivery safety | Follows the rollout runbook | Configures canaries and automatic halts | Chooses risk levels per service |
| Security | Keeps secrets out of code | Federated identity, pinned dependencies | Agrees gates and exceptions with security |
| Scripting | Reads and edits scripts | Writes tested tooling in Bash or Python | Replaces scripts with reusable products |
| Collaboration | Asks early, documents fixes | Coaches a product team | Moves many teams through a migration |
How to assess DevOps skills in a hiring process
The DevOps engineer job description covers the role and first-round questions. Once a candidate clears those, these stages show how they work on something close to your own systems.
- Pair on a pull request. Share a sanitised change to Terraform or a workflow file with two real mistakes in it and one debatable style choice. Watch how they comment.
- Allow an assistant, then ask for the risks. Let them generate a deployment manifest with any tool they like, then ask what they changed and what they would refuse to merge.
- Ask for a migration story with numbers they can defend. Build time before and after, or deployment frequency before and after, is fine. Ask how they measured it, and treat vagueness as a useful signal.
- Test the handover. Ask them to write a short runbook for a task they just completed. If a teammate could not follow it, knowledge will stay in one head, which is the very thing this role exists to prevent.
Red flags on a CV: “DevOps” used for work that was entirely server patching; every CI product ever released, with none tied to an outcome; Kubernetes listed with no mention of what ran on it; “automated everything” with no measure of what changed; and a certification trail that stops short of any production system.
Frequently asked questions
Is Jenkins experience still worth asking for?
Yes, if you run it. Large numbers of enterprises still do, and someone must keep those pipelines alive or move them. For a team already on GitHub Actions, it is a nice extra at best, and pipeline design skill carries across either way.
How much Kubernetes does a team on simpler platforms need?
Possibly very little. If your services run happily on a managed container service or serverless functions, ask for depth there. Hiring a Kubernetes specialist before you need one often leads to a cluster you did not need.
Should a DevOps engineer be strong on more than one cloud?
Depth on your primary provider matters far more. Concepts such as identity, networking and managed compute transfer reasonably well, so a capable engineer can pick up a second cloud on the job. Treat claims of equal expertise in all three with some care.
Can a systems administrator grow into this role?
Often, and they arrive with useful Linux and networking instincts. The gaps tend to be version control habits, treating infrastructure as reviewed code and writing software that others maintain. A contract-to-hire arrangement can be a sensible way to test that move.
Zilo AI screens on the real pipelines, Terraform, clusters and incidents candidates have handled, and can help you hire DevOps engineers in India on contract, contract-to-hire or permanent terms, or as part of a dedicated team through our IT hiring service. Tell us what is slowing your releases and we can start from there.