By the time a team hires its first DevOps engineer, the infrastructure already exists. It was built by whichever backend engineer was least unwilling, over two years, under deadline, and it works.
It also has a staging environment that diverged in March, a deploy script with a comment saying "do not run twice", one machine nobody will touch because the person who set it up has left, and secrets in three different places for reasons that each made sense at the time.
That is the job. Not building a platform: inheriting one, keeping it up, and improving it in an order that does not break the company. Interviewing for the first version of this role as though it were a platform engineering role at a larger company is the standard mistake, and it produces a hire who spends month one proposing a rewrite.
Archaeology. Reading a system nobody documented and forming a correct model of it, largely from the artifacts: the Terraform that half matches reality, the CI config, the one Slack thread where the decision was made.
Triage under incomplete information. Ten things are wrong. Two of them will cause an outage this quarter, six are cosmetic, and two look urgent and are not. Choosing correctly is most of the value the hire delivers in the first six months.
Working without a platform team to escalate to. No SRE rota, no internal tooling group, no runbook. When something breaks at 3am, they are the escalation path.
Being persuasive with engineers who own the mess. They cannot mandate anything. Every improvement is a negotiation with the person who wrote the thing, who is busy and slightly defensive about it.
Notice that only one of these is technical in the way a tool-list interview measures.
"Kubernetes, Terraform, AWS, ArgoCD, Prometheus" tells you what somebody has been near. At a larger company, being near Kubernetes can mean owning it or filing tickets against the team that owns it, and both look identical on a CV.
The stronger candidates for a first hire are frequently the ones with a shorter tool list and deeper marks on it. Someone who has run one boring stack, been paged for it, and fixed the causes will outperform someone who has been adjacent to a fashionable one. The tool list actively inverts this, because breadth reads as seniority.
There is a second failure. Ask about tools and you select for people who like new tools, and the first infrastructure hire has enormous latitude to introduce them. That is how a twelve-person company acquires a service mesh.
Each of these runs on a real environment, because every one depends on the candidate meeting a system they did not build.
1. Inherit and describe. Give them access to a small running system: a couple of services, a database, some Terraform that does not entirely match what is deployed. Twenty-five minutes. Ask them to tell you how it works and what worries them.
What you learn: this is the single highest-signal exercise for this role. Watch whether they read the infrastructure code or the running state first, whether they notice the drift, and crucially what they flag. A candidate who leads with "there is no backup on this database" and one who leads with "this should be on Kubernetes" are telling you exactly how their first quarter goes.
2. The 3am page. A service is down, there is a dashboard, there is log access, nothing else. No runbook, on purpose.
What you learn: whether they restore service before understanding it. The correct instinct at 3am is stop the bleeding first, understand second, and plenty of otherwise strong engineers get this backwards under observation because they want to demonstrate depth. Say explicitly that customers are affected, then watch. The live incident drill goes deeper on this format.
3. The dangerous plan. Hand them a terraform plan output that includes a destroy on something that matters, buried in forty lines of harmless changes.
What you learn: whether they read plans or scroll them. This is a small exercise with an unusually clean pass/fail, and it correlates with the thing you most need, which is somebody who does not cause the outage themselves. See anyone can write Terraform for the longer version.
4. Order the list. Give them ten real problems from a startup's infrastructure: no backups tested, secrets in the repo, no staging parity, manual deploys, no monitoring on the queue, an unpatched box, and so on. Ask what they do first, second, third, and what they deliberately leave alone for a year.
What you learn: judgment, and the willingness to leave things alone. Anyone can list what is wrong. The hire you want can say "the secrets in the repo look worst and the untested backup will actually kill us, so backups first", and can say which two items they would not touch until the team is bigger.
All four need a live system. A candidate cannot notice Terraform drift in a conversation about Terraform drift, and cannot restore a service in a discussion about incident response.
In EasyEnv the candidate gets a real environment with the mess already in it: the drifted state, the failing service, the plan with the destroy in it. The session is recorded, which matters here more than in most roles, because what you are assessing is the order of operations. Whether somebody checked the disk before restarting the process, whether they read the plan before approving it, whether they looked for a backup before touching the database. Those are sequences, and a summary of the outcome loses exactly the information you needed.
It also means you can hand the recording to the backend engineer who built the system and get a second opinion from the person who knows where the bodies are.
Warning: everything is a rewrite. A candidate who responds to every scenario with the target architecture rather than the next step will spend six months building a platform while the untested backup sits there.
Warning: no opinion about what to leave alone. The first hire has to under-build deliberately. Somebody who cannot name something they would tolerate has not worked at this scale.
Good: asks who is on call now. The candidates who ask this early are the ones who understand they are inheriting an operational reality and not a green field. It is a small question and it predicts well.
How to scale technical hiring from 5 to 50 engineers covers what happens after this hire works out.
If someone joined on Monday, what is the first thing about your infrastructure you would be embarrassed to explain?
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
Time to hire is mostly waiting, not interviewing. Here is where the days actually go, which ones you can remove without lowering the bar, and the two changes that cut the most.
The Go language is easy to read and hard to run in production. Here is what a Go developer assessment should actually test, four scenarios that separate people who have shipped Go from people who have written it, and why a syntax-shaped test tells you nothing.
Read more
What HackerRank proctoring actually detects, what it structurally cannot, what it costs you in candidates who were never cheating, and the design change that makes the question mostly go away.
Read more
