QA Tester Example Questions: What to Ask During Technical Interviews

Why standard QA questions fail hiring

Most QA interview questions fall into two traps: they're either so generic ("What's the difference between testing and QA?") that anyone passing a certification exam can answer them, or so specific to your tech stack that they test framework knowledge rather than thinking. The candidates who memorize test vocabulary sound competent. The ones who actually break software and fix processes are invisible.

Good QA questions measure test strategy, not terminology. They expose what candidates actually do when they don't have a test plan to follow.

Example question #1: The bug report scenario

"You're testing an e-commerce checkout flow. The payment gateway sometimes accepts duplicate transactions—same order ID, same amount, within 5 seconds. It happens roughly 1 in 50 times. Walk me through how you'd investigate and document this."

What you're measuring:

• Do they ask clarifying questions (what payment method? what browser? network conditions)?
• Do they distinguish between bug reproduction, root cause, and scope (is it in their code or the gateway's)?
• Can they articulate a test case that catches it again?
• Would they escalate or try to reproduce it themselves first?

This reveals whether they think like engineers (root cause, scope, prevention) or just like reporters (symptom, screenshot, ticket).

Example question #2: The automation trade-off

"You've got a test suite that runs in 2 hours end-to-end. Your team runs it once a day. A teammate proposes automating the UI flow for image uploads—about 40 lines of Selenium and 15 minutes of maintenance per quarter. Do you do it? Walk me through your reasoning."

What you're measuring:

• Do they think about ROI (cost to automate vs. cost of manual retesting)?
• Do they know when automation is overhead, not efficiency?
• Can they estimate maintenance burden honestly?
• Do they consider brittleness and false positives?

Candidates who say "yes, automate everything" or "no, UI tests are flaky" are missing the point. The right answer is usually "it depends on what it catches and how often it breaks."

Example question #3: The test design challenge

"We're building a feature that exports user data to CSV. The file can have 10 to 100,000 rows. What would you test? What would you not test and why?"

What you're measuring:

• Can they prioritize (CSV format, row count edge cases, special characters) vs. noise (does the button color matter)?
• Do they know what's worth automating vs. spot-checking?
• Can they articulate risk (data leakage, formatting corruption) vs. preference?

Good QA engineers are ruthless about scope. They don't test everything; they test what could hurt the business.

Example question #4: The regression risk

"Your team just refactored the database queries in the user profile page. There were no schema changes, just code cleanup. What's your testing strategy? What's your confidence level?"

What you're measuring:

• Do they want to run the full regression suite or think critically first?
• Can they identify what could break (N+1 queries, wrong data binding)?
• Do they understand the difference between "code changed" and "risk changed"?

This separates analysts from engineers. Engineers ask "what changed and what matters?" Analysts run the full suite regardless.

Example question #5: The cross-browser question (with a twist)

"You're testing a new UI component on Chrome, Firefox, and Safari. It renders correctly everywhere. Do you test it on IE11? On mobile Chrome? On Chromium-based browsers like Edge? Make the trade-off call."

What you're measuring:

• Do they know their user base (not all products need IE11 support)?
• Can they estimate browser coverage vs. testing cost?
• Do they know the difference between real browsers and fake coverage?

This is where opinion matters. "We don't support IE11, so no" is stronger than "we should test everything."

Example question #6: The live coding interview (brief)

"Write a test case in whatever framework you know best. I'll give you a simple function: validateEmail(email). Return true if it's a valid email, false otherwise. Write the test—don't write the function."

What you're measuring:

• Can they think about edge cases (empty string, no @, multiple @s, spaces)?
• Do they write tests that are readable or cryptic?
• Do they know their testing framework (assertions, setup/teardown)?
• Are they testing behavior or implementation?

This is a live coding interview that takes 10 minutes and surfaces language fluency, test structure, and thinking.

The pattern that works

All six of these questions have the same structure: present a real (or realistic) situation, ask the candidate to reason through it, and listen for judgment, not keyword recall. The answers aren't right or wrong. They're revealing.

The interviews you'll remember are the ones where a candidate asks you a clarifying question that makes you pause. That's the signal. That's the hire.

When to use written assessments instead

Not every QA hire needs a recorded live coding interview. A take-home test case assignment can be equally revealing: "Here's a feature spec. Write 10-15 test cases that you'd propose to your team. Explain your priority." Then ask follow-up questions in the next round about their reasoning. This combines artifact quality with verbal defense.

For scaling hiring, assessment platforms that can grade test case coverage, assertion quality, and edge-case thinking make live rounds more efficient.

Counter-consideration

Some teams prefer behavior-first interviews without the testing terminology at all: "Tell me about a bug you found that surprised you" or "Walk me through the last time you pushed back on a deadline because testing wasn't done." This works too, especially if you're hiring people who own quality rather than people who are testers.

The questions matter less than the philosophy: you're measuring thinking, not memory. Everything else follows.