---
title: SDET Interview Questions and Answers (2026)
description: SDET interview questions and answers — coding rounds, test framework design, automation strategy, flaky tests, API and CI integration, with worked examples.
url: https://usegreenroom.app/blog/sdet-interview-questions
last_updated: 2026-08-01
---

← Back to blog

Technical

# SDET interview questions and answers

August 1, 2026 · 13 min read

![SDET interview questions and answers — software development engineer in test guide cover from Greenroom, the AI mock interviewer](/assets/blog/sdet-interview-questions-hero.webp)

"Reverse a linked list." He blinked. He had spent six years writing excellent Selenium suites, had opinions about page object design that were genuinely worth hearing, and had prepared thoroughly for a testing interview. Nobody had told him that the S in SDET stands for software, and that the first round would be indistinguishable from a developer's.

That is the single biggest gap in how people prepare for **SDET interview questions**. A software development engineer in test is hired as an engineer with a testing specialisation, so the loop contains a real coding round, a framework design round that is essentially object-oriented design, and only then the testing-specific material. This guide covers all of it, in the order it arrives.

## The SDET interview loop

- **Coding round** — LeetCode easy-to-medium: arrays, strings, hash maps, occasionally a tree or a simple graph. Clean, readable code matters more than optimality here.
- **Test design round** — given a feature, enumerate what you would test and, importantly, what you would not.
- **Automation framework design round** — object-oriented design applied to a test suite.
- **API and CI integration round** — contract testing, mocking strategy, and where each suite runs.
- **Behavioral round** — a bug that escaped to production, and what changed as a result.

![Diagram of the SDET interview loop — coding round, test design round, automation framework design round, API and CI integration round and behavioral round](/assets/blog/sdet-interview-questions-diagram.webp)

An SDET loop is a developer loop with a testing specialisation on top — which is exactly why the coding round surprises people from manual QA backgrounds.

Our [QA tester interview questions](/blog/qa-tester-interview-questions) guide covers the manual and process side, and [Selenium interview questions](/blog/selenium-interview-questions) covers the tool most loops still ask about.

## The coding round

Take it seriously. String manipulation, frequency counting with hash maps, two pointers, sorting with a custom comparator, basic recursion. Nothing exotic — but you will be judged on naming, structure and whether you wrote it like someone who maintains code.

An SDET-flavoured twist appears often: "write a function and then write the tests for it." That is the round in miniature, and the tests are graded as heavily as the function.

```code:py
def parse_duration(text):
    # '1h30m' -> 5400 seconds. Raises ValueError on malformed input.
    import re
    m = re.fullmatch(r'(?:(\d+)h)?(?:(\d+)m)?(?:(\d+)s)?', text.strip())
    if not m or not any(m.groups()):
        raise ValueError(f"bad duration: {text}")
    h, mi, s = (int(g) if g else 0 for g in m.groups())
    return h * 3600 + mi * 60 + s

# the tests are the actual interview — cover boundaries, not just the happy path
def test_parse_duration():
    assert parse_duration('1h30m') == 5400
    assert parse_duration('45s') == 45
    assert parse_duration('0m') == 0            # zero is valid, not falsy-empty
    for bad in ['', 'abc', '1x', '  ', '1h30']:
        try:
            parse_duration(bad)
            assert False, f"expected ValueError for {bad}"
        except ValueError:
            pass
```

Say the categories out loud as you write them: happy path, boundaries, invalid input, and the ambiguous case you would go and ask about. That narration is what distinguishes an SDET from a developer who writes two tests.

## The test design round

You get a feature — a login page, a file upload, a search box, a payment flow — and are asked what you would test.

Answer by category rather than as a list, because the categories are the skill:

- **Happy path**, briefly. Everyone gets this.
- **Boundaries.** Zero, one, maximum, maximum plus one, empty, and the field length limit.
- **Invalid and malicious input.** Wrong types, injection strings, unicode, very long values.
- **State and sequence.** Double submission, back button, refresh mid-flow, session expiry, concurrent edits from two tabs.
- **Environmental.** Slow network, offline, permission denied, third-party dependency down.
- **Cross-cutting.** Accessibility, localisation, and the device or browser matrix.
- **What you would not automate**, and why. This is the answer that marks a senior candidate: exploratory testing, one-off migrations, and anything whose maintenance cost exceeds the risk it covers.

Be ready for "how would you test a file upload?" specifically — it is the most commonly asked version, and the good answer covers file size limits, type validation done server-side not just client-side, corrupted files, interrupted uploads, concurrent uploads, and what happens to a partial file.

## The framework design round

This is object-oriented design in testing clothes, and it is where SDET candidates from a scripting background struggle.

- **Page object model**, and its honest limits — page objects should expose actions rather than raw elements, and they should not contain assertions.
- **Test data management.** Fixtures versus factories, how you avoid tests that depend on each other's data, and how you keep a suite runnable against a shared environment.
- **Independence and idempotency.** Every test must set up and tear down its own state so it can run alone, in any order.
- **Parallelism.** What breaks when you run fifty tests concurrently — shared accounts, shared data, ports, and fixed sleeps.
- **Waits.** Explicit waits over implicit, and never `sleep`. Expect to be asked why: fixed sleeps are simultaneously too slow on a fast machine and too short on a slow one, which is the definition of flaky.
- **Reporting and failure diagnosis.** Screenshots, logs, traces and a failure message that tells you what went wrong without re-running it.
- **Layering.** A thin test layer, a business-action layer, and a driver layer — so a UI change touches one file rather than eighty.

## Flaky tests, the recurring question

