QA tester interview: the questions to prepare
· 8 min read
Testing suffers from a stubborn misunderstanding: many candidates present themselves as executors of test plans. Recruiters are looking for someone who can say what is worth testing — and what is not.
What does a recruiter really look for in a tester?
Three abilities, in this order. Prioritising under time pressure, because you never test everything. Describing a defect reproducibly, because a vague report costs more than it returns. And saying no to a release, which means owning a disagreement.
Which technical questions come up most?
- The difference between functional, regression and acceptance testing: they check the vocabulary is mastered, not recited.
- What you automate and what you keep manual — and above all why. An "automate everything" answer is a red flag.
- The test pyramid: unit, integration, end to end. They expect you to know why the base must be wide.
- A test case you consider badly written, and how you would rewrite it.
- Your relationship with code coverage: knowing that 90% coverage says nothing about assertion quality.
How does the practical exercise work?
This is what separates candidates. You get a simple feature — a signup form, a shopping cart — and are asked what you would test. The trap is starting with the happy path. What they listen for are the edge cases you see spontaneously: empty field, double submission, special characters, browser back button, session expiring mid-form.
Do you need automation skills to get hired?
Not always, but you must be able to discuss it. Many postings ask for a specific tool — Selenium, Cypress, Playwright — while the team mainly wants someone who understands what an automated test costs to maintain. If you do not know their tool, say so, then explain the one you know: transferability is demonstrated, not claimed.
How do you answer "have you ever let a bug reach production?"
With yes. Saying no destroys your credibility in one sentence: everyone has. What is assessed is what came next — how you found out, what you changed in how you test, and whether the fix produced a regression test. The STAR method structures this kind of answer well.
Do soft skills weigh as much as technical ones?
More, at equal technical level. A tester spends the day bringing bad news to people in a hurry. You will be asked how you react when a developer disputes your report, or when a project manager asks you to sign off despite an open defect. Prepare both: they come up almost every time.
A good tester does not say "it does not work". They say what does not work, under which conditions, and how serious it is.
As with any technical interview, the gap widens out loud: knowing how to test and explaining it are two different skills. See also our piece on difficult interview questions and the method for researching a company before an interview.