How to Hire a QA Engineer: Testing Talent Acquisition Guide

Hiring a QA engineer starts with one question most teams skip. Which QA engineer? The title covers at least three distinct roles in 2026, the salary bands barely overlap at the senior level, and the wrong match on day one is why a majority of QA searches stall at week four. The process below walks through the decision, the job description, the screen, and the offer in the order they actually happen, with real timelines from the placements we’ve closed over the last eighteen months.

Tom Kenaley, KORE1. I run technical searches across our software engineer staffing practice, and QA is one of the roles where the gap between the JD and the actual work causes more failed searches than almost any other tech title I recruit for. We benefit commercially when you hire through us. Take that into account. Most of what’s below applies whether you search yourself or bring in an agency to run the search for you.

Decide Which QA Role You Actually Need First

“QA engineer” on LinkedIn is a grab-bag. Same two words. Three fundamentally different jobs. If you don’t sort this out before the JD goes up, everything downstream gets expensive.

For the full comp breakdown by experience and geography, the QA Engineer Salary Guide has percentile tables and aggregator variance data. This post focuses on the hire itself.

The way to sort the decision is not company size. It comes down to three things, and they have to be answered in order before the JD is written. What does your current release cycle look like? Who is doing QA today? What does the failure mode look like when a bug reaches production, and how long does that bug typically stay in production before anyone notices it was a bug in the first place?

If engineers are writing their own integration tests and you need more exploratory coverage before release, a manual QA fits. If your test suite exists but breaks constantly and nobody on the dev team wants to own it, you need an automation engineer. If you’re building testing infrastructure from scratch, or your QA function needs to scale across multiple services, that’s an SDET search. I’ve watched more than one client post an automation req, interview candidates for six weeks, and then realize during intake that what they actually wanted was an SDET. Rewrite the JD. Lose the pipeline. Start over.

The Intake Call That Saves You Six Weeks

Every QA search we close starts with 45 minutes between a KORE1 recruiter and the hiring manager. Most of the searches that stall out skipped that conversation on the client side too. The hiring manager’s assumptions about “what kind of QA person we need” are almost never tested before the JD ships, and by the time the pipeline is cold, the JD is already public and changing it costs real time.

Six questions to answer before you post.

• Who writes tests today, and what percentage of the codebase has coverage? “Nobody writes tests” and “our devs write unit tests but nothing end-to-end” produce very different hires.
• What’s the framework actually in use? Playwright, Cypress, and Selenium are not interchangeable on a resume. According to 2026 market data, Playwright adoption sits around 45% among QA teams while Selenium has dropped to about 22%, and Playwright job postings were up 180% year over year in 2025.
• How long is the release cycle, and does QA block the release? Two-week sprints with QA as a release gate is a different job than continuous deployment with tests running on every PR.
• Is there a CI pipeline today? If tests don’t run automatically yet, your first QA hire will spend a chunk of the first quarter setting that up, and the JD needs to say so.
• What does the bug reporting workflow actually look like? Jira plus Slack plus a shared doc is fine. Nothing formal is a signal you need someone with process muscle, not just test muscle.
• What does “done” mean for a feature on your team? If nobody can answer in a sentence, QA can’t enforce it.

Last November a SaaS client came to us with a “QA engineer” req at $88K base. The job description asked for Playwright, CI pipeline experience, container basics, and TypeScript proficiency. I did the intake call. That was an SDET JD, not a QA engineer one. The client’s last QA hire had been a manual tester at $72K three years earlier, and nobody on the engineering team had revisited the comp assumption when the skill requirements got updated for the new role. We rewrote the JD for $125K, got four finalists through a two-week take-home in eleven working days, and closed the role at $128K. Had they posted the original, the pipeline would have been full of manual testers who couldn’t do the work, the hiring manager would have blamed the candidate pool, and the search would have died at week six.

Write a Job Description That Filters Rather Than Just Describes

Most QA job descriptions are interchangeable. “Strong attention to detail.” “Experience with automated testing frameworks.” “Ability to work in an Agile environment.” That text does no filtering. It attracts everyone and screens for nothing.

The JDs that actually produce a usable pipeline do three things.

They name the stack. “Experience with Playwright in TypeScript, running against a React frontend and a Node/Express backend in AWS ECS.” That single sentence cuts the applicant pool in half. Candidates who don’t know the stack self-select out. The ones who apply can speak to it in the first ten minutes of the screen.

They state the scope. Not “maintains test suites” but “you will own the end-to-end test suite for our billing module, currently 340 Playwright tests with about a 4% flake rate. Reducing flakiness and expanding coverage for new billing features is your first 90 days.” A candidate reading that knows what they’re walking into. So do you.

