DevOps Engineer interview scorecard template
A structured scorecard for interviewing a DevOps Engineer: six weighted competencies, what a 1 and a 5 actually look like, and questions that surface evidence instead of opinions. Print it, or copy it into your ATS.
The DevOps Engineer scorecard
| Competency | Weight | Score 1 — what it looks like | Score 5 — what it looks like |
|---|---|---|---|
| Infrastructure as code Whether infrastructure is defined, reviewed and reproducible in version control, which determines if an environment can be rebuilt without the person who built it. | 20% | Admits production drifted from the code and that changes are still applied by hand; cannot say when the configuration was last applied cleanly. | Describes how state and modules are organized, how a change gets reviewed before it reaches production, and what happens when a plan shows unexpected drift. |
| Pipeline and release engineering Whether the candidate can make deployments frequent, reversible and boring, which governs how much risk each release carries for the product team. | 18% | Describes deploys as a scheduled event with manual steps; rollback means restoring a backup and they cannot state how long it takes. | Gives the deploy frequency and rollback time for a system they owned, and explains a specific pipeline change that moved one of those numbers. |
| Observability and incident response Whether the candidate can detect, diagnose and close incidents with evidence, and turn each one into a change that prevents the repeat. | 18% | Recalls incidents as outages that got fixed; alerts are numerous and routinely ignored, and no postmortem produced a tracked action item. | Walks through one incident end to end — signal, hypothesis, mitigation, root cause — and names the alert or guardrail that was added afterwards. |
| Reliability, capacity and cost Whether the candidate sizes and tunes infrastructure against measured demand, which decides if the platform survives a peak and what it costs at rest. | 15% | Sizes resources by copying the previous environment; describes cost as a finance concern and cannot name the largest line in the bill. | Cites a load pattern they measured, the scaling or sizing change it justified, and the effect on both headroom and monthly spend. |
| Access, secrets and build supply chain Whether credentials, permissions and build inputs are controlled by default, since a platform role holds the keys to every environment at once. | 15% | Shares long-lived credentials in a chat or a repository; describes access reviews as something that has never happened on their systems. | Describes rotating a credential without an outage, scoping permissions down after a review, and where secrets live so no human copy exists. |
| Developer experience and platform adoption Whether the candidate builds paths product teams actually use, since unused tooling leaves the same manual work in place plus more to maintain. | 14% | Measures success by tools delivered; cannot name a team that adopted the platform or a piece of tooling that ended up abandoned. | Describes talking to the teams before building, a workflow that measurably shortened, and a tool they retired once nobody was using it. |
Weights sum to 100. Agree them before the first interview, not after — adjusting weights once you have scores is how a panel rationalises a favourite.
Questions that surface evidence
Each one asks for something that already happened, in enough detail to verify. Hypotheticals reward rehearsal, not track record.
- Walk me through the last production incident you were paged for. What was the first signal, what did you rule out, and what changed afterwards?
- Describe an environment you rebuilt from code. What was still manual, and how did you find out the code and the running system had drifted apart?
- What were the deploy frequency and rollback time on your last system, and what did you personally change to move either number?
- Tell me about a credential or permission you had to change on a running system. How did you sequence it so that nothing went down?
- Point to tooling you built that a product team adopted. How did you know they were using it, and what did you change after their feedback?
Red flags
- Lists tools on the resume but cannot describe a change they made to a running production system.
- Describes manual production access as normal and has no version-controlled definition of any environment.
- Every incident story ends at the mitigation, with no root cause and no follow-up action.
- Treats developers as users to be gated rather than the teams the platform exists to serve.
How to use this scorecard
- Agree the weights with the panel before anyone interviews, and write them down.
- Every interviewer scores every competency independently, adding a note that quotes what the candidate actually said.
- Compare scores before discussing them. Discussing first anchors the panel on whoever speaks loudest.
Build a custom scorecard → · Boolean string to source a DevOps Engineer →
Frequently asked questions
What should a DevOps engineer interview cover?
Infrastructure as code, pipelines and release safety, observability and incident response, capacity and cost, access and secrets, and how product teams actually use what they build. Ask about systems they ran, not tools they have heard of. The strongest signal is one specific incident they can narrate end to end.
How do you tell DevOps, SRE and platform engineering apart when writing the scorecard?
The titles overlap, so score the work rather than the label. If the role is mostly on call for availability, weight incident response and reliability higher; if it is mostly building paths for other teams, weight infrastructure as code and developer experience. Write the weights down before interviewing so the bar does not move between candidates.
How do you check that a DevOps candidate has real production experience?
Ask for numbers they should know: deploy frequency, rollback time, the largest line in the cloud bill, how long the last incident took to detect. People who ran the system have these; people who watched it do not. Recording each answer with the evidence cited next to the score makes candidates easy to compare later without relying on memory.
When the stakes are a real hire, use evidence
These tools are quick heuristics. Verdict reads the CV against your job description and scores six dimensions with verbatim quotes as evidence — a hiring document you can defend.