QA Career

QA Engineering Interview Prep: Questions, Test Tasks, and What Interviewers Look For

HelpMeTest

HelpMeTest

— 8 min read
QA Engineering Interview Prep: Questions, Test Tasks, and What Interviewers Look For

QA and SDET interviews are inconsistent. Some are almost entirely behavioral. Some are heavy on coding. Some give you a live application and ask you to find bugs. Some give you a take-home assignment that takes 10 hours. You can't prepare for a single format.

What you can prepare for is the underlying competencies every interviewer is trying to evaluate, regardless of format. This guide covers those competencies, the common question types, how to approach coding test tasks, and the mistakes that cause otherwise qualified candidates to fail.

What Interviewers Are Actually Evaluating

Before the specific questions, understand the frame. QA engineering interviews typically assess four things:

1. Testing instincts: Can you identify what to test and why? Do you think systematically about edge cases, failure modes, and user impact? This is the core QA skill — no tool or language teaches it, it develops through practice and deliberate thinking.

2. Technical ability: Can you write code to automate tests? Do you understand how web applications work? Can you read a stack trace, inspect network requests, or write a basic SQL query?

3. Communication: Can you explain a bug clearly enough for a developer to reproduce it? Can you write a test case that someone else could execute without help? QA requires precision in language.

4. Judgment: Do you know what to test first? Can you make tradeoffs between speed and coverage? Do you understand that not everything needs to be automated?

Great interviewers design questions that reveal all four. Mediocre interviewers check a list. Either way, if you're strong in all four, you'll do well.

The Common Question Types

Behavioral Questions

Every QA interview includes behavioral questions. The most common:

"Tell me about a significant bug you found."

This is not a question about the bug. It's a question about you. Interviewers want to know: How do you identify non-obvious issues? How do you communicate them? How do you handle the situation when development pushes back?

Structure your answer with: what you were testing, what made you suspect a problem, how you confirmed and documented it, how you communicated it, and what the outcome was.

Example of a strong answer structure: "I was testing the checkout flow for a new payment method. During exploratory testing, I noticed that the order total displayed in the confirmation email didn't match what the user had approved during checkout — a small rounding difference. I confirmed it was consistent and reproducible across several test cases, documented it with screen recordings and network request logs, and flagged it as P1 given the potential for customer disputes. Engineering initially thought it was a display issue, but after sharing the network logs showing the discrepancy at the API level, they prioritized it. It was fixed before the feature shipped."

That answer demonstrates testing instinct, technical depth, communication, and judgment — all four competencies.

"Tell me about a time testing slowed down a release. How did you handle it?"

This assesses your judgment and your ability to work under pressure. The answer they're looking for: you made a risk-based decision, you communicated clearly, and you didn't simply defer to whoever was loudest in the room.

"How do you handle a situation where a developer says 'that's not a bug, it's by design'?"

They want to see that you can hold your position with evidence while remaining collaborative. The right answer involves: having documented expected behavior before testing, presenting user impact rather than personal opinion, and escalating to PM when needed.

Test Case Design Questions

These are often given live, with a feature description or a live application. Common prompts:

  • "How would you test a login page?"
  • "Write test cases for a search feature."
  • "You have 2 hours to test this new feature before the release. What do you test?"

The approach that works:

Start with clarifying questions before writing a single test case. Interviewers reward candidates who ask about scope, user types, platform requirements, and known constraints. Jumping straight to test cases looks eager but signals poor process.

Then structure your test cases from most critical to least:

  1. Happy path: The core flow working as intended with valid inputs
  2. Authentication/authorization: Does the feature respect user roles and permissions?
  3. Input validation: Empty inputs, boundary values, invalid formats, special characters
  4. Error handling: What happens when something goes wrong? Network failure, server error, timeout?
  5. State and persistence: Does data save correctly? Does it reload correctly?
  6. Cross-browser/platform: If applicable, does it work consistently?
  7. Performance: Does the feature respond in acceptable time under load?
  8. Security: SQL injection, XSS, CSRF for input-heavy features

You won't have time to enumerate every case in an interview. The goal is to show that you think systematically and know how to prioritize. Call out what you're including and what you're deliberately leaving out, and why.

