SDET interview questions (2026): what actually gets asked

An SDET interview is not a QA interview with a few code questions bolted on — it's an engineering interview where the specialism happens to be quality. Most candidates prepare for the wrong thing: they revise testing theory and get caught out by the coding and design rounds. This page maps the four rounds that actually get tested, with scenario questions by experience level and what the interviewer is really checking.

Round 1 — Coding / DSA

Especially at product companies, expect a real coding round — data structures and algorithms at a standard (not competitive-programming) level. The interviewer is checking that you can write correct, readable code under mild pressure, not that you've memorised LeetCode.

• Junior: reverse a string/array, find duplicates in a list, count word frequency, basic string parsing. Talk through edge cases out loud.
• Mid: two-pointer and hashmap problems, simple recursion, parse and validate structured input (e.g. a log line or a JSON-ish string).
• Senior: design a small reusable utility (a retry wrapper, a test-data generator), reason about time/space, and write code you'd be willing to put in a framework.

Round 2 — Framework & test design

The round most central to the role. You'll be asked to design, not just describe.

• "Design a UI automation framework from scratch — what are its components?" (Expected: Page Object Model, config/environment handling, test data, reporting, parallel execution, CI hooks.)
• "A test is flaky — walk me through how you'd diagnose and fix it." (Expected: reproduce, isolate timing vs data vs environment, fix the root cause, not add a sleep.)
• "What would you choose NOT to automate, and why?" (Senior signal: knowing automation has a cost and ROI, not automating everything.)
• "How do you structure tests so they stay maintainable as the suite grows?"

Round 3 — API, CI/CD & systems

• API: REST methods and status codes, how you'd automate and assert on an endpoint end-to-end, contract testing (overlaps the API testing interview questions guide).
• CI/CD: how you'd wire the suite into Jenkins or GitHub Actions so it runs on every change and blocks a bad merge — the SDET's signature contribution.
• Systems: reading logs/traces to tell a real product defect from a test bug; basic SQL to validate end-to-end; a little Docker.

Round 4 — Behavioural & ownership

Often underprepared. The interviewer is checking whether you reduce risk for a team, not just file bugs.

• "Tell me about a framework or tool you built and the impact it had." (Have a concrete, quantified story ready.)
• "Describe a release you helped de-risk." / "A time you disagreed with a developer about quality."
• "How do you decide a build is good enough to ship?"

The single best preparation

Across all four rounds, the candidates who do best can point to a real framework they built and talk through every decision in it. A small, running, well-documented framework on GitHub answers the coding, design, and behavioural rounds at once. If you don't have one yet, that's the highest-leverage thing to build — the how to become an SDET and automation testing roadmap guides cover how.

Where CareerIntel fits (honestly)

Knowing the questions is half of it. The other half is walking in knowing the company cold — their stack, their quality challenges, and what they actually value in an SDET — which is exactly the research most candidates skip.