They admit what’s broken. If the current test setup is a mess, say so. “Our CI pipeline runs tests in serial and takes 47 minutes. We need someone who can parallelize it.” The right candidate leans in when they read that line. The wrong candidate self-selects out. Either outcome saves you a screen.

What to cut from the JD entirely. Nice-to-have certifications, ISTQB is fine if present but nobody should care if it isn’t. “Passion for quality” language. Bullets about cross-functional collaboration that every job in software already implies. They signal nothing except that an HR template was used without edits.

Where to Source QA Candidates

Three channels. Each one has a different cost curve and a different candidate profile.

Internal referrals. Free, and the quality signal is stronger than most teams give it credit for. Ask your engineering team who they worked with at their last company. Post in the engineering Slack. The problem is yield. Most teams get two or three real names back, and if those names don’t convert, you’ve burned a month on channel one.

Direct sourcing. LinkedIn Recruiter, Hired, Wellfound. You or your internal recruiter message candidates cold. Response rates on QA cold outreach currently sit around 12 to 18 percent depending on stack. Selenium candidates respond at higher rates than Playwright candidates, because the Playwright market is hot and those engineers are already fielding three to five recruiter messages a week.

Staffing agency or contract-to-hire. What we do. You pay a fee. We run a targeted search out of our existing network, and candidates usually arrive pre-screened against your stack. The tradeoff is cost. A contingent fee on a $130K SDET is real money. When it makes sense: you’ve run channels one and two for a month and the pipeline is empty, the role is time-critical, or the stack is narrow enough that your internal recruiter doesn’t have a warm list to work from.

For QA specifically, we see the best outcomes when clients run two channels in parallel. Internal referrals plus a specialized agency. Direct sourcing alone tends to produce manual QA candidates even when the JD asks for automation, because the manual market is larger and cold outreach self-selects for responsiveness rather than stack fit.

The Technical Screen That Actually Works for QA

Algorithm interviews on a whiteboard tell you nothing about QA ability. A 30-minute conversation about testing philosophy tells you slightly less. What works, for every QA tier, is a short take-home grounded in the actual stack. Not eight hours. Not a full project. Ninety minutes of focused work that mirrors day-one reality.

For an automation engineer or SDET, my preferred screen looks like this. Send them a repository with one working test suite and one flaky test. The flaky test is real. Pulled from a real codebase. It fails maybe one in five runs because of a race condition between a DOM update and an assertion. Ask the candidate to debug it, fix it, and write a short note on the root cause. Ninety minutes. That’s the whole screen.

What you learn from that.

• Can they read an existing codebase without panicking? Most manual testers mis-applying for automation roles fall out here.
• Do they understand the difference between a test that’s flaky because the code is slow versus flaky because the assertion is wrong? The stronger candidates explain this unprompted.
• What does their commit history look like. Small commits with clear messages. Or one big “Fixed it” commit after four hours of struggling in silence.
• Do they write a test for the fix? This is the signal I weight most. SDETs write the test. Automation engineers sometimes write the test. Manual QA almost never writes the test.

We ran this exact screen on 47 candidates for a client last quarter. 31 declined to do it. 16 did it. 4 reached final rounds. One got the offer. That’s about a 2% conversion rate from top of funnel, and it’s about right for a specialized SDET search. A JD-as-filter plus take-home-as-filter beats a 40-minute video call on every QA loop we’ve run this process on.

For a manual QA role, the screen looks different. Give the candidate your product for 45 minutes. Ask them to find three bugs. Then ask them to file those bugs in the format your team already uses. How they write the bug report matters more than which bugs they found. Clear repro steps. Expected versus actual. Severity assessment that matches the business impact. That’s the job.

The Interview Loop That Doesn’t Burn Out Your Team

After the take-home, the on-site loop should be focused. Four interviews. No more. Five is overkill and you lose candidates to scheduling fatigue before they ever meet the hiring manager.

1. Recruiter screen, 30 minutes. Covers comp, timing, basic stack match.
2. Hiring manager conversation, 45 minutes, walking through the candidate’s take-home. This is the most important round in the loop.
3. Technical peer, 60 minutes. A senior engineer the candidate will work with on day one. Covers debugging approach, testing philosophy, a live code review of a PR the engineer picks.
4. Cross-functional, 45 minutes. A product manager or tech lead from an adjacent team. Covers how the candidate communicates about bugs to non-engineers, which is QA-specific and gets skipped constantly.

Skip the standalone culture interview. Everyone says “culture fit” and nobody agrees on what it means. If you’re evaluating communication and collaboration, put those questions in the cross-functional round where they actually belong. Our technical interview guide for hiring managers covers the structure in more depth if you’re setting up this loop from scratch.

Salary, Offer, and Realistic Timeline

