DevOps Questions to Ask
Twenty questions for working out how software actually ships somewhere, whether you are interviewing with a team, evaluating a vendor, or reviewing your own setup. They ask for numbers and recent incidents rather than tool lists: lead time, who gets paged, when the last restore was tested, and what keeps getting postponed.
The questions
Open any question for the note
How long does it take a one-line change to reach production, and what slows it down?
Why ask it
Lead time is the single most informative number about a delivery pipeline. Answers in minutes and answers in weeks are both fine; an answer of it depends usually means nobody measures it.
What does a deploy look like in practice: who does what, and how often does it happen?
Why ask it
Frequency and ceremony travel together. If deploys need a named person, a window and a meeting, everything else you hear about automation is describing intent rather than practice.
How do you find out something is broken, and does a customer usually get there first?
Why ask it
The honest answer to the second half tells you more than any dashboard tour. Teams that learn from support tickets have monitoring that reports health rather than detects failure.
What breaks most often, and has anyone been given time to fix the cause?
Why ask it
Every team can name its recurring failure. Whether anyone has been allowed to work on the underlying cause tells you how the organization treats reliability against feature work.
Which parts of the infrastructure are defined in code, and which exist because somebody set them up by hand?
Why ask it
There is nearly always a hand-built remainder, and pretending otherwise is the answer to be suspicious of. What matters is whether the team knows exactly which pieces those are.
How would a new engineer get a working environment on day one, and how long does that take?
Why ask it
This is measured in hours or in weeks and the difference is felt in everything else. A long answer usually also means the setup instructions are out of date and passed on verbally.
Where do staging and production differ, and how has that bitten you?
Why ask it
Asking how it has bitten them produces a real story instead of an assurance of parity. Data volume, third-party sandboxes and network policy are the usual offenders.
How do you manage secrets and credentials across environments?
Why ask it
Secret handling is where security maturity actually shows. Ask when a credential was last rotated and how long that took, because the existence of a vault says less than the rotation history.
What runs before a merge, and which of those checks do people rerun until they pass?
Why ask it
The second half exposes flaky tests, which quietly destroy the value of a test suite. A team that names its flaky tests is managing them; a team that denies having any is rerunning without noticing.
What is your rollback story, and has anyone used it under pressure?
Why ask it
Documented rollback and rehearsed rollback are different things. Where migrations are involved, ask specifically whether a schema change has ever actually been reversed.
Who gets paged at 3am, and how often does that happen?
Why ask it
On-call load measures both system stability and how sustainable the job is. A rota with two names on it is a retention problem regardless of how good the tooling is.
What happened in your last serious outage, and what changed afterward?
Why ask it
Ask for the change, not the timeline. Postmortems that produce a document and no altered code or process are a review habit rather than a learning one.
How do you decide when to scale, and has a bill or a limit ever surprised you?
Why ask it
Surprise bills and hit quotas are the concrete version of a capacity planning question. The story of one is worth more than a description of how forecasting is meant to work.
When did you last restore from a backup, and did it work?
Why ask it
Backups that have never been restored are an assumption. The useful answers include a date and a duration, because recovery time is the part that surprises people during an actual loss.
Where does security review sit in the process, and can it stop a release?
Why ask it
If review cannot block, it is advice. If it can block but never has, ask what it caught instead, since a control with no history of use tends not to be exercised at all.
What compliance obligations shape the pipeline, and what evidence do you have to produce?
Why ask it
Evidence requirements drive real engineering work: approval trails, log retention, separation of duties. Teams that bolt this on at audit time will describe it as a paperwork exercise.
Where is this written down, and who is the one person the team cannot function without?
Why ask it
Almost every team has a single point of human failure and most will name them cheerfully. The follow-up is what has been done about it, and the usual answer is nothing yet.
When something lands between two teams, how do you decide who owns it?
Why ask it
Ownership disputes are where incidents stretch from minutes into hours. Look for a default owner and an escalation path rather than a description of good collaboration.
What work does the team keep postponing because there is never time?
Why ask it
The deferred list is the risk register nobody has budgeted for. People answer this one openly, and it often surfaces the version upgrade or certificate renewal that will cause the next outage.
If you could change one thing about how software ships here, what would it be?
Why ask it
A closing question that reveals whether frustration is shared or individual. Ask several people separately, because a common answer is a strong signal and a scattered set of answers is a different kind of signal.
Using these questions well
Practical guidance for the conversation itself
Adjust for why you are asking
Interviewing with a team
Lead time, on-call load and the last outage tell you what the job feels like day to day. Ask the engineers rather than the hiring manager, and ask the same two questions of both so you can compare.
Evaluating a vendor
Push on restore testing, rollback, secret rotation and status history. Ask for the last three incident writeups by date; a vendor that publishes them will send them, and one that does not will explain why it cannot.
Reviewing your own setup
Ask questions 4, 9, 17 and 19 to different people separately and compare. Disagreement about what breaks most often is itself the finding, and it is usually about who feels the pain.
Taking over an existing system
Start with the hand-built infrastructure, the single point of human failure and the last successful restore. Those three determine what you can safely touch in your first month.
Reading the answers
- Prefer a number with a date over a description of a process. We deploy about twice a week and last shipped on Tuesday is a real answer.
- Tool names tell you very little. The same tools support both an excellent pipeline and a stalled one, so ask what the tool is configured to prevent.
- Listen for the passive voice. It gets deployed and it is monitored are usually places where ownership is unclear.
- Ask when, not whether. Whether you test restores invites yes; when you last tested one invites a date or a pause.
- A team that talks openly about what is broken is usually in better shape than one with no complaints, because the second has either fixed everything or stopped looking.
Follow-ups worth having ready
Most of these questions get a general answer first, and one follow-up converts it into something checkable. After a lead time answer, ask what the longest step is and who owns it. After an incident story, ask which line of code or which setting is different today. After a monitoring answer, ask what page fired last week and whether it was actionable. After anything about automation, ask what still requires somebody to be awake. Keep going until you reach a specific artifact: a dashboard, a runbook, a pull request, a date. That is where the description stops and the practice starts.
What goes wrong
Turning the conversation into a maturity audit
Scoring a team against a model puts them on the defensive and produces the answers they think you want. Ask about last week instead of about capability levels.
Confusing tooling with practice
A pipeline definition, a dashboard and an on-call rota can all exist while releases still go out by hand on a Friday. Always ask what happened most recently.
Asking only the platform team
The people who feel the friction are usually product engineers waiting on a deploy. Their account of the same pipeline will differ, and both accounts are true.
Collecting answers and doing nothing
Nineteen questions of diagnosis and no follow-through is worse than not asking, because the team told you what was wrong and watched nothing change.