Hiring a DevOps or platform engineer
A small pile — forty-five applicants — and every one of them lists Kubernetes, Terraform, Docker and three clouds. The scarcity makes this role feel easy to screen. It is the opposite.
The tooling list is free. The judgment is not. Infrastructure CVs converge harder than any other engineering discipline, because the tools are a small, well-known set and listing them costs nothing. What separates a strong platform hire is entirely absent from that list: what they did at 3am when the deploy pipeline was down, whether they have ever removed infrastructure rather than adding it, and whether the systems they built could be operated by anyone other than themselves. The classic false positive is the candidate with an immaculate stack list who has only ever worked inside someone else’s platform — and the classic false negative is the person who ran production alone for four years on boring, unfashionable technology.
Who gets paged, and what happens when they do
Selene goes after on-call and blast radius, because those two answers describe the job far better than the stack does.
On-call, scale, and what already exists
For a platform role the useful questions are about consequence, not tooling: what breaks, who currently gets woken, and whether this person is inheriting a platform or building the first one. A greenfield platform hire and a rescue hire are different people.
One sentence changes the guide
It also quietly describes the difference between the two populations in this pile: people who have operated systems and people who have configured them. Both list Terraform. Only one has ever been woken by it.
Exceptional, not just good —
“Someone who has been woken at three in the morning and then changed something so it never happened again.”
→ Incident-plus-durable-fix became the top-weighted criterion; the tooling list stopped being scored.
What the guide ends up measuring
Six criteria, and the tool names appear in exactly one of them. The manager is hiring someone to make a pager quieter, and a guide that ranks on stack keywords would rank almost exactly the wrong way round.
No eligibility gates — but on-call is a fact worth stating
Nothing here is a hard filter. There is one factual thing worth putting on the application page anyway: whether the role carries on-call, and whether it is paid. It is not a gate and Selene will not score it — but candidates self-select on it honestly, and discovering it at offer stage is how a good hire falls through at the last step.
Scored on consequence, not on the stack list
Selene never receives the candidate’s name or the raw CV. She scores a blind, structured profile, with any stated age, sex, nationality and religion stripped out before scoring runs.
What she reads for is what happened when systems failed — a question the tooling list cannot answer, however long it is.
How the blind scoring works →What stays with you
Selene's half
- Working out whether this is a build hire or a rescue hire, and building the criteria accordingly
- Reading all 45 against the same guide, blind, with the evidence attached
- A ranked shortlist that separates operators from configurers
- An interview brief built around the incident each candidate described
Yours
- Getting engineers to apply — Selene doesn’t post to job boards or source candidates
- Any systems-design or troubleshooting exercise, with her brief in hand
- The on-call conversation, which is usually the one that decides it
- The offer, and every call that matters
Nearby roles
Describe what breaks
Who gets paged, and what you want to stop happening — that is enough for a guide that ignores the stack list.