The median base for software quality assurance analysts and testers was $102,610 in May 2024, according to the Bureau of Labor Statistics. That’s a national median that blends the three roles in our table above, so it’s a useful floor but not a useful benchmark for any specific hire. The QA engineer salary guide breaks the number down by role and experience.

Search timelines on our desk look like this.

Offer specifics matter more for QA than for a lot of other roles because the comp bands overlap at the edges. A senior automation engineer at $140K and a junior SDET at $140K are competing for the same market. What breaks the tie is often the tech stack and the team. A candidate who has been on a Selenium legacy codebase for three years will take a small comp step down to work on Playwright. An engineer moving from SDET into product engineering will sometimes take the same offer to get off the QA ladder entirely. Ask what’s motivating the move, not just what they’re looking for.

When Contract-to-Hire Works Best for QA

Contract-to-hire gets recommended too often in other contexts. For QA, there’s a real case for it. The skill match is hard to evaluate from a resume alone, the stack variance across teams is wide, and a 90-day contract gives both sides room to see whether the fit is real. If you’re hiring QA for the first time as an organization, a contract-to-hire via a contract staffing partner lets you adjust the role shape without the cost of a failed direct hire landing on your comp budget.

C2H isn’t automatic, though. If you’ve already hired QA successfully a couple of times and know the exact shape of the role, direct hire staffing tends to be faster and cheaper on a per-seat basis because you skip the bill-rate premium that contract carries. The right answer comes down to whether the shape of the role is settled, not whether the candidate in front of you looks strong on paper.

The Mistakes We See Most Often

Five hiring mistakes show up over and over in QA searches. Each one has cost a client at least four weeks.

1. Posting a JD that matches one of the three QA roles while budgeting for a different one. Most common pattern. SDET JD, automation comp.
2. Running a take-home that has nothing to do with the actual stack. Asking a Playwright candidate to write a Selenium test, for instance. You filter on the wrong signal.
3. Skipping the hiring manager walk-through of the take-home. If the hiring manager only sees the written output, they miss roughly 70% of what the candidate’s thought process looks like.
4. Evaluating certifications over portfolio. An ISTQB cert tells you someone studied. A GitHub with actual test code tells you what they can do. Weight the second.
5. Dragging the process past 30 days for manual QA or past 45 days for automation. The candidates you want have other offers already. Slow is the same as no.

Questions Hiring Managers Ask Us

Do we actually need an SDET, or is an automation engineer enough?

Depends on whether you’re hiring into an existing test framework or building one. Into an existing framework, an automation engineer who can write and maintain tests is enough. Building one from scratch, or scaling tests across services, is SDET work. Ask yourself what your first QA hire’s first sprint looks like. If the answer involves writing framework code, budget for an SDET.

How long should the take-home actually take?

Ninety minutes. More than that and you’re selecting for candidates with nothing going on in their personal life, which is not the filter you want. Less than that and the signal gets noisy. Tell the candidate up front you expect 90 minutes and to stop if they hit two hours. Evaluate what they did in the time they had, not what they might have produced with unlimited hours on a weekend.

Is ISTQB certification worth requiring?

Not really. It’s not a negative signal, but requiring it screens out plenty of strong candidates who learned QA on the job. Treat it the way you’d treat a Scrum certification. Nice if it’s there. Not a gate.

Should QA report to engineering or to product?

Engineering, in most cases. When QA reports to product, the role becomes about shipping acceptance tests, which is a narrower job. When QA reports to engineering, the role can own test infrastructure, CI stability, and debugging workflows. The second shape is where the value compounds over a year. Exceptions exist for regulated industries where audit trails drive the reporting structure.

Can one QA engineer cover a whole product team?

For a small team, usually. One SDET can support a product team of 6 to 10 engineers if the engineers are writing their own unit and integration tests. Past that, you need either a second QA or a restructure where QA is horizontal across multiple product teams. Ratio matters less than what the engineers are willing to own themselves on the testing side.

What’s the real difference between a tester and an SDET?

An SDET writes code that would pass a software engineering interview at the same company. A tester checks that the code works. Both are valuable. They are not interchangeable, and paying SDET comp for a tester is the most common hiring mistake I see in this space. The reverse also happens. It’s just less common.

Before You Post the Req

Most of the cost in a QA search happens before the job posting goes live. The wrong JD, the wrong comp band, the wrong screening plan, and the search is already in trouble on day one. The hiring managers who close their QA searches on time are the ones who spend an hour on the decision before they spend six weeks on the pipeline.

Want a second set of eyes on which of the three QA roles actually fits the team you’re building, or want to skip the first six weeks and go straight to a pre-screened shortlist of Playwright, Cypress, or SDET candidates who already know your stack? Talk to our team. For the broader hiring context, our guide on how to build a software development team from scratch walks through where QA fits alongside backend, frontend, DevOps, and product roles on a full engineering roster.