Hiring a backend engineer
A modest pile of applicants, all fluent in the same vocabulary, and a CV format that rewards listing technologies over having run any of them properly. The screening problem here is not volume — it is telling depth from surface.
The longest technology list is usually the weakest signal. A backend CV is a keyword surface: twelve languages, six databases, four queues, three clouds. None of it says whether they designed the thing or inherited it, whether it survived contact with real traffic, or what they did the week it fell over. And the format actively penalises the strongest candidates — someone who spent four years going deep on one system looks narrow next to someone who touched twenty and understood none, because the second CV is simply longer.
From a stack to a guide, in one conversation
Selene goes after the stack and the scale it runs at — but the answers that change the guide are about ownership and traffic, not language choice.
The stack, the scale, and who owns what breaks
For an engineering role Selene asks about the tech stack and the scale it runs at. That is a genuinely different conversation from a frontline role: not shift patterns and volume, but request rates, data size, and whether this person joins a team or becomes the team.
One sentence changes the guide
This is the answer that most changes a backend guide, and almost nobody puts it in a job description. It reverses the default: instead of rewarding the widest surface area, the guide starts rewarding restraint — which is the thing that actually predicts a codebase you can still work in three years later.
Exceptional, not just good —
“Someone who can explain why they didn't build the clever thing.”
→ Trade-off reasoning became a must-have; breadth of technologies stopped being scored at all.
What the guide ends up measuring
Five criteria — deliberately fewer than most guides here. Note what is absent: no list of languages to tick off, and no mentoring line, because the manager said he wants a builder rather than a lead. The stack is context Selene already has; the criteria are about what someone did inside it.
No certifications, no licences, nothing to gate on
Nothing here is a yes-or-no fact, which makes this the opposite of a driving or care role: there is no question that can filter the pile before scoring. Every applicant has to be read properly, and the entire job is separating a deep three years from a shallow ten. That is precisely where a consistent, evidence-backed guide beats a tired human on their fortieth CV.
Scored on what they did, not what they listed
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.
Each criterion comes back with the evidence found, what could not be confirmed, and how sure she is about the difference — which matters most on the trade-off criterion, where a confident CV and a deep one read alike.
How the blind scoring works →What stays with you
Selene's half
- Working out what this backend role actually turns on, and building the criteria from your answers
- Reading all 60 against the same guide, blind, with the evidence attached
- Ranking them, with the trade-off evidence quoted for each
- An interview brief that probes what she couldn't confirm — like that data-modelling gap
Yours
- Getting engineers to apply — Selene doesn't post to job boards or source candidates
- Any code exercise, take-home or repo review; she reads what people wrote about their work
- The technical interview itself, with her brief in hand
- The offer, the level, and every call that matters
Brief her on your stack, once
First hire or fifteenth, greenfield or a decade of someone else's decisions — the guide comes out different for each.