Hiring a QA or test engineer
Ninety-five applications for a title that covers two genuinely different jobs, and a market where every CV has learned to imply both.
Everyone writes “manual and automation”. Very few mean it equally. The split between exploratory manual testing and building automated suites is the whole hire, and CVs are written to obscure it because job ads ask for both. Someone who has written a handful of Selenium scripts under supervision will list automation; someone whose entire value is a genuinely sceptical mind and a talent for breaking things will list it too, because they once used Cypress. Underneath that, the most valuable quality in this discipline is close to unmeasurable on paper: a habit of not believing the specification. The classic false positive is a long list of frameworks; the classic false negative is the tester who found the bug that would have cost you a weekend and never thought to write it down.
Which kind of testing is actually missing
Selene separates the two jobs immediately, because a team that needs a safety net and a team that needs a sceptic are hiring differently.
What breaks, and what is already automated
The useful question is what currently goes wrong. A team with no automated tests and frequent regressions needs a builder; a team with a large suite that still ships bugs needs someone who thinks about what the suite does not cover.
One sentence changes the guide
It also names the thing that separates the two populations behind this title. Automation proves the software still does what it did last week. The bug this manager is describing was never in anybody’s test plan, and finding it is an act of imagination that no framework list has ever predicted.
Exceptional, not just good —
“The one who finds the bug nobody wrote a ticket for, because the spec never mentioned it.”
→ Finding an unspecified bug became a must-have; automation-framework breadth dropped to context.
What the guide ends up measuring
Six criteria weighted toward exploratory testing, because that is what this team is missing. On a team drowning in regressions the top two would swap with the automation criteria — same title, near-opposite guide.
No gates — and ISTQB is not one
Nothing here is a yes-or-no fact. The certification usually treated as one, ISTQB, tests vocabulary rather than instinct; it belongs in the scoring as weak evidence at most, and on this role it correlates poorly with the exploratory ability the manager described.
Scored on the bug, not the framework 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.
She reads for described instances of finding something nobody was looking for, which is the only durable evidence of the instinct this role runs on.
How the blind scoring works →What stays with you
Selene's half
- Establishing what actually gets through to production, which decides the whole weighting
- Reading all 95 against the same guide, blind, with the evidence attached
- A ranked shortlist that is not simply ordered by automation tooling
- An interview brief asking each candidate to walk through their best find
Yours
- Getting testers to apply — Selene doesn’t post to job boards or source candidates
- Any testing exercise on your real product, with her brief in hand
- The interview, and the read on whether they enjoy breaking things
- The offer, and every call that matters
Say what gets through
Regressions or surprises — the answer picks one of two opposite guides.