SDET Interview Questions 2026: QA Automation Guide and Answers

SDET interview questions in 2026 test three skills: designing tests for a feature you have never seen, building automation that stays reliable in CI, and writing production-quality code. Most loops include a coding round, a "how would you test X" round, an automation framework discussion (now usually Playwright or Selenium), and API testing questions. Prepare a repeatable test design framework and a framework architecture you can draw from memory, and you cover most of the loop.

Key Takeaways

• An SDET interview is a software engineering interview with a testing lens. Expect a real coding round, then a follow-up asking you to test your own solution.
• "How would you test X" questions are scored on structure, not on how many test cases you list. Use the risk-based matrix below to rank what matters before going deep.
• Playwright is a common choice for new web automation projects, but Selenium knowledge still matters at enterprises. Be ready to compare Playwright, Selenium, and Cypress on trade-offs, not hype.
• Flaky test questions are about process: detect, quarantine, root-cause, fix, and measure. "Add retries" alone is a weak answer.
• Push tests down the pyramid. Interviewers want to hear that you test business logic at the unit and API layers and keep UI tests for critical user journeys.

What Is an SDET, and How Is It Different From QA and SWE?

An SDET (Software Development Engineer in Test) is an engineer who writes code whose job is to verify other code. That means automation frameworks, test harnesses, CI pipelines, mocks, and test data tooling. Companies also use titles like "Software Engineer in Test" or "QA Automation Engineer." The differences change what the interview tests.

Read the job description, not the title. If it mentions "build and maintain test frameworks," "CI/CD," and "code reviews," prepare for an SDET-level coding round even if the title says QA.

What Does the SDET Interview Process Look Like in 2026?

A typical SDET loop has four to six stages. The mix varies by company, but this pattern is common.

1. Recruiter screen (30 minutes): background, tools you have used, and salary expectations.
2. Technical phone screen (45-60 minutes): one coding problem plus testing questions. Our technical phone screen guide covers the general format.
3. Online assessment or take-home (some companies): often "automate this small app" or "write tests for this API." See the take-home coding assignment guide for how these are graded.
4. Onsite or virtual loop (3-5 rounds): coding, test design, automation framework design, sometimes a debugging round, and a behavioral round.

Many SDET candidates underprepare for the behavioral round: pushing back on a release, disagreeing with a developer over bug severity, improving quality culture. The behavioral interview guide has a STAR structure that works well for these.

Test Design Techniques You Must Know

Interviewers expect you to name and apply classic test design techniques. Knowing the terms signals training; applying them quickly signals experience.

• Equivalence partitioning: split inputs into classes that should behave the same, and test one value per class. For an age field accepting 18-65, the classes are below 18, 18-65, and above 65.
• Boundary value analysis: bugs cluster at edges. Test 17, 18, 19, 64, 65, and 66.
• Decision tables: list combinations of conditions and their expected outcomes. Useful for discount rules, permissions, and pricing logic.
• State transition testing: model the feature as states and transitions, then test valid and invalid transitions. Order lifecycles and login lockouts are classic examples.
• Pairwise (combinatorial) testing: when you have many parameters, cover every pair of values instead of every combination. Browser by OS by locale is the usual example.
• Error guessing and exploratory testing: experience-driven testing for things specs miss, like double-clicks and the back button.

Say which technique you are using and why. "This field has a numeric range, so I will start with boundary values" beats a list of numbers.

The 'How Would You Test X' Framework: A Risk-Based Test Design Matrix

"How would you test a login page" (or a vending machine, or a search box) is the most common SDET interview question. Most candidates start listing test cases immediately and run out of steam after ten. The interviewer is scoring structure, prioritization, and judgment.

Use this five-step framework.

Step 1: Clarify scope (2-3 minutes)

Ask who the users are, what the requirements say, and which platforms are in scope. For a login page: Is there SSO? Two-factor authentication? A lockout policy? Clarifying before testing is half the signal.

Step 2: Map the risk areas

List categories, not cases: functional, boundary and negative inputs, security, performance, accessibility, compatibility, localization, and integration with other systems.

Step 3: Score each area by risk

Risk is likelihood of failure multiplied by impact if it fails. Score each from 1 to 3 and multiply. Here is a worked example for a login page:

Step 4: Go deep on the top scores

Spend most of your remaining time on the areas scoring 6. Walk through specific cases using the techniques above: boundaries for input fields, state transitions for lockout, decision tables for 2FA combinations.

Step 5: Decide what to automate

Close by saying where each test lives. Logic and input validation go in unit tests. Authentication rules and security checks go in API tests because they are fast and stable. One or two happy-path E2E tests cover the full journey in a real browser. Exploratory testing covers the rest.

This step separates SDET answers from QA answers: it shows you think about speed of feedback, not just coverage.

Playwright vs Selenium vs Cypress: What Interviewers Want to Hear

Expect at least one question comparing automation tools, often phrased as "Why would you pick Playwright over Selenium?" The best answers are balanced. Every tool has trade-offs, and interviewers distrust candidates who call one tool perfect.

Points worth making in the interview:

• Playwright's auto-waiting. Per Playwright's actionability documentation, before a click it runs actionability checks before a click: the element must be visible, stable, enabled, and able to receive events. Locators are also strict, so one that matches several elements throws an error instead of clicking the wrong one. That removes a whole class of timing flakiness that Selenium users solve with explicit waits.
• Selenium has improved. Recent Selenium 4 releases ship Selenium Manager, which finds and downloads matching browser drivers automatically, so the old "driver version mismatch" pain is mostly gone. Mentioning this shows your knowledge is current.
• Cypress's in-browser model gives a strong developer experience but has historically made multiple tabs and cross-origin flows harder. It is a good choice for front-end-heavy teams.

If asked about migration: write new tests in Playwright, port the flakiest high-value Selenium tests first, and run both suites until coverage matches.

Framework Design: A Sample Playwright Answer

"Design a test automation framework from scratch" is a common senior SDET question. Treat it like a small system design interview: requirements first, then layers, then trade-offs.

A strong answer organizes the framework in layers:

1. Test layer: readable specs that describe user behavior, with no raw selectors.
2. Page objects or components: encapsulate locators and actions per page or UI component.
3. Fixtures: set up authenticated state, test data, and API clients, and tear them down.
4. API helpers: create data through the API instead of the UI, which is faster and less flaky.
5. Config and environments: base URLs, browsers, retries, and reporting per environment.
6. CI integration: sharding, artifacts, and reports.

Here is a compact example you can describe or sketch:

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

class LoginPage {
  constructor(private page: Page) {}

  async goto() {
    await this.page.goto('/login');
  }

  async login(email: string, password: string) {
    await this.page.getByLabel('Email').fill(email);
    await this.page.getByLabel('Password').fill(password);
    await this.page.getByRole('button', { name: 'Sign in' }).click();
  }
}

type Fixtures = { loginPage: LoginPage };

const test = base.extend<Fixtures>({
  loginPage: async ({ page }, use) => {
    await use(new LoginPage(page));
  },
});

test('locked account shows an error', async ({ loginPage, page, request }) => {
  const res = await request.post('/api/test-users', {
    data: { status: 'locked' },
  });
  const user = await res.json();

  await loginPage.goto();
  await loginPage.login(user.email, user.password);

  await expect(page.getByRole('alert')).toContainText('account is locked');
});

Talk through the design choices as you go. Role- and label-based locators survive CSS refactors and match how users find elements. Test data comes from an API call, so each test owns its data and can run in parallel. The assertion uses a web-first expect that retries until the condition is met, so there is no manual sleep.

In the config, mention fullyParallel, retries only in CI, a JUnit reporter for the pipeline, trace: 'on-first-retry', and projects for Chromium and WebKit. That covers the CI follow-ups.

API Testing Questions

API testing questions show up in nearly every SDET loop because most business logic lives behind APIs, and API tests are faster and more stable than UI tests. Know these cold:

• HTTP methods and idempotency: GET, PUT, and DELETE should be idempotent; POST usually is not. Be ready to explain why retrying a POST can create duplicate orders.
• Status codes: 200, 201, 204, 400, 401 vs 403, 404, 409, 422, 429, 500, 503. The 401 vs 403 distinction comes up often.
• What to assert: status code, response schema, key field values, headers like content type, and response time within a threshold.
• Negative tests: missing fields, wrong types, invalid tokens, expired tokens, and requests from a user without permission.
• Contract testing: verifying that a provider and its consumers agree on the API shape, often with tools like Pact, so teams catch breaking changes before integration.

