How to hire a QA engineer

Transparency note: Hireo is built by BetterQA, an ISO 27001 certified software testing company in Cluj-Napoca. We hire testers for our own delivery work, which is why this blog exists at all. This is the process, not the theory.

Decide what the role is actually for

Most QA hires go wrong here, before anyone has written an ad. "We need a QA engineer" is a symptom. The useful question is which of these you are buying, because they are different people.

Somebody to test what the team builds. Somebody to build the automation the team does not have. Somebody to own quality as a practice, decide what gets tested and argue with a release date. A strong candidate for the third is often a mediocre fit for the first and will leave within a year.

Write one sentence describing what this person owns, and check that nobody currently owns it. If somebody does, you have a capacity problem rather than a hiring problem, and hiring for it produces two people doing half a job each.

Write the ad for the person you want, not the job title

Job ads for testers are unusually interchangeable. Most list the same tools, the same years, and the same "attention to detail", which selects for people who apply to everything.

Two changes do most of the work. Say what the product is and what is hard about testing it, in a sentence a candidate can react to. Payments with a compliance deadline attracts a different person than a consumer app shipping twice a day, and you want them to self-select.

Then cut the tool list to what the person will genuinely touch in month one. A long list is a filter, but it filters out the wrong people: the strong generalist who has used three of your seven tools reads it and moves on, while somebody who has listed all seven on their CV applies.

Be specific about the automation expectation, because it is the question every candidate has and most ads dodge. If the role is manual with some scripting, say so. There is a good candidate for that role and they are much easier to hire when the ad is honest.

Screening CVs without losing a week

QA roles attract volume, and most of it is genuinely not a fit. The trap is reading carefully from the top, spending your good attention on the first twenty and skimming the rest.

Screen against the one sentence you wrote at the start, not against the CV's quality. A well-formatted CV from somebody who has only done manual regression on a desktop product is a no for an automation role, and a scrappy one from somebody who rebuilt a flaky suite is a yes. The formatting tells you about their last employer's template.

Two signals are worth more than the rest. What they say about a bug they found, if they say anything, and whether their work history shows them staying long enough to live with the consequences of their own test suite. A short stint is rarely long enough to find out whether your tests were any good, because that answer arrives once the suite has aged.

How long should hiring a QA engineer take?

Decide the timetable before you advertise, and expect scheduling to be what stretches it rather than deciding. Book the loop before you need it. If you compress it, be deliberate about which step you are dropping, because the dropped step is usually the one that would have caught a mis-hire.

The cost of being slow is specific here: good testers are usually employed and are rarely running a wide search. A two week gap between your first conversation and your second is long enough for them to stop thinking about you.

Should you set a take-home exercise?

Only if you will read it properly, and only if it is short enough to do on a weeknight. A take-home that eats a weekend selects for candidates who have a free weekend, which is not a quality you are hiring for.

The better version is small and real: here is a feature, tell us what you would test and what you would not. It takes twenty minutes to write and it surfaces judgement rather than diligence. A candidate who explains what they are choosing not to test has told you more than a completed test plan would.

Can you hire a QA engineer if nobody in the team is a tester?

You can, and it is the most common way a QA hire goes wrong. Without somebody who can tell a good answer from a rehearsed one, you will hire on confidence, and confidence is exactly what interview preparation produces.

If that is your situation, borrow a tester for the technical conversation. A contractor, an advisor, somebody from a partner. One hour of their time is cheaper than a year of the wrong hire.

Structure the loop so it produces a decision

Three conversations is usually right: a screening call, a technical conversation, and a session with whoever the person will actually work beside.

Give each one a distinct question. The screen answers whether the role matches what they want. The technical conversation answers whether they reason about risk, which is a different thing from whether they know your tools, and our QA interview questions go into how to draw that out. The third answers whether the team wants to argue about a release date with this person.

What ruins a loop is asking all three the same thing. If every interviewer opens with "walk me through your background", you have spent three hours gathering one hour of information, and the candidate has noticed.

Deciding, and the reference call people skip

Decide from evidence, not from an average. A candidate who was outstanding in one conversation and ordinary in two is usually a better hire than one who was fine in all three, because "fine everywhere" is what rehearsal produces.

Then make the reference call, which almost everyone skips because it feels like a formality with a predetermined answer. Ask one question that is hard to answer with a platitude: what did this person need from a manager in order to do their best work? You get something specific, and it is useful whether you hire them or not.

The first month is part of the hire

A QA hire can fail in the first month, and when it does the cause is usually the same: they arrive, find no clear first thing to own, and spend the time reading instead.

Have a first bug, a first area, and a named person to ask. The fastest signal that you hired well is somebody finding something real in week two, and that only happens if they were pointed somewhere.

If you are choosing between hiring and bringing in a testing partner while you search, we wrote a comparison of the two paths, and our own software testing services are the second option, so read it knowing that.

What this looks like in Hireo

The parts of this that are dull and easy to get wrong are the parts to automate: screening against the sentence you wrote, keeping the loop's notes in one place so the second interviewer starts where the first stopped, and not letting a strong candidate sit for a week because nobody scheduled.

That is most of what Hireo does. It does not decide for you, and a tool that claimed to would be selling you the part of this that is actually judgement.