September 21, 2026·6 min read
DevOps HiringEphemeral EnvironmentsHands On AssessmentLinux Troubleshooting InterviewProduction Debugging Interview
Ask a DevOps candidate to describe a good CI pipeline and you will hear the same answer from almost everyone. Stages. Caching. Artifacts. Environments. Gates before production. It is correct, it is a recital, and it tells you nothing.
Ask them to fix a build that passed yesterday and fails today, and inside two minutes you know whether they have owned one.
The whole difference is a single habit: where they look first.
Engineers who have lived with CI check what changed before they read the pipeline file.
Not the application diff. Everything else. The base image tag that moved under them. The cache that is now poisoned with a stale layer. The runner that is not the runner from last week. The dependency that resolved to a new patch version because nothing pinned it. The secret that rotated. The disk on the build host that filled up.
Candidates who have only read about CI go straight to the YAML and start editing, because the YAML is the part they have seen in tutorials. They will sometimes get there. It takes much longer, and along the way they will have changed several things that were not the cause.
That is the axis this interview measures, and you can measure it in fifteen minutes if there is a real pipeline in front of them.
1. The build that was green yesterday. Nothing in the application changed. The failure is environmental: a floating base image tag, an unpinned dependency, or a cache holding something that is no longer valid.
What you watch: whether they ask "what is different" before "what is wrong with this file". Whether they compare the failing run against the last passing one, which is the cheapest and most decisive move available and is skipped constantly. Whether they can read the build log to the actual first error rather than the last line, which is usually a summary of a summary.
2. The pipeline that is slow. Twenty-five minutes to know whether a one line change is safe. Nothing is broken. The job is to make it usable.
What you watch: whether they measure before optimising. Which stage is actually slow, and is it slow because of work or because of waiting. Strong candidates split the question into "what can run in parallel", "what can be cached correctly", and "what should not run on every commit at all". Weak candidates propose caching everything, which is how you get the poisoned cache in scenario one. The best answer we have heard started with a question: what is the acceptable feedback time, because that determines how much of this is worth doing.
3. The deploy that half worked. The pipeline reported success, the new version is in production, and a fraction of requests fail. Rollback is available.
What you watch: whether they roll back first and investigate second. That sequence is not obvious to people who have never had a customer on the phone, and it is the correct one. After that, whether they can say what the pipeline should have caught and where the gate belongs. A candidate who wants to add a smoke test against the deployed environment rather than more unit tests has understood which layer failed. This one pairs naturally with the live incident drill if you want to stretch the session.
Once they have fixed or diagnosed the thing, the design conversation is worth having, and it is a much better conversation because it is anchored to something real.
Ask: what would you change about this pipeline if it were yours. Good answers are specific and small. Pin the base image with a digest. Split the slow integration stage so it does not gate the fast feedback. Make the cache key include the lockfile hash. Fail the build on the thing that just silently passed.
Bad answers are architectural and unprompted. Replacing the CI system entirely, introducing a new tool, rewriting everything in a different format. Sometimes that is right, and a candidate who proposes it in the first five minutes without knowing the constraints is showing you how they will behave in their first month.
Ask one follow up: what would you not change, and why. Engineers who can defend leaving something ugly alone because it works and is not the problem are rarer than they should be.
You cannot stage any of this in a document. A red build is a fact about a runner, a cache, a network and a set of versions, and every interesting thing about it is in the logs.
In EasyEnv the candidate gets a real environment: a repository, a working runner, and a pipeline broken in the way you chose. They can run the build, read the logs, change things and try again. The session is recorded, so afterwards you review the sequence: did they diff against the last green run, did they change one thing at a time, did they verify the fix by re-running rather than by assertion.
Let them use AI. A model will happily produce a corrected pipeline file, and quite often a plausible one that fixes nothing, because it cannot see the runner. Watching a candidate accept that output unverified is a result. So is watching them use it well, which usually looks like asking the model to explain an error message and then going to check the claim. How to review AI generated code applies directly, and infrastructure code is where unverified suggestions do the most damage.
Four lines on the sheet:
Isolation. Did they narrow to a cause, or apply general remedies?
Evidence. Did they read the log and the diff, or theorise from the file?
Discipline. One change at a time, re-run to verify?
Judgment. Can they say what the pipeline should have caught, and where the gate belongs?
Score independently, compare after. How to write a technical interview rubric has the mechanics.
Do not ask them to write a pipeline from scratch on a blank page. Nobody does this in the job, the answer is always a template, and the template is now generated in four seconds.
Do not test tool trivia. Which YAML key does what in which CI product is documentation, and an engineer who knows one system well will learn yours in a fortnight.
Do not break the pipeline in a way your own team would never hit. The scenarios are only valuable because they are recognisable. Take yesterday's real failure and reproduce it.
What broke your build most recently, and how long did it take somebody to find out why?
Run live coding sessions and take-home challenges in real production environments. Watch sessions back, score consistently, and hire with confidence.
More posts you might like
The best Linux interview question is not a question, it is an SSH prompt on a machine where something is wrong. Here are six scenarios, what each one separates, and how to read the first ninety seconds.
Timed task platforms measure correct code written alone against a clock, which is a real skill and a narrow slice of the job. Here is what a task score can and cannot see, and how to decide whether you need a different kind of assessment.
Read more
Engineering managers should not take coding tests, and most EM loops overcorrect into pure behavioural questions that everyone has rehearsed. Here is a middle path that tests the judgment calls the job actually consists of.
Read more
