Home · About · Services · Industries · Projects · Products · Process · Blog · FAQ · Contact
Hiring a DevOps engineer: skills to look for and questions to ask What to look for when hiring a DevOps engineer in 2026: the skills that matter, interview questions that reveal real experience, a practical exercise and red…
A common story: a founder interviews six DevOps candidates and cannot tell them apart. Every CV lists AWS, Docker, Kubernetes, Terraform and Jenkins. Every candidate says they have built CI/CD pipelines. The problem is rarely the candidates. The interviews are checking for tool names, and tool names are the easiest thing in the field to copy onto a CV.
Here is the short answer. When hiring a DevOps engineer, look for strong Linux and networking fundamentals, hands-on infrastructure as code, CI/CD you can inspect, and a calm approach to incidents. Ask them to explain past failures in detail, review a real pipeline, and debug a broken service. Judge how they reason, not how many tools they list.
Below is how we would approach the hire, from defining the role to the questions and exercises that separate people who have run production from people who have read about it.
Decide which DevOps engineer you actually need "DevOps engineer" covers several different jobs. Writing a job description that asks for all of them attracts generalists who are thin everywhere, or puts off specialists who would suit you well. Before you post anything, decide which of these is the main need for the next twelve months.
Platform builder: sets up cloud accounts, networking, infrastructure as code and deployment pipelines from close to nothing. Common in startups moving off a single hand-built server. Operator: keeps an existing estate healthy. Patching, monitoring, backups, capacity, cost and on-call. Common once a product has paying users. Pipeline and developer-experience engineer: speeds up builds, tests and releases for a development team. Common when deployments are slow or frightening. Migration lead: moves workloads between providers or tools, such as on-premises to cloud, Jenkins to GitHub Actions, or VMs to containers. Time-bound by nature. Also write down what you run today: which cloud, which databases, how many services, how deployments happen and who gets woken at night. A candidate who can read that description and ask sharp questions about it is already showing you something useful.
Skills that matter in 2026 Tools change every few years. The fundamentals underneath them do not. We weight the first group of skills much more heavily than the second.
Linux: processes, systemd, file permissions, disk and memory pressure, reading logs with journalctl. Most production incidents end at a shell prompt. Networking: DNS, TLS certificates, load balancers, reverse proxies such as NGINX or Traefik, security groups and private networking. A large share of outages are DNS, certificates or a firewall rule. Infrastructure as code: Terraform or OpenTofu (the open-source fork created after Terraform's 2023 licence change), plus an understanding of state, plans and drift. Containers: writing small, non-root images, multi-stage builds, health checks, and knowing when Docker Compose is enough. CI/CD: GitHub Actions, GitLab CI or similar, with secrets handled properly, ideally through OIDC federation to the cloud rather than long-lived access keys. Observability: metrics, logs and traces, with tools such as Prometheus, Grafana, Loki and OpenTelemetry, and alerts that someone would actually act on. Data safety: database backups, restore testing and the difference between a snapshot and point-in-time recovery. Then the tools that depend on your stack: Kubernetes, a specific cloud's managed services, configuration management with Ansible, or a particular secrets manager. If you run Kubernetes, test for it properly. If you do not, a candidate who insists you need it on day one is a warning sign rather than a strength.
One more skill has become important: using AI coding assistants sensibly. Most engineers now draft Terraform, workflows and scripts with one. That is fine. What you want to know is whether they read and test what comes out, especially anything touching IAM policies, firewall rules or deletion.
Interview questions that reveal real experience Good questions are open, tied to a real situation and have follow-ups. Ask for specifics: what was the error, what did you check first, what would you do differently. People who did the work answer with detail without being prompted.
Tell me about the worst outage you were involved in. What was the first sign, what did you check, and what changed afterwards? A site returns 502 errors after a deployment. Walk me through how you find the cause, from the browser to the container. How do you get secrets into a CI pipeline and into a running application? Where do they live, and who can read them? Your Terraform plan wants to destroy and recreate a production database. What do you do? How would you know a nightly backup had silently stopped working last month? What is the most expensive cloud mistake you have seen, and how would you have caught it earlier? Describe a deployment pipeline you built. How long did it take, how did rollback work, and what did developers complain about? When would you not use Kubernetes? Listen for a few things in the answers. Strong candidates check the simple causes first: DNS, disk space, a certificate, the last change. They talk about blast radius and rollback before speed. They mention telling people what is happening during an incident. And they say "I don't know, but here is how I would find out" without embarrassment.
Use a practical exercise, not a quiz Trivia questions about command flags test memory. A short, realistic exercise tests judgement. We prefer a paid take-home of two to three hours, or a paired session of about an hour where the candidate shares their screen. Two formats work well.
The first is a review exercise. Give the candidate a short pipeline with deliberate problems and ask what they would change and why. For example:
name: deploy
on:
pull_request_target:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v5
with:
ref: ${{ github.event.pull_request.head.sha }}
- uses: some-org/setup-tool@main
- run: npm install && npm run build
- run: aws s3 sync ./dist s3://prod-site --delete
env:
AWS_ACCESS_KEY_ID: ${{ secrets.AWS_KEY }}
AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET }}A strong candidate will spot most of these: pull_request_target with a checkout of untrusted pull request code, which can expose secrets to anyone who opens a pull request; a third-party action pinned to a branch rather than a commit SHA; no permissions block limiting the GitHub token; npm install instead of npm ci; long-lived AWS keys instead of OIDC with a scoped role; no environment protection or approval before production; and deploying to production from a pull request at all. How they prioritise the list matters as much as finding it.
The second is a debugging exercise. Give them a small virtual machine or container where a service will not start, with two faults planted, for example a wrong port in the NGINX upstream and a full disk. Watch how they move: logs first, systemctl status, curl against localhost, df -h. You learn more in forty minutes of this than in an hour of questions.
Red flags and green flags Red: lists every tool on the market but cannot explain how DNS resolution or a TLS handshake works. Red: proposes a rebuild of your stack before asking what it does today or what it costs. Red: describes past incidents only in terms of who else was at fault. Red: treats backups as done because a job exists, with no mention of restoring. Green: asks about your users, your release frequency and who is on call before recommending anything. Green: writes things down. Runbooks, README files, architecture notes. Green: can explain a technical trade-off to a non-technical founder in two sentences. Employee, contractor or dedicated engineer A single in-house DevOps engineer works well when you have enough steady work and can tolerate one person holding most of the knowledge. The risk is the bus factor: holidays, illness or a resignation leave nobody who understands the pipelines. If you go this way, require that everything lives in code and documentation in your own accounts from the first week.
A freelancer suits a defined project, such as a migration or a pipeline rebuild, with a clear end. A dedicated engineer from a team suits ongoing work where you want continuity and cover without building a department. Whichever route you take, the interview questions above still apply, and you should still meet the actual person who will have access to production.
Access deserves a decision before day one. Use individual accounts with multi-factor authentication, roles scoped to what the job needs, and break-glass production access that is logged. Make sure you, not the engineer, own the cloud accounts, domain registrar, repositories and secrets manager.
A hiring checklist Write down which kind of DevOps role you need and what you run today. Screen for Linux, networking and infrastructure as code before specific tools. Ask about real incidents and follow up on the details. Run one practical exercise: a pipeline review or a debugging task. Check how they handle secrets, backups and rollback. Decide access rules and account ownership before the first day. Agree the first 30 days: document the current estate, fix the riskiest gap, set up alerting that works. If you cannot judge the technical answers yourself, ask an engineer you trust to sit in on the practical exercise. One hour of an experienced reviewer's time is cheap next to six months with the wrong hire.
Infigini IT Services · 11 Kanwali Road, Dehradun 248001, India · info@infigini.com · +91 95684 87789