DevOps / Site Reliability Engineer interview kit: questions and rubric

How to use this kit

1. Agree the competencies with the hiring manager before the job is posted.
2. Give each interviewer one or two competencies, so nothing is asked twice.
3. Ask every candidate the same core questions; follow up freely.
4. Rate each competency against the anchors straight after the interview, alone.
5. Debrief on quotes, not adjectives, then decide with the rule at the end.

First-round screen

Fifteen to twenty minutes, by phone, video or a disclosed AI screen. The aim is to confirm the basics before the panel spends its time.

1. What draws you to infrastructure and reliability work, and which part of it do you want more of in your next job?
2. Walk me through the platform you run today: what runs where, how code reaches production, and what pages you at night.
3. Which of the tools named in the job description (the cloud provider, the infrastructure-as-code tool, the container platform, the CI system) have you run in production, and at what scale?
4. The job description sets out the location, working pattern, on-call rota and start date. Do those work for you, what is your notice period, and what compensation range are you expecting?

1. Role-play, 25 minutes: you are on call. At 14:10 an alert fires: checkout errors are at 18% and rising. A config change and an application deploy both went out in the last hour. I play the system and your colleagues; ask for any dashboard, log or person. Walk me through what you do, minute by minute. (Script it in advance: what each dashboard shows, and the cause, such as a config change that shrank the database connection pool.)

   Follow up with

   • Who do you tell, when, and what does your first update say?
   • Rolling back the deploy did not help. What next?
   • What goes into the incident review, and what stays out?
   Strong answer

   Acknowledges the alert and declares an incident, takes or assigns incident command, and posts a short status update early. Checks recent changes first, rolls back the likeliest one, and when that fails moves to the next hypothesis with evidence. Changes one thing at a time, separates mitigation from root cause, and proposes a blameless review with owned actions.

   Weak answer

   Reads logs alone for 20 minutes without telling anyone, or changes several things at once so nobody knows what fixed it. Blames the person who shipped the change.

2. Tell me about the worst incident you have been part of. What was your role, and what changed afterwards?

   Follow up with

   • What did the timeline show that people did not expect?
   • Which follow-up actions actually got done?
   Strong answer

   Gives a specific incident, their own role in it, the mitigation and the root cause, and actions that were completed and checked. Describes the review as learning about the system, not about who erred.

   Weak answer

   The story is a late-night hero fix with no follow-up, or about whose fault it was. Actions were written down and never done.

1. Work sample, 15 minutes: here is a short Terraform or OpenTofu change (use your own tool if different). It renames a database resource, opens a security group to 0.0.0.0/0 on the database port, and hard-codes a cloud access key. Review it as you would for a teammate.

   Follow up with

   • What would the plan show for the renamed database, and why does that matter?
   • Where should the key live instead?
   • How should this change reach production?
   Strong answer

   Spots that the rename would destroy and recreate the database, and proposes a moved block or a state move instead. Rejects the open port and the hard-coded key, suggests a secrets manager or workload identity, and expects the plan output in review and a pipeline, not a laptop, to apply it.

   Weak answer

   Reviews formatting only, misses that the database would be replaced, or approves the open port as temporary. Applies changes from their own machine.

2. Tell me about something you automated that people used to do by hand. How did you decide it was worth it?

   Follow up with

   • What did it break the first time?
   • Who maintains it now?
   Strong answer

   Names the toil, how often it happened and what it cost, the automation built, how it was tested and rolled out, and what it takes to maintain. Knows when a task is not worth automating.

   Weak answer

   Automated for its own sake, or built a script only they understand. Cannot say whether it saved anything.

3. What would you do if production no longer matches the infrastructure code, because people make console changes during incidents?

   Follow up with

   • How would you find all the drift?
   • What would you allow in an emergency?
   Strong answer

   Detects drift with regular plans, imports or reverts each change deliberately, keeps an audited break-glass path for emergencies with a rule to bring changes back into code within a day, and removes the reasons people reach for the console.

   Weak answer

   Runs apply and overwrites production without checking what the console changes were for, or locks everyone out with no emergency path.

1. Our pipeline takes 45 minutes from merge to production, and a bad release last month took two hours to roll back. You have one quarter. What would you look at and change?

   Follow up with

   • What would you measure first?
   • How would you make rollback fast enough that people use it without fear?
   • What would you leave alone?
   Strong answer

   Measures where the time goes before cutting anything, caches and parallelizes builds, moves slow checks off the merge path, and makes rollback one tested step. Introduces canary or progressive rollouts with automatic health checks, and backward-compatible database migrations so a rollback stays safe.

   Weak answer

   Proposes a new CI vendor without measuring, or removes tests to save time. Ignores that a database change can make rollback impossible.

2. Tell me about a release that went wrong in a pipeline you owned. What did the pipeline do, and what did you change?

   Follow up with

   • Why did no check catch it?
   • How long did it take to get back to safe?
   Strong answer

   Describes the failure, why the pipeline let it through, and a specific fix: a smoke test, a canary stage, an automatic rollback on failed health checks, or a rule for migrations.

   Weak answer

   Blames the developer who shipped, or adds a manual approval step as the only fix.

