QA engineer interview questions that tell you something
Transparency note: Hireo is built by BetterQA, an ISO 27001 certified software testing company in Cluj-Napoca. We hire QA engineers for our own delivery teams, which is why this blog exists. The questions below are ones we use, not ones we collected.
Why most QA interviews measure the wrong thing
The standard QA interview asks a candidate to list test types, define the testing pyramid, or explain the difference between severity and priority. Every one of those has a correct answer that can be memorised in an evening, and none of them predicts whether the person will catch the bug that reaches your customers.
What you are actually hiring for is judgement under incomplete information. A tester spends their day deciding what not to test, because testing everything is not available to them. That decision is invisible in a definitions quiz.
The questions below are built to make that decision visible. None has a right answer. All of them separate somebody who has done the work from somebody who has read about it.
Six questions, and what the answers tell you
How would you test a login form?
The oldest question in QA, and still the best opener, because it has no floor and no ceiling. A weak candidate lists valid and invalid credentials and stops. A stronger one reaches password reset, session expiry, the back button after logout, rate limiting, and what happens when the same account signs in from two places.
What you are listening for is not the length of the list. It is whether they ask you anything first. Is this a banking app or an internal tool? Does it have SSO? Who is allowed to be locked out? A candidate who starts generating cases without asking those has told you how they will behave on your product.
What is the last bug you missed?
The single most informative question here, and the one candidates are least prepared for. Everyone has missed something. What matters is whether they can describe it without either shrugging or flagellating themselves.
Good answers are specific and structural: the bug lived in a path nobody owned, or in a combination of settings nobody had thought to combine, and here is what we changed afterwards. Weak answers are either "I cannot think of one" or a story where somebody else was at fault. The first is not credible. The second tells you what post-incident conversations will be like.
This release ships Friday and you have two days of testing left. What do you do?
Almost the whole job, compressed. There is no way to answer well without talking about risk, and there is no way to answer badly that is not revealing.
Listen for whether they reach for the change log. The correct instinct is to test what moved and what sits downstream of what moved, not to run the full regression suite more quickly. Listen also for whether they say out loud what they are choosing not to cover. A tester who will tell a room "we did not test the export path, here is why" is worth considerably more than one who lets that stay unsaid.
How do you decide something is not worth testing?
The mirror of the previous question, and worth asking separately, because it invites the candidate to defend a negative decision rather than triage under pressure.
The answer you want involves consequence, not probability alone. Rare and catastrophic beats frequent and cosmetic. If they only talk about how likely a path is to be used, they are missing half the calculation, and it is the half that produces the expensive incidents.
When did you last delete a test, and why?
This one surprises people, which is the point. Test suites accumulate. A tester who has never removed anything has either never owned a suite long enough for it to rot, or believes coverage only goes up.
Strong answers name the specific failure: the test was flaky and nobody trusted its red, or it asserted an implementation detail that changed for a good reason, or it duplicated another test and both broke together on every unrelated change. Any of those shows they have lived with a suite rather than only added to one.
How would you check whether an AI-generated test is any good?
Increasingly the question that separates recent experience from dated experience. Generated tests are now routine, and reviewing them is a distinct skill from writing them.
What you want to hear is scepticism with a method. Does the test fail when the code is broken? Does it assert the behaviour or merely restate what the implementation currently does? A test that passes against both the correct and the broken version is worse than no test, because somebody will read the green and stop looking. A candidate who says that unprompted has understood something many experienced testers have not.
What a strong answer sounds like next to a rehearsed one
Across all six, the tell is the same: a rehearsed answer arrives complete, and a real one arrives with conditions attached.
Somebody who has done the work says "it depends on whether" and then tells you what it depends on. Somebody who has revised for the interview delivers a tidy list with no qualifications, because the list came from an article rather than from a release that went badly. Both sound confident. Only one of them is telling you how they think.
Follow up on the specific, always. "You said the bug was in a path nobody owned. How did you find it?" A real story survives that question and gets more interesting. A constructed one gets vaguer.
Hiring one QA engineer, or bringing in a partner
Worth being straight about, since we do both. These questions assume you are hiring somebody permanent, and that is not always the right call.
Hiring in-house makes sense when testing is continuous, when the product knowledge compounds, and when you have somebody senior enough to interview well. That last condition is the one teams underestimate. If nobody in the building can tell a strong answer from a rehearsed one on the six questions above, you will hire on confidence, and confidence is the thing rehearsal produces.
A testing partner makes sense when the need is spiky, when you want coverage across skills a single hire cannot have, or when you need testing running before a hiring process could realistically finish. The honest trade is that you get capability sooner and product depth later. Our own software testing services work this way, and we would rather say where the trade sits than pretend there is not one.
Plenty of teams do both: a partner while the search runs, an in-house hire who then owns it. That is usually the least wasteful order.
What to do with the answers
Do not score these. A rubric turns a judgement question back into a definitions quiz, which is the problem the questions exist to solve.
Write down, per candidate, the one moment where they surprised you and the one where they reached for a template. Compare those across candidates rather than comparing totals. The surprises are the signal, and they do not add up into a number.
And record the answers somewhere the next interviewer can read them before the second round, rather than relaying an impression. Hireo keeps the notes against the candidate so the second conversation starts where the first one stopped, which is a small thing that stops good candidates being asked the same opener twice.