Exploratory Testing Live Sessions

Some interviews give you a staging environment and 30–60 minutes to find bugs. This is common at product companies with strong QA culture.

What interviewers observe:

  • Do you explore methodically or randomly?
  • Do you check the obvious paths first, then the edges?
  • Do you inspect developer tools (network tab, console errors)?
  • Do you document what you find as you find it?
  • Do you ask clarifying questions or make assumptions?

Preparation tip: Practice exploratory testing on live applications. Find a product you use and spend 30 minutes trying to break it. Check the console for JavaScript errors, inspect API calls in the network tab, try boundary values in every input field, try actions in unexpected orders. The more you practice, the faster your instincts become.

Coding Test Tasks

SDET interviews almost always include a coding component. The formats vary.

Automate a Test Scenario

The most common task: you're given a web application (often a demo app like Sauce Labs' demo or a company's own staging environment) and asked to automate a specific scenario.

Example: "Write an automated test that verifies a user can add an item to the cart and complete checkout."

What they're evaluating:

  • Can you set up a test project from scratch?
  • Do you write readable, maintainable test code?
  • Do you handle waits correctly?
  • Do you add assertions that actually verify behavior (not just that elements exist)?
  • Do you follow basic software engineering practices (no hardcoded credentials, clear naming, comments where needed)?

A well-structured Playwright test for this scenario:

import { test, expect } from '@playwright/test';

test.describe('Checkout flow', () => {
  test.beforeEach(async ({ page }) => {
    // Log in and reach product page before each test
    await page.goto('https://demo.example.com/login');
    await page.fill('[data-testid="username"]', process.env.TEST_USER);
    await page.fill('[data-testid="password"]', process.env.TEST_PASSWORD);
    await page.click('[data-testid="login-btn"]');
    await expect(page).toHaveURL(/inventory/);
  });

  test('user can add item to cart and complete checkout', async ({ page }) => {
    // Add first item to cart
    await page.click('[data-testid="add-to-cart-sauce-labs-backpack"]');
    await expect(page.locator('[data-testid="shopping-cart-badge"]')).toHaveText('1');

    // Navigate to cart
    await page.click('[data-testid="shopping-cart-link"]');
    await expect(page.locator('[data-testid="inventory-item-name"]')).toHaveText('Sauce Labs Backpack');

    // Proceed to checkout
    await page.click('[data-testid="checkout"]');
    await page.fill('[data-testid="firstName"]', 'Test');
    await page.fill('[data-testid="lastName"]', 'User');
    await page.fill('[data-testid="postalCode"]', '10001');
    await page.click('[data-testid="continue"]');

    // Verify order summary
    await expect(page.locator('[data-testid="inventory-item-name"]')).toHaveText('Sauce Labs Backpack');
    await expect(page.locator('[data-testid="total-label"]')).toBeVisible();

    // Complete purchase
    await page.click('[data-testid="finish"]');
    await expect(page.locator('[data-testid="complete-header"]')).toHaveText('Thank you for your order!');
  });
});

Notes on what makes this strong: credentials from environment variables (not hardcoded), beforeEach for shared setup, assertions that verify actual content (not just visibility), descriptive test name, clear test structure.

Write a Test for a Given Function

Some SDET interviews ask you to unit test a function in the company's codebase. This tests your coding ability and your understanding of testing principles.

For a function like:

function calculateDiscount(price, discountPercent) {
  if (discountPercent < 0 || discountPercent > 100) {
    throw new Error('Invalid discount percentage');
  }
  return price - (price * discountPercent / 100);
}

Strong test cases cover:

  • Happy path: 20% discount on $100 = $80
  • Zero discount: $100 with 0% = $100
  • Full discount: $100 with 100% = $0
  • Boundary values: 99%, 1%
  • Invalid inputs: -1%, 101%, null, undefined, non-numeric
  • Floating point: Does $10.99 with 15% return the expected result?

API Testing Tasks

You may be given API documentation and asked to write tests against an endpoint. Key things to test:

  • Valid request with valid credentials → expected response body and status code
  • Valid request with invalid credentials → 401/403
  • Invalid request body → 400 with meaningful error message
  • Missing required fields → appropriate error
  • Boundary values in parameters
  • Rate limiting behavior (if relevant)

