Screening DevOps Engineers: A Non-Technical Recruiter's Playbook
Non-technical recruiter playbook for DevOps screens: DevOps vs SRE, core concepts, and questions that prove production ownership.
DevOps hiring is expensive when it goes wrong. Kubernetes, Terraform, and CI/CD expertise command senior rates — and non-technical recruiters are often asked to screen people for roles they cannot personally practice.
This playbook gives you plain-language concepts, DevOps vs SRE clarity, and call questions that produce evidence without requiring you to administer a cluster. It is built for agency and in-house recruiters who need a credible first gate before a specialist round.
“You are not testing whether you could pass a CKA. You are testing whether the candidate has operated real systems under change and failure.”
DevOps vs SRE vs “knows Docker”
Job posts blur titles. Your screen should not. Align with the hiring manager on which job you are actually filling.
| Label | Usually means | What to verify on a call |
|---|---|---|
| DevOps engineer | Build & run delivery platforms: CI/CD, infra as code, environments, developer enablement | Pipelines, Terraform/CloudFormation, env promotion, incident participation |
| SRE | Reliability engineering: SLIs/SLOs, error budgets, toil reduction, deep incident response | SLO design, on-call practice, automation of toil, postmortems |
| Platform engineer | Internal products for developers (paved roads) | Self-service, golden paths, API/DX thinking |
| “Knows Docker” | Can run containers locally — not the same as production operations | Do not equate with Kubernetes production ownership |
If the manager says DevOps but describes pager duty and error budgets, you are screening SRE. Rename the scorecard before the call.
Concepts you can explain in one sentence
- CI/CD: automatic build/test/deploy path from commit to environment
- Infrastructure as code (Terraform etc.): infra changes reviewed like software, not clicked in a console
- Containers: package app + deps; orchestration (Kubernetes) runs many containers reliably
- Observability: logs, metrics, traces so you can ask “what is broken?” with data
- IAM / least privilege: who can change what in cloud accounts
- Rollback / blast radius: how bad a bad deploy can get, and how you undo it
Before the call: intake questions for the hiring manager
- Cloud: AWS / GCP / Azure — which is must-have?
- Kubernetes: required in production, nice-to-have, or not used?
- IaC: Terraform, Pulumi, CloudFormation, Ansible — which?
- On-call: yes/no, primary or secondary, frequency
- Percentage of time: building platform vs firefighting vs ticket ops
- Deal-breaker: e.g. no production incident ownership = no hire
Call structure (30 minutes)
- 0–5: role clarity + their recent production ownership story
- 5–15: CI/CD + infra-as-code deep dive
- 15–25: Kubernetes/cloud OR reliability (match the real job)
- 25–30: incident follow-up + red-flag check + next steps
Question bank with strong vs weak signals
1. Walk me through your last production deploy path.
Strong: commit → checks → artifact → environment promotion → approval gates → verify → rollback option. Weak: “Jenkins builds and we deploy” with no ownership of failure points. Follow-up: “What failed last month in that path?”
2. How do you manage secrets?
Strong: vault/cloud secret manager, rotation, no secrets in git, least privilege. Weak: “env files on the server” or shrugs. Follow-up: “Have you ever rotated a leaked key? What was the process?”
3. Describe a Terraform (or IaC) change you owned end-to-end.
Strong: plan/review, state awareness, blast radius, apply order, rollback. Weak: copy-paste modules with no state or drift story. Follow-up: “What happens if two people apply at once?”
4. How do you decide blue/green, canary, or rolling updates?
Strong: risk vs cost, traffic shifting, metrics for promote/abort. Weak: buzzword salad. Follow-up: “Tell me about a canary you aborted.”
5. Explain a Kubernetes incident you helped resolve.
Strong: symptoms (CrashLoop, OOM, networking), how they debugged, what changed. Weak: “pods were restarting” with no path. Follow-up: “What did you look at first — events, logs, metrics, or manifests?”
6. How do you think about monitoring and alerting quality?
Strong: SLIs, actionable alerts, reducing noise, runbooks. Weak: “we use Prometheus/Datadog” as the whole answer. Follow-up: “Which alert did you delete or rewrite because it was useless?”
7. What’s the difference between your DevOps work and classical sysadmin ticket ops?
Strong: automation, developer self-service, measuring toil. Weak: proud of manual heroics only. Follow-up: “What repetitive work did you eliminate last quarter?”
8. (If SRE-leaning) How have you used error budgets?
Strong: SLO, burn rate, feature freeze vs reliability work tradeoff with stakeholders. Weak: never heard of it while applying to an SRE seat. Follow-up: “Who decided to stop releases when the budget burned?”
Common recruiter confusions — cleaned up
| Confusion | Reality check |
|---|---|
| Docker = Kubernetes | Docker packages; Kubernetes orchestrates at scale |
| Terraform = Ansible | Terraform often provisions cloud resources; Ansible often configures systems — overlap exists, jobs differ |
| DevOps = on-call only | Many DevOps roles are platform/delivery; confirm pager expectations |
| Multi-cloud on CV = expert | Ask which cloud they owned in production last year |
| Certified = senior | Certs help; incident ownership matters more for senior screens |
Red flags specific to DevOps screens
- Lists every cloud tool but cannot narrate one deploy path they owned
- No story about a failed apply, bad rollout, or leaked credential
- Treats production access casually (“we all share the admin role”)
- Confuses monitoring installation with reliability outcomes
- Cannot separate their work from “the platform team did it”
For a broader bluff list, see 12 signs a candidate is bluffing.
Sample scorecard for the ATS
| Must-true | Evidence examples | Advance if… |
|---|---|---|
| Delivery path ownership | CI/CD stages, gates, rollback | Can narrate end-to-end with a failure |
| IaC judgment | Plan/apply, state, blast radius | Owns a real change, not only modules |
| Runtime operations | K8s/cloud incident or deploy risk | Debugging path is concrete |
| Security hygiene | Secrets, IAM, least privilege | Treats access as serious |
| Reliability mindset (if SRE) | SLO/error budget/toil story | Matches SRE job description |
What “good enough for specialist round” looks like
You are not certifying a principal SRE in thirty minutes. Advance when the candidate can tell one true production story with personal decisions, survive one constraint-change follow-up, and match the actual job (platform vs reliability vs ticket ops). Hold or reject when the CV is a tool museum and the call is a brochure.
Niche note: DevOps recruiting stays commercially hot because the skill mix is scarce and mis-titled. Recruiters who can separate Docker familiarity from production ownership become trusted partners to hiring managers — the same pattern skilled agency teams already sell when they specialize in infrastructure hiring.
Related reading
- How to screen a senior Python developer without coding
- The first 10 minutes screening framework
- How to run a technical pre-screen as a non-technical recruiter
- Red flags in technical interviews
When you need live follow-ups mid-call — especially on Terraform state, rollout strategies, or incident timelines — Hireduce can surface probes against the criteria you set with the hiring manager, while you keep the human conversation.
FAQ
Should I ask candidates to white-board Kubernetes architecture?
Only if you can score it. Most non-technical recruiters get more signal from a real incident and deploy-path narrative.
Is AWS certification enough to advance?
Treat it as a plus, not a pass. Advance on owned production change + failure story.
DevOps vs SRE — which title should I use in outreach?
Use the title the hiring manager staffs and pays for — but screen for the work described, not the buzzword.