Skills assessment
QA Engineer skills assessment
The fastest way to make a bad QA hire is to screen for what is easiest to count: years of Selenium, number of test cases authored, certification acronyms. None of it predicts whether someone can look at a half-built feature, work out where it will break, and get a team to care before customers do. And in 2026 a candidate can generate a plausible test suite in minutes, so "wrote 2,000 automated tests" on a résumé tells you almost nothing about their judgement.
A good assessment measures that judgement directly: risk-based prioritisation under a deadline, structured exploration that surfaces the bug two menus deep, and the discipline to know what not to automate. It values test strategy over test-case counting. H-Evaluate generates the exercise from your job description — quality-gated, per-job generation rather than a static shared library — so the buggy-feature task a candidate faces maps to the release problems your team actually has and cannot be scraped from a forum beforehand.
What to assess
The competencies that predict performance in this role, mapped to the five hiring pillars.
Exploratory testing in a live task
Investigating a deliberately buggy feature against its spec — forming hypotheses, chasing a surprising result, and filing the bug reports that matter, not re-verifying the happy path.
Test strategy & risk depth
Reasoning about what to test first, at which level, and what to consciously leave untested — money-touching flows, new code paths, cross-team integrations — at the seniority you are hiring for.
Automation judgement
Treating automation as a bet with a maintenance cost — deciding what not to automate as deliberately as what to automate, and reasoning about where the suite would rot faster than it pays back.
Prioritisation under a deadline
How a candidate handles a release that normally gets two weeks and now gets two days — walking through explicit trade-offs, not promising to test everything.
Quality advocacy
Writing a bug report that reproduces cleanly, quantifies user impact, and makes the fix decision easy — influence without the authority to block a release.
AI fluency
Generating tests with an AI assistant and then critiquing them — spotting happy-path bias, change-detector assertions, and hallucinated coverage rather than trusting a green run.
How to structure the assessment
- 1Give candidates a deliberately buggy feature and its spec, and ask for a one-page test plan plus their three best bug reports.
- 2The three-report limit is the point — it forces prioritisation between a data-loss bug and three cosmetic misalignments.
- 3Run it in a sandbox so every candidate gets the same environment and you can review the process log, not just the final artifact.
- 4Include a generate-then-critique step: have them produce tests with an AI assistant, then find the missing negatives and the assertions that codify bugs.
- 5Score against an anchored rubric written before the first candidate, weighting the same questions to the seniority you are hiring for.
Signals that predict success
- +Prioritises the data-loss and payment-edge bugs over cosmetic ones
- +Pulls on a surprising result — narrowing conditions, checking if it generalises
- +Names what they would deliberately not automate, and why
- +Treats AI-generated tests as a draft to edit, deleting assertions that lock in bugs
Red flags to watch for
- –Measures themselves in test-case counts or coverage percentages without risk context
- –Claims to automate everything, with no sense of the maintenance bet
- –Cannot describe a memorable bug found through exploration
- –Accepts an AI-generated suite because it runs green
Assessment vs. interview
A pleasant interview reveals little about how someone investigates a half-built feature or prioritises a release under a hard deadline. A sandboxed work sample shows it directly: which bugs they find and in what order, whether they surface the data-loss case or three cosmetic ones, and whether they treat an AI-generated suite as a draft or a deliverable. Use the process log as the evidence, then interview for advocacy and how they influence engineering without owning the roadmap.
Skills assessment
Configure this assessment by role and seniority
Watch the emphasis shift in real time as you change the role and level — no signup.
Related reading
How to Hire a QA Engineer: Test Strategy Over Test Counts
How to hire a QA engineer in 2026: screen for test strategy and automation judgement with work samples, structured interviews, and AI-fluency checks.
Work Sample Tests: The Most Predictive Way to Hire
Work sample tests measure what a candidate can actually do and predict job performance better than résumés or interviews. How to design and score them well.
Structured Interviews: A Guide to Fairer Hiring
Structured interviews are among the strongest predictors in hiring. This guide covers what makes an interview structured and how to build, score and run one.
Frequently asked questions
How do you assess a QA engineer?
Use a work sample that mirrors the job: give candidates a deliberately buggy feature and its spec, then ask for a one-page test plan and their three best bug reports in about 90 minutes. The three-report limit forces prioritisation, the plan reveals strategy, and the reports reveal advocacy. Run it in a sandbox so every candidate gets the same environment and you review process, not just output.
What skills should a QA engineer assessment cover?
Prioritise four capabilities: test strategy (risk-based prioritisation under time pressure), automation judgement (knowing what not to automate as much as what to automate), exploratory testing skill (structured investigation that surfaces non-obvious bugs), and quality advocacy (bug reports that change team behaviour). Tool experience matters less — frameworks change, but the ability to reason about risk transfers across every stack.
Should a QA assessment require coding?
It depends on the variant. An SDET builds test infrastructure and needs genuine software-engineering skill; a hybrid QA engineer needs enough scripting to maintain automated regression tests; a manual-first analyst or quality coach can be highly effective with light scripting. Match the assessment to the role you actually need, rather than defaulting to 'must code' and filtering out the exploratory testers your team may need more.
How do you assess a QA engineer's AI fluency?
Have them generate tests with an AI assistant against a spec, then critique the output. Strong candidates name the characteristic failure modes — happy-path bias, change-detector tests that lock in buggy behaviour, hallucinated coverage that asserts nothing, and missing domain oracles — and treat generation as a draft to edit. Candidates who accept the output because it runs green are demonstrating the opposite of fluency.