QA Engineer Interview Questions and Scorecard

The first time I sat across from a QA candidate, I had no idea how to grade the answers. I could tell that the person in front of me knew more testing vocabulary than I did, and that was the entire problem: I was interviewing for a skill I did not have, using questions I had copied off the internet an hour earlier. The hire worked out, but by luck rather than by process.

Most small companies hire their first tester exactly this way. There is no QA lead to run the loop, no test suite to compare a candidate against, and the person conducting the interview is the founder or an engineering manager with a full plate. At FirstHR, we build for that situation, so these six question sets are written for the interviewer, not the candidate.

Each set covers a different slice of the role: a core set for every candidate, manual test design, automation and continuous integration, a bug report work sample, a founder screen for interviewers who cannot read test code, and a scoring rubric with a seniority guide and red flags.

What You Are Actually Interviewing For

You are interviewing for four behaviors: deciding what to test, finding the problems, writing them up so a developer can fix them, and protecting the next release from repeating the same failures. The title covers a wide range, from a manual tester running checks by hand to an automation engineer building test suites that run on every code change.

That range matters for the interview, because the two profiles need different questions. Federal data groups the occupation with software developers: the Bureau of Labor Statistics projects employment for software developers, quality assurance analysts, and testers to grow 15 percent from 2024 to 2034, with about 129,200 openings a year on average. Write the role down before you interview. If you have not, the QA engineer job description templates split the role into manual, automation, lead, and junior versions, and picking one of those first makes the interview far easier to run.

Which Question Set Should You Use?

Pick the set that matches the role and your own comfort with testing. Every candidate gets the core set, and you add one specialty set on top. If you cannot evaluate test code yourself, add the founder screen and the bug exercise instead of guessing at technical depth.

6 Free QA Question Sets to Download

Download all six as a single Word document or copy individual sets. Each follows the same structure: when to use it, the questions with notes on what a good answer sounds like, a what-to-listen-for block, and a quick score at the end. Fill in the candidate details and use them as they are.

Set 1: Core QA Engineer Questions

The starting set for every QA candidate, manual or automation, junior or senior: test thinking, the bug life cycle, risk prioritization, and what they do when a developer disputes a bug. Start here.

Set 2: Manual QA and Test Design Questions

For a hands-on tester: designing test cases on the spot, boundary values, exploratory versus scripted testing, cross-browser coverage, and working from thin requirements that were never written down anywhere.

Set 3: QA Automation and SDET Questions

For an engineer who writes test code: frameworks and why they chose them, the test pyramid, flaky tests, continuous integration, API testing, and a realistic first-90-days plan for a codebase with zero tests.

Set 4: Bug Report Writing Exercise

A 20-minute work sample with a candidate brief and a grading checklist. This is the single most useful stage in a QA interview, and you can grade it fairly without any testing expertise of your own.

Set 5: Founder Screen, Culture and Judgment

Situational and culture questions for an owner or manager who cannot evaluate test code: release pressure, disagreeing with engineering, admitting a miss, and explaining technical work in plain language.

Set 6: Scoring Rubric, Seniority Guide, and Red Flags

A six-area scorecard, a guide to what junior, mid, and senior candidates should sound like, and a red-flag checklist, so you compare candidates on evidence instead of on which conversation felt best.

Judging QA Skill Without Reading Test Code

You do not need testing expertise to run a good QA interview; you need to grade the things a non-expert can see. Judgment, reproducibility, ownership, and communication are all visible to anyone paying attention, and they predict performance better than a memorized definition of black-box testing.

Three moves carry most of the weight. Ask the candidate to rank what they would test first on your actual product and explain the reasoning. Have them write up two real bugs after a short hands-on session, then grade the write-ups against a checklist. Ask them to explain a technical problem to you in plain words, which doubles as a preview of the working relationship. If the role involves automated tests, ask one engineer or a trusted contractor to review a code sample separately, on its own, rather than trying to fake technical depth in the room.

Manual and Automation Ask Different Things

Manual QA and automation are related but distinct hires, and interviewing them with the same questions is the most common mistake I see. Both need test design and risk thinking. Only one needs to write maintainable code, run a continuous integration pipeline, and live with the maintenance cost of a suite.

The practical rule for a small company: hire manual first unless you already have a product stable enough that repeating the same checks is wasting real hours. A first automation hire who arrives before the product has settled will spend months rewriting tests against a moving target. If you are hiring both a tester and developers, the software engineer job description templates help you keep the two roles distinct on paper.