1. A service has 60 alerts, mostly on CPU, memory and disk, and the on-call engineer is paged about ten times a week, usually for nothing. What would you change?

   Follow up with

   • What would you page on instead?
   • How would you set the thresholds?
   • How do you get the team to agree to delete alerts?
   Strong answer

   Moves paging to user-facing symptoms (errors, latency, availability) measured against an agreed service level objective, demotes cause-based alerts to dashboards or tickets, uses error-budget burn rates to set urgency, and reviews every page for whether it needed a human.

   Weak answer

   Raises every threshold, or adds more alerts to catch what was missed. Cannot explain an SLO or why a CPU alert might not matter.

2. Tell me about a time your monitoring missed a problem that users noticed first. What did you change?

   Follow up with

   • What signal would have caught it?
   • How did you check the new alert fires?
   Strong answer

   Names the gap (a silent failure, an outage in one region, a scheduled job that stopped running), the signal added (a synthetic check, an alert on missing data, a trace), and how they tested that it fires.

   Weak answer

   Added a dashboard nobody watches, or blamed users for reporting late.

1. What would you do if the monthly cloud bill rose 40% in two months and finance asked you why?

   Follow up with

   • Where would you look first?
   • Which savings would you not take, and why?
   Strong answer

   Breaks the bill down by service, team and tag, finds the drivers (an oversized cluster, forgotten environments, data transfer, log volume), takes the safe quick wins, and puts budgets, alerts and ownership tags in place. Weighs each saving against reliability and explains the trade-off to finance in plain terms.

   Weak answer

   Cuts instance sizes across the board without checking load, or says cost is finance's problem. Cannot explain what the bill is made of.

2. Tell me about a change you made to make access to production safer. What was the risk, and what did you do?

   Follow up with

   • How were secrets stored and rotated afterwards?
   • What would you do in the first hour after a key leaked?
   Strong answer

   Describes moving to least-privilege roles, single sign-on or short-lived credentials instead of shared keys, an audited break-glass path, a secrets manager with rotation, or image and dependency scanning in the pipeline. For a leaked key: revoke first, then rotate, check the audit logs, and find how it leaked.

   Weak answer

   Sees no problem with a shared admin account or long-lived keys. Cannot say how a leaked key would be revoked, or would investigate before revoking it.

Never ask

• Don't ask a candidate's age, or their graduation year to work it out. Why: age says nothing about operations skill, and age-based decisions are unlawful in many places.
• Don't ask about marital status, children, pregnancy or caregiving duties, even to judge on-call availability. Why: none of it is job-related, and it is put mostly to women. Describe the on-call rota and ask every candidate whether they can work it.
• Don't ask about religion, caste, community or the origin of a surname, directly or by proxy ('What does your father do?'). Why: in India these questions signal caste and religion, which have no bearing on the job.
• Don't ask 'Where are you from originally?' or 'What is your native place?'. Why: it invites judgments about region, language and community. If location matters, ask whether the candidate can work from the job's location.
• Don't ask about health conditions, disabilities or past medical leave, including whether they can handle night pages. Why: the only relevant question is whether the candidate can perform the essential functions of the job, with or without reasonable accommodation.
• Don't ask about arrests or criminal records in the interview, even though the role holds production access. Why: many US states and cities restrict when employers may ask, and an arrest is not a conviction. If the role needs a background check, run it lawfully and at the stage the law allows.
• Don't ask for salary history where the law restricts it: many US states and cities do, and the EU Pay Transparency Directive requires member states to. Why: it carries past pay gaps into the new offer. Ask for the expected range; in India, where current pay is commonly asked, still set the offer from the role's band.
• Don't ask the candidate to describe their current employer's network layout, security controls or unpatched weaknesses. Why: it asks them to breach confidentiality, and a candidate who complies would do the same with yours. Ask about problems and their own decisions in general terms.

Questions people ask

What is the difference between a DevOps engineer and an SRE interview?

The overlap is large: both own infrastructure, pipelines and production. SRE roles weigh reliability practice more heavily (service level objectives, error budgets, incident command), while many DevOps roles weigh delivery tooling and developer experience. Use one kit for both and move the must-haves to match the job description.

How do you run an incident role-play in an interview?

Write the scenario and the answers in advance: what each dashboard shows, what each colleague says, and the real cause. The interviewer plays the system and answers only what the candidate asks. Use the same script for every candidate, and rate the process (communication, mitigation, hypotheses) more than whether they find the cause in time.

Should DevOps candidates do a hands-on lab or take-home?

A short live review of an infrastructure or pipeline change shows most of what a lab does, without hours of setup. If you use a lab, run it in a disposable sandbox you provide, cap it at an hour or two, and never use your real accounts. Discuss the result in a follow-up interview.

Do cloud or Kubernetes certifications matter when hiring DevOps engineers?

They show study, not production judgment. Treat a certification as a small plus at most, and do not screen candidates out for lacking one. The role-play and the code review in this kit show the skills directly.