DEV Community

Cover image for 5 QA Interview Questions That Senior Engineers Still Get Wrong
George Bakatsias
George Bakatsias

Posted on • Edited on

5 QA Interview Questions That Senior Engineers Still Get Wrong

Whether you're preparing for a QA Engineer or SDET interview, some questions trip up even experienced professionals. Here are 5 I've seen catch people off guard:

1. "Design a test automation framework from scratch — what's your architecture?"

Most candidates jump straight to tools (Selenium, Playwright).
Interviewers want to hear about:

  • Page Object Model vs Screenplay pattern
  • Test data management strategy
  • CI/CD integration approach
  • Reporting & failure analysis

Tip: Start with the problem (what are we testing?), not the tool.

In real interviews, you might be handed a full Playwright project — complete with Page Object Model, Builder pattern, custom fixtures, and API + UI tests — and asked to explain the architectural decisions, not just run it.

2. "You have 2 hours to test this API — walk me through your approach"

The trap: candidates start writing tests immediately.

Better approach:

  • 5 min: Read the API docs/Swagger
  • 10 min: Identify critical paths & edge cases
  • 15 min: Set up collections (Postman/REST client)
  • 90 min: Execute tests (happy path → edge cases → security)
  • Remaining: Document findings

3. "Look at this form and tell me what's wrong" (Attention to Detail)

You're shown a screenshot of a registration form — something like a "New Registration" page with fields for user ID, password, name, email, address, and country.

Everything looks fine at first glance. But the interviewer expects you to catch things like:

  • Password confirmation is visible in plain text while the password field is masked
  • The "First Name" field accepts numbers (John Plainfield 777)
  • Validation messages are inconsistent — some fields show errors, others silently accept bad input
  • The address field allows multiple selections when it shouldn't
  • The copyright year at the bottom says 1811
  • The "I am not a robot" is a simple checkbox instead of a proper CAPTCHA
  • Missing asterisks on required fields like Email and Confirm Password

Most candidates spot 2–3 issues. Strong candidates find 10+. This tests whether you actually look at what's in front of you or just tick boxes.

4. "Write a test for this code" (Code Reading Challenge)

You get production source code and must decide which tests give full coverage. This isn't about writing code fast — it's about analytical thinking.

For example, you might see pseudocode like:

IF A > B THEN
    C = A - B
ELSE
    C = A + B
ENDIF
Read D
IF C = D Then
    Print "Error"
ENDIF
Enter fullscreen mode Exit fullscreen mode

And you're asked: "What's the minimal test set to cover all branches?"

Most people say 5 tests, or 3. The answer is 2 — if you pick values that traverse complementary paths (one where both IFs are true, one where both are false), you get full statement and branch coverage.

This question filters out people who test mechanically from those who reason about coverage.

5. "Draft a bug report for this scenario"

Sounds simple, but interviewers evaluate:

  • Clear title (not "bug in form")
  • Steps to reproduce (exact, numbered)
  • Expected vs Actual behavior
  • Environment details
  • Severity/Priority classification
  • Urls/screenshots/logs as evidence

A typical setup: you're given a requirement — say, a Payment module with a "Status" column that should show Red/Yellow/Green based on due dates. The developer implemented it, but in your testing you find the status turns Yellow when the due date is wrong instead of the one specified in the requirements.

Now write the bug report. Most candidates write vague descriptions. What interviewers want to see:

  • Title: "Payment Status shows Yellow instead of a more precise condition"
  • Steps: Access the URL, navigate to Payment, filter by specific rules
  • Expected VS Actual reasons should be clear
  • Reference: Link to the requirement

The difference between a junior and senior bug report is precision. Developers should be able to reproduce the bug without asking you a single question.

Want to practice all of these?

I put together a hands-on exercise pack with real scenarios,
solution docs, and a Playwright automation project for almost nothing:

👉 QA Interview Content Pack

Includes:

  • ✅ Attention-to-detail exercise
  • ✅ Test case exercise
  • ✅ Code-reading challenge
  • ✅ Bug report writing exercise
  • ✅ A Playwright project (TypeScript, POM, fixtures, architectural decisions readMe)

What's the hardest QA interview question YOU've been asked? Drop it in the comments! 👇

Top comments (0)