Six question sets for the employer deciding what to ask: screening, pipelines, incidents, access and cost, small-team fit with a work sample brief, and a weighted scorecard. Every question carries why it is worth asking and what a strong answer sounds like. Download as DOCX.
The hardest part of hiring a DevOps engineer at a small company is that the person interviewing usually cannot verify the answers. I have sat on the employer side of that call more than once, holding a list of questions copied from somewhere, nodding at words I could not evaluate, and deciding on confidence instead of evidence. That is how you end up paying senior money for someone who has only ever extended a pipeline somebody else built.
This page is written for the employer deciding what to ask, not for the candidate rehearsing answers. At FirstHR, we build for companies hiring without an HR department, where the founder runs the whole loop alone. Six question sets below, every question paired with why it is worth asking and what a strong answer sounds like, plus a weighted scorecard so the decision rests on something you wrote down.
TL;DR
Interview a DevOps engineer on five things: the delivery path they built, how they behave during failure, how they handle access and secrets, whether they control cloud cost, and whether they fit a small team. Ask every candidate the same questions, grade on real numbers and honest sequencing rather than tool names, and score on a weighted rubric. Six question sets and a scorecard download as DOCX.
What to Assess in a DevOps Engineer
Assess four areas: delivery and automation, behavior under failure, access and security discipline, and fit for a team without a platform organization behind it. Tool familiarity is the easiest thing to check and the least predictive, which is why a question list built around technology names tells you almost nothing about how someone will perform here.
The reason is structural. A DevOps engineer at a large company owns a narrow slice with specialists on either side. The same title at a company of thirty people means pipelines, cloud accounts, monitoring, backups, on-call, and often the security questionnaire that arrives with an enterprise deal. Interviewing for the first version of the job when you are hiring for the second is the most common and most expensive mistake in this hire.
Delivery and automation
Describes a real path from merge to production
Automates with a stated cost and benefit
Has rolled back under pressure
Operating under failure
Names an outage with real timings
Stabilizes before investigating
Follow ups that shipped and held
Access and security
Secrets in a store, never in source control
Least privilege as the default
Offboarding list written before it is needed
Fit for a small team
Wants breadth, not a narrow platform slice
Explains trade offs to non engineers
Prefers boring, reversible choices
Everything below follows from that. The questions ask for systems the candidate has run rather than tools they have touched, and the scorecard weights small-team fit alongside technical depth instead of treating it as a soft afterthought.
The Six Question Sets
The sets are organized by what they test rather than by seniority, so you can mix them to match the role you actually wrote. A screen uses the first set alone. A deep interview usually pairs it with two others chosen for where the job leans.
Core Screening
Every candidate
Works as a 30 minute screen on its own: the real deployment path, what they changed, what they have run in production, and what they chose not to automate.
Pipelines and IaC
The delivery path
Continuous integration checks, flaky builds, infrastructure as code, configuration drift, environment consistency, and a rollback they have actually performed.
Incidents and On-Call
Highest value set
The worst outage they lived through, what changed afterward, what deserves to wake someone up, and the first fifteen minutes of an outage they are leading.
Access, Secrets, Cost
No security team here
Secrets handling, an exposed credential, production access reviews, offboarding, pipeline security checks, backups, and an unexplained cloud bill.
Small-Team Fit
Plus a work sample
Honest scope, breadth versus specialization, explaining trade offs to non engineers, and a fill-in work sample brief with a time cap and stated criteria.
Scorecard and Red Flags
Score, do not guess
A weighted 1-to-5 rubric across seven areas plus a red-flag checklist, so the decision rests on written evidence rather than on who sounded most fluent.
Pick Sets by Scope, Not by Title
Delivery-weighted role, where the pain is slow or unreliable releases: Core Screening plus Pipelines and IaC. Availability-weighted role, where the pain is downtime and a pager nobody wants: Core Screening plus Incidents and On-Call. Anyone who will hold administrative access to production, which at a small company is everyone in this role: add Access, Secrets, and Cost. First or only infrastructure hire: add Small-Team Fit. Use the Scorecard with every combination.
6 Free DevOps Question Sets to Download
Download all six as a single Word document or copy individual sets. Each one states when to use it, lists the questions with why they are worth asking and what a strong answer sounds like, names what to listen for, and leaves room for notes. The last file is the weighted scorecard.
Download All 6 DevOps Question Sets
Screening, pipelines and IaC, incidents and on-call, access and cost, small-team fit with a work sample brief, and a weighted scorecard. All in one DOCX.
Set 1: Core DevOps Screening Questions
The opening set for every candidate, and a complete 30 minute screen on its own: the real deployment path, what they changed after arriving, what they have run in production, and what they deliberately chose not to automate.
Core DevOps Screening Questions
CORE DEVOPS ENGINEER SCREENING QUESTIONS
Candidate: __
Company: __
Interviewer: __
Date: _
HOW TO USE THIS SET
This is the opening set for any DevOps engineer candidate, and it works as a 30
minute screen on its own. Ask 6 to 8 of these, in the same order, of every
candidate. Each question lists why it is worth asking and what a strong answer
sounds like, so you can judge the response even if you do not run infrastructure
yourself. Score on the rubric in Set 6 immediately after the call.
QUESTIONS
1. Walk me through the deployment path at your last company, from a merged pull
request to code running in production.
(Why: this is the whole job in one question, and it is very hard to fake.
Good answer: names the concrete stages, says who approves what, says how long
it takes, and volunteers the parts that were still manual.)
2. What was the state of that pipeline when you arrived, and what did you change?
(Why: separates people who built something from people who inherited it.
Good answer: a before and after with a number attached, such as deploy time,
deploy frequency, or how often a release had to be rolled back.)
3. How many services or applications were you responsible for, and how large was
the team around you?
(Why: calibrates scale. A candidate from a 40 person platform team may never
have owned anything end to end. Good answer: specific counts, and an honest
description of what they personally owned versus what the team owned.)
4. Which parts of this stack have you actually run in production, as opposed to
evaluated or used in a course?
(Why: invites honesty and gives you a clean signal either way.
Good answer: draws the line themselves, without being pushed to.)
5. Tell me about something you automated that you are proud of. What did it
replace, and what did it save?
(Why: automation judgment is the difference between a DevOps engineer and a
scripter. Good answer: names the manual process, the time or error rate it
removed, and who else could run it afterward.)
6. What is a piece of infrastructure you deliberately chose NOT to automate?
(Why: strong engineers know automation has a cost. Good answer: a real
example where the frequency did not justify the maintenance burden.)
7. How do you decide between building something in house and paying for a
managed service?
(Why: at a small company this decision is most of the budget.
Good answer: weighs engineering time against the bill, and does not treat
self hosting as automatically cheaper.)
8. What do you want the first 90 days here to look like?
(Why: reveals whether they read the role or applied to everything.
Good answer: asks about your current pain before proposing a plan.)
WHAT TO LISTEN FOR
•Specific systems, counts, and time frames rather than tool names
•Willingness to say "I have not done that" without hedging
•Interest in what is broken here before proposing a rebuild
•Ownership language about outcomes, not just tasks
NOTES
__
__
Set 2: Pipelines, Automation, and Infrastructure as Code
For roles that own the delivery path: continuous integration checks, flaky builds, infrastructure as code and the manual corners around it, configuration drift, environment consistency, and a rollback they have actually performed.
Pipelines, Automation, and Infrastructure as Code
PIPELINE, AUTOMATION, AND INFRASTRUCTURE AS CODE QUESTIONS
Candidate: __
Company: __
Interviewer: __
WHEN TO USE THIS SET
Use this set for any role where the hire will own continuous integration,
continuous delivery, and the definition of your environments. These questions
test whether the candidate can build a delivery path your team will trust, not
just whether they recognize the tools. Ask at least four.
QUESTIONS
1. What runs in your continuous integration pipeline before a change can merge,
and why those checks and not others?
(Why: tests the trade off between speed and safety.
Good answer: a short, fast set of checks with a reason for each, plus an
opinion on what belongs after merge instead of before.)
2. A build has been failing intermittently for two weeks and everyone reruns it.
How do you handle that?
(Why: flaky pipelines are the most common real problem at a small company.
Good answer: treats the flake as a defect with an owner, not as background
noise, and quarantines rather than deletes the test.)
3. How do you manage infrastructure as code, and what is still clicked by hand?
(Why: almost every environment has manual corners. Honesty here is the signal.
Good answer: names what is codified, admits what is not, and can explain the
order they would fix it in.)
4. Someone changed a resource in the cloud console and the code no longer
matches reality. Walk me through what you do.
(Why: drift handling separates real infrastructure as code experience from a
tutorial. Good answer: detect, reconcile, then close the hole that allowed the
manual change in the first place.)
5. How do you keep staging, production, and any other environment consistent?
(Why: environment drift causes releases that pass everywhere except
production. Good answer: shared modules or templates with explicit,
documented differences rather than copies that diverge over time.)
6. How do you roll back a bad deploy, and how long does it take?
(Why: a rollback story tells you how safe the whole system really is.
Good answer: a specific mechanism they have actually used under pressure, and
an honest note about the cases that cannot be rolled back, such as a database
migration.)
7. How would you deliver a first useful improvement here in week one?
(Why: tests whether they can work incrementally instead of proposing a six
month rebuild. Good answer: something small, visible, and reversible.)
WHAT TO LISTEN FOR
•Opinions with reasons attached, not tool preferences
•Comfort with incremental change on a system already in use
•Honesty about the manual corners that still exist
•A rollback plan they have personally executed
NOTES
__
Still Using Spreadsheets for Onboarding?
Automate documents, training assignments, task management, and track onboarding progress in real time.
The highest value set for a small company, because the hire is often your entire incident response function: the worst outage they lived through, what changed afterward, what deserves to wake someone up, and the first fifteen minutes of an outage they are leading.
Incidents, On-Call, and Reliability Questions
INCIDENT RESPONSE, ON-CALL, AND RELIABILITY QUESTIONS
Candidate: __
Company: __
Interviewer: __
WHEN TO USE THIS SET
Use this set whenever the hire will carry a pager or be the person you call at
2 a.m. It is the highest value set for a small company, because at your size the
DevOps engineer is often the entire incident response function. Ask at least
four, and push for the specific incident rather than the general philosophy.
QUESTIONS
1. Tell me about the worst production outage you were part of. What broke, how
did you find out, and how long until customers were served again?
(Why: the single most revealing question in the set.
Good answer: names the actual cause, gives real timings, and describes their
own role plainly, including what they got wrong.)
2. What changed afterward, and did it hold?
(Why: anyone can describe an outage. Fewer can describe a durable fix.
Good answer: a concrete follow up that shipped, and a check on whether the
same failure recurred.)
3. How do you find out something is wrong before a customer tells you?
(Why: tests monitoring judgment. Good answer: a small number of alerts tied
to customer impact, not a wall of dashboards nobody watches.)
4. What is your rule for what deserves to wake someone up?
(Why: alert fatigue destroys small on-call rotations faster than anything.
Good answer: pages only for things that are both urgent and actionable, and
they have deleted alerts before.)
5. Walk me through the first fifteen minutes of an outage you are leading.
(Why: tests process under pressure. Good answer: stabilize first, communicate
early, investigate root cause after service is restored, and keep a written
timeline as they go.)
6. How do you run a post incident review without it turning into blame?
(Why: culture question with a practical answer.
Good answer: focuses on the conditions that allowed the failure, assigns
follow ups to named owners with dates, and shares the write up.)
7. What does a healthy on-call rotation look like to you, and what would you
need from us to make ours sustainable?
(Why: lets the candidate tell you what is missing here.
Good answer: asks about volume, escalation, coverage, and compensation
without embarrassment.)
8. What have you deliberately left less reliable, and why?
(Why: reliability costs money. Good answer: a real trade off tied to what the
business actually needs.)
WHAT TO LISTEN FOR
•Real timings and real customer impact, not hypotheticals
•Calm sequencing: stabilize, communicate, then investigate
•Willingness to name their own mistakes
•Questions back to you about the current rotation
NOTES
__
Set 4: Access, Secrets, and Cloud Cost
For anyone who will hold administrative access to production, with no security team behind them: secrets handling, an exposed credential, production access reviews, offboarding, pipeline security checks, backups, and an unexplained cloud bill.
Access, Secrets, and Cloud Cost Questions
ACCESS, SECRETS, AND CLOUD COST QUESTIONS
Candidate: __
Company: __
Interviewer: __
WHEN TO USE THIS SET
At a small company this hire usually holds administrative access to your cloud
accounts, your pipeline, your secrets store, and your production data, and often
owns the cloud bill as well. There is rarely a security team behind them. Use
this set for anyone who will hold that access, and treat weak answers here as
disqualifying rather than as a training gap.
QUESTIONS
1. How are secrets stored and delivered to your applications today?
(Why: the fastest way to find out how a candidate really works.
Good answer: a managed secrets store or an equivalent, with rotation, and no
credentials in source control or in a shared spreadsheet.)
2. A credential is exposed in a public repository. Walk me through your first
hour.
(Why: tests sequencing under pressure.
Good answer: rotate first, then assess what the credential could reach and
whether it was used, then remove the history, then fix the process.)
3. How do you decide who gets production access, and how do you review it?
(Why: access sprawl is the most common finding in a small company audit.
Good answer: least privilege by default, named roles rather than shared
logins, and a periodic review with a date on it.)
4. What happens to access when someone leaves?
(Why: offboarding is where small companies are most exposed.
Good answer: a written list built while access was granted, with an owner and
a deadline per item.)
5. What security checks belong in the pipeline, and which ones are theater?
(Why: an opinionated answer shows real experience.
Good answer: a few checks that block a merge and produce actionable findings,
plus honest skepticism about scanners that only generate noise.)
6. Our cloud bill went up 40 percent last quarter and nobody knows why. What are
your first three steps?
(Why: at a small company the DevOps engineer usually owns this and it is
rarely in the posting. Good answer: attribute spend before cutting anything,
look for idle and oversized resources first, then discuss commitments.)
7. How do you keep backups honest?
(Why: untested backups are the most expensive assumption in infrastructure.
Good answer: has personally restored from a backup, and knows how long the
restore took.)
WHAT TO LISTEN FOR
•Rotate first, investigate second, on any exposed credential
•Least privilege described as a default, not an aspiration
•A restore they have actually performed
•Cost treated as an engineering problem with data behind it
NOTES
__
Companies Using FirstHR Onboard 3x Faster
Join hundreds of small businesses who transformed their new hire experience.
For your first or only infrastructure person: honest scope, breadth versus specialization, explaining trade offs to non engineers, plus a fill-in work sample brief with a time cap, stated evaluation criteria, and debrief questions.
Small-Team Fit and Work Sample Brief
SMALL-TEAM FIT QUESTIONS AND WORK SAMPLE BRIEF
Candidate: __
Company: __
Interviewer: __
WHEN TO USE THIS SET
Use this set when the hire will be your first or only infrastructure person. The
failure mode here is not technical skill, it is a specialist from a large
platform team who has never owned breadth and will be unhappy inside a month.
The work sample brief at the end replaces the whiteboard puzzle with something
that resembles the actual job.
FIT QUESTIONS
1. Here is the honest scope: pipelines, cloud infrastructure, monitoring,
backups, on-call, laptops, and the occasional security questionnaire. Which
parts do you actually want, and which would you rather not own?
(Why: an honest answer here saves both of you six months.
Good answer: names real preferences instead of claiming to love everything.)
2. When was the last time you were the only person who understood a system? How
did you handle it?
(Why: at your size they will be that person.
Good answer: wrote things down, taught someone else, or reduced the system
until it no longer needed a specialist.)
3. Explain what a container orchestrator does to someone on our sales team.
(Why: this hire will have to explain trade offs to non engineers, including
you. Good answer: plain language, no jargon, an analogy that holds up.)
4. A founder asks you to ship something today that you think is unsafe. What do
you do?
(Why: tests judgment and communication together.
Good answer: states the specific risk, offers a smaller safer option, and
accepts a decision made with the risk understood.)
5. What is the smallest, simplest version of our infrastructure that would still
work? Would you build that, or something more standard?
(Why: over engineering is the most expensive habit a first infrastructure
hire can bring. Good answer: prefers boring and reversible.)
6. What would make you leave a job like this after a year?
(Why: surfaces the real mismatch while it is still cheap.
Good answer: specific and candid rather than diplomatic.)
WORK SAMPLE BRIEF (FILL IN AND SEND)
Time cap: 2 hours. Do not exceed it. Paid: [ ] Yes [ ] No Amount: ___
The scenario:
__
Example: our application is deployed by hand from a laptop. Sketch how you would
get it to a repeatable, automated deploy, and what you would do first.
What to submit:
•A short written plan, one page maximum
•The first slice you would actually build, in whatever form is fastest for you
•A list of what you would need from us, and what you would not do yet
How we will evaluate it (share this with the candidate):
•Does the plan solve the stated problem rather than a bigger one?
•Is the first slice small, useful, and reversible?
•Are trade offs and assumptions written down?
•Is the writing clear enough for a non engineer to follow?
Debrief questions after they submit:
1. What did you leave out, and why?
2. What would you do differently with two more days?
3. Which part of this are you least confident about?
NOTES
__
Set 6: DevOps Interview Scorecard and Red Flags
A weighted 1-to-5 rubric across seven areas and a red-flag checklist, so the hiring decision rests on written evidence rather than on whoever sounded most fluent. Use it with any combination of the sets above.
DevOps Interview Scorecard and Red Flags
DEVOPS ENGINEER INTERVIEW SCORECARD AND RED FLAGS
Candidate: __
Company: __
Interviewer: __
Date: _
HOW TO SCORE
Score every area from 1 to 5 immediately after the interview, while the answers
are fresh. Anchor each score to something the candidate actually said. If more
than one person interviews, each scores independently before anyone discusses.
Use the same rubric, with the same weights, for every candidate in the same role.
Set the weights BEFORE the first interview, not after you meet someone you like.
Rating scale:
5 = Strong, specific evidence 4 = Solid evidence 3 = Some evidence
2 = Weak or mixed evidence 1 = No evidence or red flags
SCORING AREAS
Delivery pipeline: builds and improves a path from merge to production
Strong answers share three properties regardless of the topic: they contain real numbers, they follow a sequence you can check, and they include something the candidate got wrong. Those three are legible to any interviewer, technical or not, which is the point.
Walk me through the deployment path at your last company, from a merged pull request to code running in production.
Strong answer: Names the concrete stages in order, says who or what approves each one, gives a real elapsed time, and volunteers which parts were still manual. A strong candidate adds what they would change about it and why, and can tell you how often that path was actually used.
Weak answer: A weak answer is a list of tool names with no system behind them, or a description so generic it would fit any company. Ask how long it took and how often it ran; vagueness on both is the signal.
Tell me about the worst production outage you were part of.
Strong answer: Names the actual cause, how they found out, how long customers were affected, and what they personally did. A strong candidate stabilizes before diagnosing, communicates during the incident, and describes a follow up that shipped and held. They will also tell you what they got wrong.
Weak answer: A weak answer is an outage that was always someone else's fault, or a story with no timings in it. Nobody who has run production for three years has no outage to describe, so a blank here usually means the exposure was not real.
A credential is exposed in a public repository. Walk me through your first hour.
Strong answer: Rotates the credential first, then assesses what it could reach and whether it was used, then cleans the history, then fixes the process that allowed it. A strong candidate treats rotation as the immediate action and history cleanup as the slower follow up.
Weak answer: A weak answer starts with deleting the commit, which leaves a live credential in the world while the candidate does housekeeping. Order matters more than knowledge here, and it is the clearest single tell in the whole set.
The most useful follow-up in the whole process is some version of how long did that take. A candidate who ran the system has the number. One who watched somebody else run it changes the subject to what the team was doing generally, and that shift is the answer.
A Work Sample Beats the Whiteboard
A short work sample drawn from your own environment predicts performance far better than a live algorithm puzzle, because it resembles the job and produces an artifact you can review after the fact. The EEOC's guidance on employment tests and selection procedures makes the same point from the compliance side: a selection procedure should be job related and applied consistently to everyone.
Keep it to two hours, state the evaluation criteria up front, and pay for anything longer. The brief in Set 5 is fill-in, but the shape matters more than the wording, so use the table below as the sanity check before you send one.
Element
What good looks like
Scenario
A real problem from your environment, not a puzzle invented for the interview
Time cap
Two hours, stated explicitly, with permission to stop when it is reached
Deliverable
A one-page plan plus the first slice they would build, in any form
Criteria
Shared with the candidate before they start, not invented afterward
Debrief
What did you leave out, what would two more days change, what are you least sure of
Consistency
The same brief and the same criteria for every candidate in the role
The debrief is where the work sample earns its cost. A candidate who can explain what they deliberately left out, and why, is showing you the judgment you are actually buying. If you need a second technical opinion, spend it reviewing this artifact rather than adding another round to the candidate's calendar.
Follow-Ups, Signals, and Red Flags
The prepared question opens the door and the follow-up tells you what is behind it. Push for the number, the sequence, and the specific system every time an answer arrives in the abstract. The patterns below repeat across almost every interview for this role.
When you hear
Ask this next
What it tells you
We used Terraform and Kubernetes
What did that stack actually run, and how many services?
Whether they operated a system or listed a resume
We had a solid CI/CD pipeline
How long did a deploy take, and how often did it run?
Real ownership produces numbers immediately
We had monitoring in place
What was the last alert that woke you up, and was it worth it?
Separates dashboards from an on-call reality
I would rebuild that
What would you check first before deciding to rebuild?
Whether they diagnose before they demolish
Security was handled by another team
What part of it did you own in the pipeline?
Honest scope, or a gap they are papering over
We never really had outages
What was the closest call, and what did you change?
Nobody running production for years has none
Two silences are worth noticing. A candidate who cannot name a single thing that went wrong on their watch is either very junior or not telling you the truth, and a candidate who proposes a full rebuild before asking what is currently broken will do the same thing on your infrastructure in month two.
Scoring a DevOps Interview
Score every area from 1 to 5 immediately after the interview, anchored to something the candidate actually said, using weights you set before the first conversation. Weights chosen afterward are a rationalization. If more than one person interviews, each scores independently before the group talks, so a single confident voice does not anchor the decision.
Weighting is where this rubric differs from a generic one. The areas that matter most depend on your scope, and a strong score in one should not paper over a weak score in another. Use a standard evaluation form if you want a general version, and the DevOps rubric in Set 6 when the role is this one.
Scoring area
What a 5 looks like
Weight higher when
Delivery pipeline
Built or rebuilt a path from merge to production, with numbers
Releases are slow, manual, or unreliable today
Infrastructure as code
Codified environments, handles drift, keeps them aligned
You are growing past one hand-built environment
Incident response
Stabilizes calmly, follows up durably, owns mistakes
You have customers and a pager
Security and access
Least privilege by default, secrets in a store, offboarding written
This hire will hold production credentials
Cost awareness
Attributes spend before cutting, right sizes with data
The cloud bill is a visible line in your budget
Communication
Explains trade offs plainly to people who are not engineers
Nobody else on the team can check their work
Small-team fit
Wants breadth, prefers boring and reversible, documents
This is your first or only infrastructure hire
Once the scores are in, a short written interview feedback step turns them into a decision you can explain later. Keep the scorecards with the rest of the hiring record rather than in somebody's notebook.
Matching the Questions to the Level
Ask the same questions at every level and change what a 5 means, rather than keeping a separate junior list. A junior candidate who describes a pipeline they extended carefully, with real detail, is a stronger signal than a senior candidate who describes one in the abstract.
Junior
Can follow and extend an existing pipeline, asks before changing production, and has a mentor in mind. Score breadth of curiosity, not depth of war stories.
Mid-level
Owns the delivery path end to end, has been on call, and can name a rollback they performed. This is the level most small companies actually need.
Senior
Has rebuilt a delivery path while it was in use, sets on-call policy, and can say no to their own preferred design when the business does not need it.
First hire
Level matters less than breadth and temperament. Weight small-team fit and communication heavily, and pay for the ownership rather than the title.
Level calibration also sets the band you are interviewing against, which is worth fixing before the first call rather than after a candidate names a number. There is no published federal wage for the title itself, so the benchmark has to come from the nearest classifications.
No Federal Occupation for the Title: Benchmark to the Nearest Classifications
The Bureau of Labor Statistics does not publish a DevOps engineer occupation. In its Occupational Employment and Wage Statistics survey (May 2025), the closest classification, software developers (SOC 15-1252), reported a national median annual wage of $135,980, with the 10th percentile at $82,460 and the 90th at $214,670. Operations-weighted roles sit closer to network and computer systems administrators (SOC 15-1244) at $99,130 (U.S. Bureau of Labor Statistics, OEWS national estimates).
Which neighbor you anchor to should follow the weight of the role you described in the interview. The full breakdown across seven adjacent occupations, plus the posting language that goes with each, lives in the DevOps engineer job description templates. Where pay transparency laws apply, the range you publish has to be one you will honor.
On-Call Questions Assume the Role Is Exempt. Check That First.
The FLSA computer employee exemption has a duties test and a pay test, and a junior infrastructure role paid below the salary threshold is non-exempt no matter what the title says. The pay test is met at the standard salary level on a salary or fee basis, or at an hourly rate of at least $27.63, and the duties test excludes work that is primarily help desk support or hardware installation (U.S. Department of Labor, Fact Sheet 17E). If the role is non-exempt, restrictive on-call time can count as hours worked. Our guide to exempt versus non-exempt classification works through both tests in order. This is general information, not legal advice.
Fair, Legal, and Structured Interviewing
A fair interview and an accurate one are the same interview. Asking every candidate the same job-related questions in the same order, scored against a rubric you set in advance, is what makes the comparison meaningful and what keeps the decision defensible. This is the part most question lists skip entirely.
Same questions, same order
Ask every candidate for the role the same core questions in the same order. Consistency is what makes the comparison defensible and the scores meaningful.
Keep it job related
Every question should map to something the person will do here. Age, family plans, origin, religion, health, and citizenship beyond work authorization stay out, including in small talk.
Set the weights first
Decide which scoring areas matter most before the first interview. Weights chosen after you meet a candidate are a rationalization, not a rubric.
Write it down and keep it
Keep the scorecards, notes, and work sample submissions with the rest of the hiring record, so a decision made months ago can still be explained.
Same Questions, Same Order, Scored on a Rubric
A structured interview, where every candidate answers the same questions against a consistent rubric, predicts on-the-job performance more reliably than an unstructured conversation, and asking the same job-related questions of everyone also keeps you inside the EEOC rules against decisions based on protected characteristics. Structure is both the fairer approach and the more accurate one.
Keep age, family plans, origin, religion, and health out of the conversation, including the small talk before the technical part starts. On-call is a legitimate topic when framed around the job, so ask what a sustainable rotation looks like rather than about someone's personal circumstances. Our list of illegal interview questions covers the traps, and reducing bias in the process covers the rest. This is general information, not legal advice.
Interviewing a DevOps Engineer Without HR
At a large company this candidate runs a coordinated loop with a recruiter holding the scorecards and a platform team assessing depth. At a small company the founder runs the interview alone, between everything else, and a bad hire here holds the keys to production. Three problems come up every time, and each has a fix.
You are interviewing for skills you do not have yourself
Most founders hiring their first infrastructure person cannot personally verify a Kubernetes answer, and they know it. The fix is not to borrow a technical friend for an hour and hope. It is to ask questions where the quality of the answer is legible without the domain knowledge: real numbers, real timings, a real sequence of actions, and a real mistake owned out loud. Every question in these sets carries a note on what a strong answer sounds like for exactly that reason. You are grading structure, specificity, and honesty, and those are visible to anyone. Where you genuinely need a technical read, spend it on the work sample rather than on the conversation, because a written plan can be reviewed later by someone who does know the domain.
The specialist who looks best on paper may be the worst fit here
A candidate from a 40 person platform team at a large company has deep experience in a narrow slice and a support structure around them that you do not have. At your size the same person owns pipelines, cloud accounts, monitoring, backups, on-call, and often laptops and the security questionnaire too. That is a different job, and pretending otherwise produces a resignation in month four. State the real scope in the interview, ask which parts they actually want, and treat an honest ‘I would rather not own laptops’ as useful information rather than as a failed answer. The small-team fit set exists to surface this while it is still cheap to act on.
This hire holds the keys before you have written the offboarding list
A DevOps engineer typically holds administrative access to your cloud accounts, your pipeline, your secrets store, and your production data within the first two weeks. The interview is where you find out whether they treat that access as a responsibility with a process attached, and the offer stage is where you build the record: a confidentiality and intellectual property agreement signed before day one, an access list with a named owner per item, and a removal step written while you are granting rather than on the afternoon somebody resigns. FirstHR runs that side of it, with e-signature for the agreements, document storage for the signed record, and task workflows that give every access grant an owner and a due date. Applicant tracking is coming soon to FirstHR.
Keeping the loop short is its own advantage. A screen, one deep interview, and a capped work sample is enough for most small companies, and a decision inside a week beats a longer process that loses the candidate. If you want a general version of this structure for other technical roles, our technical interview questions cover the same ground without the infrastructure specifics.
From Interview to Onboarding
The interview is step one. For this role the offer stage carries extra weight, because a DevOps engineer reaches production data faster than almost any other hire: a written offer, a signed confidentiality agreement, and an access list built while you are provisioning rather than on the day somebody resigns.
Offer, confidentiality, and IP
A written offer plus confidentiality and intellectual property agreements signed before day one, because this hire reaches production data in week two.
Provision access with an owner
Every cloud account, repository, secrets store, and third-party console granted with least privilege, each one assigned to a named owner with a due date.
Name the first real project
Pick one visible improvement for the first 30 days, say who they ask when stuck, and define what good looks like at 30, 60, and 90 days.
Write the removal list now
The provisioning list doubles as the offboarding checklist. Build it while you are granting access, not on the day somebody gives notice.
Run reference checks on the specifics you scored: ask a former manager what this person actually owned and how they behaved during an incident. If the role warrants a background check, apply the same policy to everyone in comparable roles rather than deciding candidate by candidate. Applicant tracking is coming soon to FirstHR.
After the offer, the work becomes a repeatable sequence, and our IT onboarding guide covers the access path from agreements through first production deploy. The same list, written once, becomes the IT offboarding checklist you will need eventually.
FirstHR connects the offer, the confidentiality and IP agreements, e-signature, the new hire paperwork, and the access-and-policy workflow in one place, and stores the signed record on the employee profile, so a company without an HR department can run the whole thing from one system. FirstHR is an onboarding and HR platform, not a cloud provider or a monitoring tool, so pair it with those. Applicant tracking is coming soon to FirstHR. More role templates for engineering and operations hires live in the hiring templates library.
Key Takeaways
Assess five areas: the delivery path they built, behavior under failure, access and security discipline, cost awareness, and fit for a team with no platform organization behind it.
The strongest opening question is to walk through the deployment path from a merged pull request to production, because it is the whole job in one answer and hard to fake.
Grade structure, specificity, and honesty rather than technology: real counts, real timings, a checkable sequence, and a mistake owned out loud are legible to any interviewer.
On the exposed-credential question, rotating first and cleaning history second is the correct order, and starting with the commit is the clearest single tell in the set.
Replace the whiteboard puzzle with a two hour work sample drawn from your own environment, with criteria shared up front and a debrief on what they left out.
There is no federal wage for the title, so benchmark to software developers at a $135,980 median (OEWS, May 2025) and adjust toward the administrator figure for operations-weighted roles.
Interview element
Generic question list
This kit
States why each question is worth asking
Says what a strong answer sounds like
Weighted scorecard for the decision
Work sample brief with stated criteria
Written for the employer, not the candidate
Frequently Asked Questions
What questions should I ask a DevOps engineer candidate?
Ask questions that test five things: the delivery path they built, how they handle failure, how they treat access and secrets, whether they control cost, and whether they fit a small team. The strongest opener is to have them walk you through the deployment path at their last company, from a merged pull request to code running in production, because it is the whole job in one question and very hard to fake. Follow with what the pipeline looked like when they arrived and what they changed, the worst outage they were part of and what changed afterward, how secrets are stored and delivered today, and what happens to access when someone leaves. Close with the honest scope of your role and ask which parts they actually want to own. This page groups those into six downloadable sets, each question paired with why it is worth asking and what a strong answer sounds like.
How do I interview a DevOps engineer if I am not technical?
You grade structure, specificity, and honesty rather than the technology itself, and those are visible to anyone. A strong answer contains real numbers: how many services, how long a deploy took, how long customers were affected, what the before and after looked like. A weak answer is a list of tool names with no system behind it. Three questions do most of the work for a non-technical interviewer: walk me through your deployment path, tell me about the worst outage you were part of, and a credential is exposed in a public repository, what is your first hour. The last one is scored on sequence, not knowledge, because rotating the credential first and cleaning history second is the correct order and is easy to check. Where you genuinely need a technical read, spend it on a short written work sample that someone else can review later, not on the live conversation.
What is the difference between a DevOps engineer, an SRE, and a platform engineer?
The titles overlap heavily and the boundaries are set by each company rather than by any standard. In common usage, a DevOps engineer owns the path from code to production plus the infrastructure underneath it, a site reliability engineer focuses on availability, error budgets, and incident practice for services that already exist, and a platform engineer builds internal tooling that other engineers consume as a product. At a small company one person usually does all three, which is why the interview should follow your actual scope rather than the title you advertised. Decide what the role really owns first, then pick the question sets that match: pipelines and infrastructure as code for delivery-weighted roles, incidents and on-call for availability-weighted roles, and the small-team fit set whenever the hire will be your only infrastructure person.
Should a DevOps interview include a coding test?
A live coding puzzle is a poor predictor for this role, because almost nothing in the job resembles solving an algorithm question under observation. A short work sample that mirrors the actual work predicts far better and respects the candidate's time. Cap it at two hours, state the evaluation criteria up front, and pay for it if it runs longer than that. A good brief for infrastructure work is a scenario from your own environment: our application is deployed by hand from a laptop, sketch how you would get to a repeatable automated deploy and what you would build first. Evaluate whether the plan solves the stated problem rather than a larger one, whether the first slice is small and reversible, and whether trade offs are written down. The debrief matters as much as the submission, so ask what they left out and why. A fill-in work sample brief is included in the fifth question set on this page.
What are the red flags in a DevOps engineer interview?
The clearest red flag is an answer made entirely of tool names with no description of the system those tools ran. Others worth weighing: no real numbers anywhere, meaning no service counts, no deploy timings, no before and after; an inability to name anything that went wrong on their watch; proposing a full rebuild before asking what is currently broken; treating credentials in source control or shared production logins as normal; never having restored from a backup; and dismissing documentation and handover as somebody else's job. On the exposed-credential question, starting with deleting the commit instead of rotating the credential is a sequencing error that matters more than any knowledge gap. None of these is automatically disqualifying on its own, but two or three together usually mean the exposure was narrower than the resume suggests.
How long should a DevOps engineer interview process take?
Two or three rounds is enough for most small companies, and speed is a genuine competitive advantage in this market. A practical shape is a 30 minute screen using the core set, a 60 minute deep interview using two topic sets chosen for your scope, and a short work sample with a debrief conversation. Score after each stage rather than at the end, and give the candidate a decision within a few days of the final step. Long, uncoordinated processes lose good infrastructure candidates to companies that moved faster, and every extra round adds cost without adding much signal once you have a work sample in hand. If you need a third technical opinion, bring it to the work sample review rather than adding another live interview to the candidate's calendar.
What questions are illegal to ask in a DevOps engineer interview?
Avoid anything that probes characteristics protected under federal law, which the EEOC enforces: age, race, color, religion, national origin, sex, pregnancy or family plans, disability, and genetic information. In practice that means no questions about how old someone is, where they are originally from, whether they plan to have children, their health, or their religious observance, even as small talk before the technical part starts. You may ask whether a candidate can perform the essential functions of the job and whether they are authorized to work in the United States. On-call questions are legitimate when framed around the job, so ask what a sustainable rotation looks like to them rather than about their personal or family circumstances. Asking every candidate the same job-related questions in the same order is the simplest safeguard. This is general information, not legal advice.
