Why pre-screen QA engineers before the technical panel interview
A ten minute screen saves your engineering panel from candidates whose resumes cannot be read at face value. QA applicants arrive from bootcamps, manual testing outsourcing shops, support teams moving sideways, and genuine SDET backgrounds, and every one of those resumes lists Selenium, Jira, and Postman. What a resume cannot show is whether they wrote the framework or inherited it, whether they can read the application code, and how they behave when a developer says the bug is not worth fixing before Friday's release.
What actually matters when screening Quality Assurance (QA) Engineer candidates
- 01
Technical proficiency
Probe testing depth: automation frameworks they built, and whether they can read the code they are testing.
- 02
Systems and trade-offs
Test how they decide what to automate, what to test manually, and what is not worth testing at all.
- 03
Evidence and rigour
Check how they handle a flaky suite and whether they can describe a bug that escaped to production.
- 04
Collaboration and communication
Assess how they raise quality problems with developers under release pressure without becoming a blocker.
Pre-screening questions to ask Quality Assurance (QA) Engineer candidates
12 questions grouped by what they test. Ask the same set in every screen and score answers on a consistent scale, or send them as an async video screen and compare answers side by side.
Testing background
4 questions01How many years have you worked in software testing and QA, and what kind of products were you testing?
Listen forSpecific products, team size, and whether they owned manual testing, automation, or both, with clear dates and scope.
Vague tenure claims with no product detail, or years of experience that do not match the responsibilities described.
02What QA tools have you actually used yourself, and what did you use each one for?
Listen forNamed tools tied to purpose: Playwright or Cypress for UI, Postman or REST Assured for APIs, Jira and TestRail for tracking.
A long tool list with no explanation of what they did in each one, or tools named that do not fit the stated stack.
03Which automated testing frameworks have you built or extended, and in what language?
Listen forFramework plus language plus their own contribution: page objects, fixtures, test data setup, parallel runs, custom reporting.
Claims automation experience but can only describe pressing run on a suite someone else wrote and maintained.
04What continuous integration tools have you run tests in, and how were the suites triggered?
Listen forNamed CI (GitHub Actions, Jenkins, GitLab CI, CircleCI) plus triggers: per pull request, nightly regression, pre-deploy gate.
No knowledge of where their tests ran, or tests only ever executed manually on a local machine.
Coverage decisions
3 questions05Walk us through a test strategy you defined for a project: what you chose to automate, what you kept manual, and what you decided not to test.
Listen forExplicit reasoning about risk, change frequency, and maintenance cost, including something they consciously left untested.
Says everything should be automated or everything matters equally, with no cost or maintenance reasoning.
06What are the key factors you weigh when writing test cases for a new feature?
Listen forRequirements traceability, boundary and negative cases, test data needs, and clear preconditions others can reproduce.
Only lists happy-path steps, or describes test cases so vague another engineer could not run them.
07How do you check that a feature is not just functional but actually usable for the end user?
Listen forConcrete methods: exploratory sessions, accessibility checks, real device testing, reviewing support tickets or session recordings.
Treats usability as design's problem, or reduces it to whether the acceptance criteria passed.
Rigour and escapes
3 questions08Tell us about the most difficult bug you have had to track down, and how you found the root cause.
Listen forA reproducible narrative: symptoms, how they narrowed scope, logs or debugger used, root cause, and the test added afterwards.
Describes reporting the bug and handing it off, with no involvement in isolating or verifying the cause.
09Have you found security-related defects, and how did you spot them?
Listen forReal examples: broken access control between user roles, injection attempts, exposed tokens, or findings from OWASP-style checks.
Assumes security is entirely a separate team's job and has never tested authorisation or input handling.
10Describe a time developers pushed back on a defect you raised close to a release. What did you do?
Listen forEvidence-led escalation: reproduction steps, user impact framing, severity agreement with product, and a decision that unblocked the release.
Either caves immediately to release pressure or describes blocking a ship with no impact evidence.
Team fit and logistics
2 questions11How does QA work in your current Agile or Scrum team: when do you get involved in a story?
Listen forInvolvement at refinement and acceptance criteria stage, testing within the sprint, and clear handling of the definition of done.
Describes QA only as a gate at the end of the sprint, receiving builds with no earlier input.
12Do you hold any QA certifications such as ISTQB, and are you available for a technical panel in the next two weeks?
Listen forHonest certification status plus concrete availability windows and any notice period or time zone constraints.
Overstated or unverifiable credentials, or no clear availability after multiple scheduling attempts.
How to score responses
Score every candidate on the same four criteria immediately after the screen. At this stage you are shortlisting for panel interviews, not making the final call.
Technical proficiency
35%5Builds and maintains automation themselves, and reads the code well enough to test where the risk actually is.
Systems and trade-offs
25%5Allocates testing effort by risk, and can defend what they deliberately left untested.
Evidence and rigour
25%5Fixes flakiness at the cause rather than by retrying, and is candid about a bug that escaped and why.
Collaboration and communication
15%5Raises quality risks with evidence and calibrated urgency, so releases improve rather than stall.
QA screening depends on hearing someone reason out loud about coverage trade-offs and describe a bug hunt in order. Async video captures that reasoning, plus how diplomatically they would tell a developer their fix is incomplete.
Try it on HirevireScreening FAQ
Process basics
How many questions should a QA engineer pre-screen include?
Eight to ten questions is enough for a QA screen. Cover tools and frameworks, one decision question on automation scope, one incident question about a bug that reached production, one on developer friction, and logistics. Keep it under fifteen minutes of candidate effort; longer screens lose strong mid-level applicants who are interviewing at several companies at once.
Should I ask for a coding or testing exercise at the pre-screen stage?
Not a full take-home at this stage. Instead ask candidates to walk through a test suite or test plan they already built, on video, sharing the structure and one hard decision they made. That surfaces real ownership in three minutes and gives your panel something concrete to probe, without asking for unpaid work upfront.
Evaluating answers
How do I tell a real automation engineer from someone who only ran existing tests?
Listen for setup detail: which framework and language, how they handled waits and test data, where the suite ran in CI, and what they did when it went red. People who only executed suites describe results and ticket counts; people who built them describe page objects, fixtures, parallelisation, and the trade-offs they accepted.
What is a good answer about a bug that escaped to production?
A good answer names the bug, how it got past the suite, the blast radius, and the specific test or process change that followed. Weak answers blame developers, product deadlines, or claim nothing ever escaped. Every QA engineer with real shipping experience has an escape story; refusing to give one signals limited exposure or low ownership.
Go deeper on this role
Sanat has been hiring since 2012 and watching the recruitment industry change up close ever since, and turned that screening process into Hirevire's video screening platform. LinkedIn