The Bug Report Exercise

Give every QA candidate the same short work sample: 20 minutes on a named area of your real product on a test account, then two written bug reports you could hand straight to a developer. Nothing else in the interview tells you as much, and you can grade it without knowing how to test.

Keep it fair and keep it short. Use a test environment and a test account, never live customer data. Give every candidate for the role the identical brief and the identical time limit, pay for anything longer than 30 minutes, and grade the artifact rather than the person. Run it after a phone screen so you are not asking unqualified candidates to spend time on it.

Red Flags in a QA Interview

The most reliable warning sign is vagueness about their own work: a candidate who cannot describe one specific bug they found, in detail, has usually watched a QA process rather than run one. The second is overclaiming, because nobody tests everything and a candidate who says they never miss anything is not being straight with you about tradeoffs.

Two more worth watching: no questions for you about the product or its users, and a bug report from the exercise that you cannot reproduce from the steps given. None of these disqualifies a candidate on its own, but two or three together are a pattern. Balance the negatives against evidence, and treat a reference check as the place to confirm anything that felt off rather than as a formality.

Scoring the Interview

Fill in the scorecard within an hour of each interview, while it is fresh, and anchor every rating to something the candidate actually said or did. Score six areas from 1 to 5 for every candidate for the role, then compare the numbers rather than your memory of which conversation felt best.

If more than one person interviews, each should score independently before comparing, so the loudest opinion in the debrief does not set the tone. The same questions plus the same rubric for every candidate is the core of a structured interview, and the completed scores make the interview feedback step fast and specific.

A reusable interview evaluation form keeps the format consistent across every role you hire for. That consistency matters more than it sounds once you are comparing a candidate you met on Monday against one you met three weeks earlier.

QA Engineer Pay and Classification

QA pay varies enormously by specialty, seniority, and metro market, so start from federal survey data and adjust from there. The occupation spans junior manual testers and senior automation engineers, which is why the published range is so wide.

Budget toward the lower half for a first manual QA hire in a lower-cost market and toward the upper half for an automation engineer building your test infrastructure from nothing. Add employer payroll taxes, benefits, and equipment on top of base pay when you compare an employee against a contractor arrangement, and read the employee versus contractor rules before you decide.

Classification matters here too. The Fair Labor Standards Act computer employee exemption can cover skilled workers whose primary duty includes the design, development, documentation, analysis, creation, testing, or modification of computer systems or programs, when they are paid on a salary or fee basis at not less than $684 per week or hourly at not less than $27.63 an hour. A senior automation engineer often fits; a manual tester executing cases someone else wrote may not. Job titles do not decide it, and the exempt versus non-exempt analysis turns on actual duties. State rules can be stricter. This is general information, not legal advice.

Hiring QA at a Small Business

A large company hires testers through a QA lead who already knows what good looks like. A small business hires through a founder who does not, and that difference drives most of the avoidable mistakes. Here is how the constraint actually plays out, and what to do about each part of it. Applicant tracking is coming soon to FirstHR, so for now a shared folder and a consistent scorecard will carry the process.

One more thing worth planning: this hire will probably be alone. Ask directly how they would work without a QA lead, and listen for someone who sets their own priorities and reports risk upward rather than waiting for instructions. Mixing in a few situational interview questions is the fastest way to surface that, since the answers are about judgment rather than recall.

From Interview to Onboarding

The interview is step one. A QA hire needs access to environments, a bug tracker, source control, and staging accounts before the first morning, plus a signed offer and a confidentiality agreement covering the product internals they are about to see. Set the first real test assignment before they arrive.

Alongside that, the standard I-9, W-4, and the rest of the new hire paperwork still have to be collected and stored properly, and a busy first week is exactly when a form goes missing.

An onboarding template keeps the sequence consistent so nothing gets skipped. It also gives the new tester a predictable first few days instead of a laptop, a pile of forms, and a vague instruction to start looking around.

FirstHR connects the offer, the confidentiality agreement, e-signatures, the new-hire documents, and the access-and-policy checklist in one place, so a small business can onboard a QA engineer without a dedicated HR person tracking it all by hand. FirstHR is an onboarding and HR platform, not a payroll provider, so pair it with your payroll system. Applicant tracking is coming soon to FirstHR.

Frequently Asked Questions