You may be asked to write an API test live. Python with pytest and requests is a common choice:

import requests

BASE = "https://api.example.com"

def test_create_order_returns_201_and_body(auth_token):
    payload = {"sku": "ABC-123", "quantity": 2}
    r = requests.post(
        f"{BASE}/orders",
        json=payload,
        headers={"Authorization": f"Bearer {auth_token}"},
        timeout=10,
    )
    assert r.status_code == 201
    body = r.json()
    assert body["sku"] == "ABC-123"
    assert body["quantity"] == 2
    assert "id" in body

def test_create_order_without_token_returns_401():
    r = requests.post(f"{BASE}/orders", json={"sku": "ABC-123", "quantity": 1}, timeout=10)
    assert r.status_code == 401

Back-end-heavy SDET roles also test SQL for data validation. Our SQL interview questions guide covers joins, aggregation, and window functions at the level these rounds expect.

CI Integration and Flaky Tests

"How do you handle flaky tests?" is close to guaranteed in an SDET interview. A flaky test is one that passes and fails on the same code with no changes. It matters because flaky suites teach engineers to ignore red builds, which defeats the point of testing.

Name the common root causes:

• Timing and race conditions, such as hard-coded sleeps or asserting before the UI updates.
• Shared or leftover test data between tests.
• Test order dependence.
• Unstable test environments or shared staging servers.
• Unmocked third-party services, animations, and time zones.

Then describe a process, not a trick:

1. Detect. Track pass/fail history per test. Playwright's test runner, per its retries documentation, labels a test "flaky" when it fails first and passes on retry, which gives you a ready-made signal.
2. Quarantine. Move known flaky tests out of the blocking pipeline so they stop blocking merges, but keep running them and assign an owner.
3. Root-cause. Use traces, videos, logs, and network captures. Capturing traces on the first retry gives you evidence without slowing every run.
4. Fix the cause. Replace sleeps with condition-based waits, isolate test data, mock unstable dependencies.
5. Measure. Track flaky rate and time-to-fix as team metrics.

The weak answer is "I add retries." Retries hide flakiness; they are a reporting tool, not a fix.

Also know how to shard a suite, publish reports, and decide which tests block merges. Infrastructure-heavy roles ask about running browsers in containers, covered in our Kubernetes and Docker interview questions.

Coding Round Expectations for SDETs

The SDET coding round is real. At large tech companies, expect easy to medium problems on strings, arrays, hash maps, and occasionally trees: balanced brackets, parsing log lines, grouping anagrams, or a simple LRU cache.

What makes it different is the testing follow-up. After you solve the problem, expect "How would you test this?" Have a habit ready:

• List edge cases out loud: empty input, single element, duplicates, very large input, invalid types, Unicode.
• Write two or three assertions or a small unit test.

Practice with the coding interview patterns cheat sheet, and brush up on your language's idioms with the Python interview questions or JavaScript interview questions guides, depending on your stack. Some loops also add a debugging round where you find a bug in existing code; the debugging interview guide covers the method interviewers want to see.

Sample SDET Interview Questions With Short Answers

These come up repeatedly across SDET and QA automation loops.

1. What is the test pyramid? Many fast unit tests at the base, fewer integration and API tests in the middle, and a small number of slow end-to-end tests at the top. It optimizes for fast, reliable feedback.
2. Explicit vs implicit waits in Selenium? Implicit waits set a global timeout for finding elements. Explicit waits wait for a specific condition on a specific element. Prefer explicit waits and do not mix the two, since mixing can cause unpredictable timeouts.
3. What makes a good locator? Stable, unique, and tied to user-visible meaning: roles, labels, or dedicated test IDs. Avoid long XPath chains and auto-generated class names.
4. What is the Page Object Model? A pattern that wraps a page's locators and actions in a class, so tests read like user behavior and selector changes happen in one place.

When you answer, narrate your reasoning. The guide on thinking out loud applies to test design rounds as much as coding rounds.

A Two-Week SDET Interview Prep Plan

If your interview is close, focus on the rounds that carry the most weight.