Example using supertest in Node:

const request = require('supertest');
const app = require('../app');

describe('POST /api/users', () => {
  it('creates a user with valid data', async () => {
    const response = await request(app)
      .post('/api/users')
      .set('Authorization', `Bearer ${process.env.TEST_API_KEY}`)
      .send({ email: 'test@example.com', name: 'Test User' });

    expect(response.status).toBe(201);
    expect(response.body.email).toBe('test@example.com');
    expect(response.body.id).toBeDefined();
  });

  it('returns 400 when email is missing', async () => {
    const response = await request(app)
      .post('/api/users')
      .set('Authorization', `Bearer ${process.env.TEST_API_KEY}`)
      .send({ name: 'Test User' });

    expect(response.status).toBe(400);
    expect(response.body.error).toMatch(/email/i);
  });
});

Take-Home Assignments

Many companies send a take-home test task. Typical scope: 2–4 hours of actual work. Common formats:

  • Automate 3–5 scenarios for a provided web app
  • Write a test plan for a described feature
  • Find and document bugs in a staging environment
  • Write unit tests for a provided code snippet

Take-home tips:

Treat it like a real work product. Readme with setup instructions, clean code, meaningful commit messages, organized test structure. You're showing them what working with you looks like.

State your assumptions. If the requirements are ambiguous, say so and explain what you assumed. "I assumed user authentication would be handled via environment variables rather than hardcoded credentials" — this shows professional judgment.

Don't over-engineer it. A clean, working solution for the stated scope beats a half-finished framework that's trying to do too much. Scope to what's asked, do it well, and briefly explain what you'd add with more time.

Include what you'd test next. After your implemented tests, add a section: "Given more time, I would also add..." This shows that your thinking extends beyond what you implemented.

Questions to Ask the Interviewer

Always ask questions. Not to fill time — to gather real information about whether this is a place you want to work.

  • "What does the current test coverage look like, and where are the biggest gaps?"
  • "How does QA fit into the development process — are testers embedded in feature teams or centralized?"
  • "What's the biggest quality challenge the team is facing right now?"
  • "How are bugs that reach production handled — is there a post-mortem process?"
  • "How much time does QA typically get before a release?"

These questions signal that you're thinking about the job seriously. They also give you real data about whether the QA culture there is healthy.

The Mistakes That Sink Candidates

Testing only the happy path. In live exercises, candidates who only test that things work when everything is correct fail immediately. Edge cases and error handling are where QA thinking shows.

Asserting existence instead of behavior. "The button is visible" is not a test. "The button is visible and clicking it submits the form and the user sees a confirmation message" is a test.

Writing code first, without explaining your approach. In pair coding exercises, walk through your thinking before typing. "I'm going to write a setup function that handles the login, then write individual tests for each scenario" — then do it. Interviewers are evaluating your process, not just your output.

Not asking clarifying questions. Jumping into a test design without asking about scope, user types, or known requirements is a red flag. Senior QA engineers ask questions before they start testing. Junior engineers guess.

Treating automation as the answer to everything. When asked "how would you improve testing here?", the answer isn't always "automate more." Sometimes it's better monitoring, better tooling, better developer testing practices, or a shift-left approach. Show range.

Preparing in the Last Week Before the Interview

  • Run through 10 exploratory sessions on real applications. Practice documenting bugs with full reproduction steps.
  • Write 3 complete automated test scenarios from scratch, without tutorials. Set up the project, write the tests, get them passing.
  • Practice explaining your test design decisions out loud. Record yourself if it helps. Interviewers notice when answers are fluent vs. rehearsed-from-notes.
  • Review HTTP fundamentals: status codes, request methods, headers, auth. Most SDET roles require solid API knowledge.
  • Research the company's product. Know what it does, what the core user flow is, and what could go wrong. Coming in with specific test ideas for their product makes an impression.

The QA engineering interview rewards preparation and genuine testing instincts more than any specific tool or framework. Know your fundamentals, prepare your examples, and practice until the thinking is fast.

Read more

Start now free