Why pre-screen software testers before the technical interview
Following a written test script is not the skill. The skill is imagining what a user might do that nobody planned for, noticing that a number looks wrong in a way the specification does not cover, and writing it up so a developer can reproduce it in a minute. Testers worth hiring have found something serious late. A short screen asks about the worst bug they found.
What actually matters when screening Software Tester candidates
- 01
Technical proficiency
Check depth in test design: equivalence partitioning, boundary values, API checks in Postman, and automation with Selenium, Cypress or Playwright plus assertions they wrote themselves.
- 02
Systems and trade-offs
Probe how they decide what not to test: risk-based prioritisation before a release, regression suite scope, manual versus automated coverage, and CI runtime budgets in Jenkins or GitHub Actions.
- 03
Evidence and rigour
Assess bug quality: reproducible steps, logs, environment detail, severity versus priority calls in Jira or TestRail, and defect leakage or escape rate they tracked.
- 04
Collaboration and communication
Look for how they push back on developers and product owners over ambiguous acceptance criteria, sign-off disputes, and shipping decisions during a tight release window.
Pre-screening questions to ask Software Tester 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.
Defects they found
3 questions01Have you found a critical defect in an application, and how did you find it?
Listen forA serious defect with the reasoning that led to it, showing exploration beyond the written cases.
Defects found only by following a script, or no significant issue they can describe.
02Which types of software testing are you familiar with?
Listen forSeveral types understood with the purpose of each, and the ones they are strongest at named.
Testing types listed as terminology, or no distinction between their purposes.
03How do you approach functional testing of a new feature?
Listen forBoundaries, invalid input and interactions with existing features are all explored deliberately.
Testing limited to the acceptance criteria, or only the expected path exercised.
Designs beyond happy path
3 questions04Have you created a test plan from scratch?
Listen forScope and risk-based prioritisation described, with what will not be tested stated explicitly.
Plans that attempt to test everything equally, or no prioritisation by risk.
05Can you explain your process for creating a test case?
Listen forCases derived from requirements and risk, with preconditions and expected results written clearly.
Cases that restate the requirement, or expected results left open to interpretation.
06How do you handle regression testing?
Listen forA maintained suite prioritised by risk, with tests removed when they stop earning their cost.
Regression suites that only grow, or full manual regression before every release.
Automation earns its keep
3 questions07Can you describe your experience with automated testing tools?
Listen forAutomation applied where it repays maintenance, with flaky tests fixed rather than tolerated.
Flaky tests rerun until they pass, or automation coverage treated as the objective.
08Are you experienced with both manual and automated testing?
Listen forA clear view of what belongs in each, with exploratory testing valued alongside automation.
Manual testing dismissed entirely, or exploratory testing described as unstructured.
09Which programming languages are you comfortable with?
Listen forEnough to write and maintain test code, and to read the application code being tested.
No coding ability where the role requires automation, or scripts copied without understanding.
Reports developers can use
3 questions10Can you give an example of how you have used a defect tracking system?
Listen forReports with exact steps, environment and expected against actual behaviour all recorded clearly.
Reports lacking reproduction steps, or defects raised without checking they are reproducible.
11Describe a time when you worked closely with developers during testing.
Listen forEarly involvement in requirements and design, with defects discussed rather than thrown over.
Testing treated as a stage after development, or a relationship described as adversarial.
12Can you describe your experience in a team-based development environment?
Listen forQuality treated as a team responsibility, with them raising risks early rather than at release.
Quality described as the tester's job alone, or issues raised only in the final test cycle.
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%5Names frameworks used daily, explains locator strategies and flaky test fixes, and distinguishes unit, integration and end-to-end coverage precisely.
Systems and trade-offs
25%5Justifies coverage choices against release risk and pipeline time, and cites a case where they deliberately deferred low-value automation.
Evidence and rigour
25%5Describes tickets developers reproduced first try, and quotes metrics like escaped defects per release or reopened bug counts.
Collaboration and communication
15%5Recounts a specific release they flagged as risky, the evidence presented, and how the disagreement was resolved without stalling delivery.
Following a script is not the skill; imagining what breaks is. A one-way video screen asks what they found.
Try it on HirevireScreening FAQ
Process basics
How long should a pre-screening round for this role take?
Ten to fifteen minutes across eight to ten questions, answered async. Enough to establish defects they found, test their design approach, and check automation and reporting practice.
How much automation should I expect?
Enough to automate regression where it pays back, without treating automation as the goal. A tester who automates everything spends more time maintaining tests than finding problems.
Evaluating answers
What is the strongest signal when screening this role?
The worst defect they found and how they found it. Strong testers describe reasoning about what could break. Anyone describing a scripted step has been executing rather than testing.
How do I judge their bug reports?
Ask what a good report contains. Real answers include exact steps, environment and expected against actual. Anyone whose reports say it does not work creates a second job for the developer.
























