DevOps Engineer Interview Questions: What to Ask and What a Good Answer Contains
The job is to make it safe to change production often. Interview for that: how the candidate has made deploys boring, what they measure, and what they did on the bad days. Tool names are the least interesting thing on their CV.
- Ask about work the candidate owned, not opinions: every question below asks for a system, a deal, a campaign or a decision that actually happened, with what they did and what came of it.
- Score each answer against the note beside it. The notes describe observable things a strong devops engineer answer contains, so two interviewers write down the same evidence and reach the same score.
- Use the scorecard: delivery; incident handling; observability, and two more. Five criteria, scored 1 to 4, with a sentence of evidence each.
- Ask five questions well rather than eight in a rush. The first one, about something the candidate owned end to end, sets the tone: specifics, not generalities.
- Watch for the red flags listed below, which are patterns rather than single answers: talks about tools they installed, not problems they solved, for one.
The questions
1. Describe the deployment pipeline you are proudest of. What did it look like before you, and what does a deploy look like now?
What a strong answer contains: A before and after with numbers (deploy frequency, lead time, failed-deploy rate), and the specific changes that mattered. Look for reversibility: how a bad deploy gets undone.
2. Tell me about the worst incident you have worked. Timeline, please.
What a strong answer contains: Detection, diagnosis, mitigation, resolution, follow-up, each with a rough time. Names what made diagnosis slow and what changed so it would be faster. Composure in the retelling counts.
3. How do you decide what to alert on?
What a strong answer contains: Symptoms users feel, not every metric; alerts with an owner and a runbook; a story about an alert they deleted. Someone with 400 alerts is not on call effectively.
4. How do you manage secrets, and what is wrong with the way most teams do it?
What a strong answer contains: A secrets manager, short-lived credentials where possible, no secrets in repos or CI logs, rotation that has actually been done. Knows the common failures because they have seen them.
5. Walk me through how you would add a new service to an existing platform: infrastructure, observability, access.
What a strong answer contains: Infrastructure as code from a template, dashboards and alerts from day one, least-privilege access, an owner, and cost visibility. Notices what the platform makes easy and what it does not.
6. How do you keep cloud costs from creeping?
What a strong answer contains: Visibility per service or team, right-sizing with data, reserved capacity for the stable base, and a story about a bill they cut. Cost is a reliability concern in a small company.
7. What is the difference between a system that is highly available and one that is resilient? Which have you built?
What a strong answer contains: Availability as a number, resilience as behaviour under failure; has tested failure deliberately (killed a node, pulled a dependency) and describes what they found.
8. Tell me about a change you did not make because the risk was not worth it.
What a strong answer contains: Judgement: a tempting upgrade or migration weighed against the blast radius, and a decision to wait or to do it differently. Knows that not changing is also a choice.
Scorecard
Score each 1 to 4 with one line of evidence. A total is less useful than a pattern.
- Delivery: made deploys frequent, fast and reversible, with numbers
- Incident handling: a real timeline with a structural follow-up
- Observability: alerts on symptoms, with owners and runbooks
- Security basics: secrets, access, rotation, done not described
- Platform thinking: makes the right thing the easy thing for other engineers
Red flags
- Talks about tools they installed, not problems they solved
- No incident story, or one with no follow-up
- Alerts on everything, or on nothing
- Has never deliberately broken something to see what happens
How to run the interview
The pipeline question is the anchor. Ask for numbers, even rough ones: deploys per week before and after, how long a deploy takes, how a rollback works and how long it takes. Candidates who improved a pipeline can quantify it; candidates who maintained one describe it.
Give the incident question time. The timeline format keeps it concrete and shows how the candidate thinks under pressure. Follow up on what made diagnosis slow: missing dashboards, a runbook nobody had, a dependency nobody knew about. Those answers tell you what they will fix first at your company.
End with the change they did not make. Operations judgement is largely knowing when to leave things alone, and the candidates who can tell that story have it.
Frequently asked questions
Should we ask them to write Terraform or Kubernetes manifests live?
Ask them to review a small, deliberately flawed one and say what they would change. Reading infrastructure code well is the daily skill; writing it from a blank file under observation is not.
How much security should a DevOps interview cover?
The basics in the questions above, seriously. Secrets in repos, over-broad IAM and unrotated credentials are how small companies get breached, and this role is where they get prevented.
Is a cloud certification a useful signal?
Weak. It shows they can study. The incident and pipeline questions show whether they can operate.
Related guides
Screening devops engineer CVs this week?
Paste the job description into WadeCV, check the rubric it drafts, and upload the CVs. Each one is read against the rubric and scored with an explanation. Ten screenings are free; there is no subscription.
Screen your first CVs free