**"How do you handle a flaky test?"** The answer that scores: quarantine it out of the blocking path immediately so it stops eroding trust, assign an owner and a deadline, and fix the root cause — which is almost always timing, shared state, test order dependence, or an unreliable environment.

Blanket retries are the common wrong answer because they hide real failures. If retries are used, they must be visible and tracked so flakiness is measurable.

Then add the point that makes it a senior answer: **a suite people do not trust is worse than no suite**, because a red build that everyone ignores means a real failure ships. Our [CI/CD interview questions](/blog/ci-cd-pipeline-interview-questions) guide covers the pipeline side.

## API testing and the pyramid

- **The test pyramid** — many fast unit tests, fewer integration tests, very few end-to-end. Know it, and know the honest critique: for some products the middle layer matters more than the shape suggests, and the trophy shape is a defensible alternative.
- **Contract testing** for services that deploy independently, so a consumer's expectations are verified without a full end-to-end run.
- **Mocking strategy.** What to mock, what not to, and why mocking everything produces a suite that passes while the product is broken.
- **API test coverage** — status codes, schema validation, auth and authorisation paths, pagination, rate limits, and idempotency. Our [REST API interview questions](/blog/rest-api-interview-questions) guide covers the contracts.
- **Where each suite runs.** Unit on every commit, integration on every PR, end-to-end on merge or on a schedule. Being specific here shows you have owned a pipeline.

**The core truth:** SDET loops are engineer loops. The candidates who struggle are not the ones who know less about testing — they are the ones who prepared only for testing questions and met a linked list in round one.

## The behavioral round

The reliable question is about a bug that reached production. Have one ready: what it was, why the tests did not catch it, how it was found, and — the part that matters — the specific change you made so that class of bug could not escape again.

"We added more test cases" is weak. "We added a contract test between the two services and a schema check in CI, because the root cause was an unannounced field type change" is the answer.

## Where each prep option actually helps

- **LeetCode** — easy-to-medium, genuinely required. This is the most commonly skipped preparation for this role.
- **Build a framework from scratch** — even a small one with page objects, fixtures, parallel execution and reporting. It answers the framework round for you.
- **The Playwright and Cypress documentation** — modern loops increasingly ask about these rather than only Selenium, especially their auto-waiting and trace tooling.
- **Java or Python fundamentals** — collections, exceptions and OOP, since the framework round is object-oriented design. Our [Java interview questions](/blog/java-interview-questions) guide covers the most common language for this role in India.
- **ChatGPT** — good for generating test-case enumeration practice on a feature description. It will not tell you your framework design has no layering.
- **Greenroom** — the spoken layer. [Ari, the AI interviewer](/) runs the test design and framework rounds out loud, where the answer is a spoken enumeration rather than code. Honest tradeoff: Ari will not run your suite, so build one.

For the fundamentals underneath the automation layer, see our [unit testing interview questions and answers](/blog/unit-testing-interview-questions) guide, covering test doubles, coverage and testing untestable code.

## Frequently asked questions

### What is the difference between QA and SDET?

A QA engineer focuses on test strategy, execution and quality process, often with a mix of manual and automated work. An SDET is hired as a software engineer with a testing specialisation, which means they write production-quality code, design and own automation frameworks, and are expected to clear a real coding round. The practical consequence for interview preparation is that an SDET loop opens with an algorithm question rather than a testing question.

### Do SDET interviews include DSA and coding rounds?

Yes, almost always. Expect LeetCode easy-to-medium problems covering arrays, strings, hash maps, two pointers, sorting with a custom comparator and basic recursion, judged on readability and structure as much as optimality. A common SDET-specific variant is being asked to write a function and then write the tests for it, where the test cases are graded as heavily as the implementation.

### How do you answer how would you test a login page or file upload?

Answer by category rather than as a flat list, because the categories are the skill being assessed. Cover the happy path briefly, then boundaries such as zero, one, maximum and maximum plus one, invalid and malicious input, state and sequence issues like double submission and session expiry, environmental conditions such as slow or offline networks and a dependency being down, and cross-cutting concerns like accessibility and localisation. Finish by saying what you would not automate and why.

### How do you handle flaky tests as an SDET?

Quarantine the test out of the blocking path immediately so it stops eroding trust in the suite, assign an owner and a deadline, and fix the root cause — usually timing, shared state, test order dependence or an unstable environment. Blanket retries are the common wrong answer because they hide real failures, and the point that makes this a senior answer is that a suite nobody trusts is worse than no suite, since an ignored red build means real failures ship.

### What is asked in an SDET automation framework design round?

It is object-oriented design applied to testing. Expect page objects that expose actions rather than raw elements and contain no assertions, test data management via fixtures or factories with no inter-test dependencies, full independence so any test can run alone in any order, what breaks under parallel execution, explicit waits instead of fixed sleeps and why, failure reporting with screenshots and traces, and layering so a UI change touches one file rather than eighty.

### What is the test pyramid and is it still relevant?

The test pyramid describes many fast unit tests, fewer integration tests and very few end-to-end tests, on the basis that cost and fragility rise as you move up. It remains a useful default, and the honest critique worth mentioning is that for service-heavy or integration-heavy products the middle layer carries more value than the shape implies, which is why the testing trophy is a defensible alternative for some codebases.

SDET loops open with a coding round and turn on spoken test enumeration. [Greenroom](https://usegreenroom.app/) runs the design and behavioral halves out loud with Ari, who asks what you would deliberately not automate. Free to start. Curious how it works? See [how AI mock interviews work](/blog/ai-mock-interview).