How to Screen DevOps Engineers on CI/CD and Infrastructure: 9 Questions and What to Listen For Screening Interview Template

Describe the infrastructure you personally manage today. Which cloud, roughly how many services or hosts, and which parts are you the one who gets called about?

What this assesses: The last clause is the whole question. Strong answers narrow to what they hold the pager for and give shape to it: three regions, forty services, a Postgres cluster they own end to end, a Kafka cluster somebody else runs. Weak answers list the org's entire estate as though they own all of it, or describe scale in adjectives rather than numbers. Someone who cannot say what they get called about has been adjacent to operations, not in it.

Walk me through your CI/CD pipeline from commit to production. What runs automatically, who approves what, and what is the slowest part of it?

What this assesses: Every candidate can describe a pipeline. Fewer can tell you where theirs hurts. Strong answers walk the real path with times attached, name the stage that eats the clock, usually an integration suite or a serial build, and say what they tried or why they have not fixed it. They are also clear about approval gates and whether anyone actually reads them. Weak answers describe the pipeline they wish they had, or an idealized diagram with no numbers and no friction anywhere.

Tell me about the last deploy that went wrong. How did you find out, and what did you do in the first ten minutes?

What this assesses: Detection is the revealing half. Strong answers say an alert fired, a canary caught it, or error rate moved before anyone filed a ticket. Then they stabilize first: roll back, flip the flag, drain the bad instances, tell support what to say. Root cause comes after the bleeding stops. Weak answers start with a customer complaint or a message from an executive, then spend ten minutes reading logs while the service stays down. Note also whether they say what changed afterward, since a postmortem with no action item is a story, not a fix.

Roughly how many alerts fire on your team in a week, and what is one alert you deleted or rewrote because it was not worth waking someone up for?

What this assesses: This is the fastest way to separate operational maturity from tool familiarity. Strong answers give a number, admit whether it is too high, and name a specific alert they killed along with the reason: it fired on a symptom with no action attached, it duplicated another page, it threshold-alerted on a metric that was noisy by design. Weak answers describe an alerting philosophy without a number, or claim their alerting is well tuned and cannot name a single thing they changed. Nobody who has carried a pager for a year has zero examples.

What in your environment is managed as code today, and what is still clicked in a console? Where has infrastructure as code made things worse instead of better?

What this assesses: The honest answer to the first half is never everything, and candidates who claim otherwise are either new or not telling you the truth. Strong answers draw the line clearly, name the drift they live with, DNS records, one IAM policy, a dashboard, and give a real complaint about the tooling: state file contention, a module abstraction that made a simple change a two-day exercise, a plan output nobody can read. Weak answers treat the question as a tool checklist and describe infrastructure as code as an unqualified good, which usually means they have used it but never owned it through a bad migration.

What runs in containers on your team, who operates the orchestrator, and what breaks most often?

What this assesses: The middle clause is the calibration. There is a large difference between running workloads on a managed cluster somebody else configures and owning the control plane, upgrades, and networking. Strong answers say which one they are and are comfortable saying it, then name a recurring failure with specifics: eviction from bad resource limits, image pull failures on a registry limit, a networking policy that broke a service mesh. Weak answers claim deep Kubernetes expertise and then describe only writing deployment manifests. That is useful experience, but you should know that is what you are buying.

Tell me about a security requirement that slowed developers down. What did you actually do about it?

What this assesses: Look for someone who solved the tension rather than picking a side. Strong answers name the requirement, secret rotation, a scanning gate, least-privilege roles, then describe making the secure path the easy path: a template, a default, a self-service role request that returns in minutes instead of days. Weak answers land at either extreme. One says security is the business's problem and they just implement what compliance hands down. The other describes blocking every build on a scanner and treats developer complaints as evidence it is working.

Tell me about something you automated that used to be manual. How much time did it actually save, and how do you know?

What this assesses: Strong answers pick a real piece of toil, name who used to do it and how often, and give a number they can defend: onboarding an environment went from two days to twenty minutes, a weekly manual certificate rotation went away entirely. Best answers also mention the maintenance cost of the automation itself, because scripts rot. Weak answers describe automation with no before state, or claim large savings with no way to know, which usually means the manual process was never measured and the automation is a side project nobody else uses.

How much of this job do you expect to be on-call and firefighting versus building? What ratio would make you leave?

What this assesses: Ask this in the screen, not at the offer stage. DevOps hires quit over this more than over compensation. Strong answers give a specific past ratio and a specific limit: they were seventy percent interrupt-driven at the last job, they will accept a rotation of one week in four, they will not be the only person in the rotation. That is a candidate telling you where the offer breaks while it is still cheap to know. Weak answers say they are fine with whatever the team needs, which is either untrue or a person who has not yet been paged at three in the morning for six months straight.