If you're interviewing for an SDET (Software Development Engineer in Test) role, here's the hard truth: it's two interviews in one. You have to code like a developer and think like a test architect. Most candidates are strong at one and get filtered out on the other.
This guide gives you the 35 questions you're most likely to get asked in 2026, grouped exactly how a real loop is structured — coding, automation frameworks, API/backend testing, CI/CD, and behavioral. For the important ones, you'll get the answer and what the interviewer is actually listening for.
Practice these out loud, not just in your head. Reading answers is not the same as saying them under pressure. You can run a free AI voice mock interview on all of these at interview-prep.academy — 8,675 real questions, no credit card.
How SDET interviews are structured
A typical SDET loop has 4–5 rounds:
- Coding — a DSA problem, usually a notch easier than a pure SWE loop, but you must write clean, testable code.
- Automation / framework design — design a test framework or automate a given scenario.
- API & backend testing — REST, status codes, contract testing, mocking.
- CI/CD & systems — pipelines, flaky tests, environments.
- Behavioral — quality mindset, ownership, conflict.
The single biggest differentiator: interviewers hire the test-thinking, not just the code. When you solve a problem, narrate the edge cases you'd test. That habit alone moves you up a band.
Section 1 — Coding questions (5)
1. Reverse a linked list. Classic warm-up. Write it iteratively, then mention the recursive version and its stack trade-off. They're checking: clean code + that you discuss complexity (O(n) time, O(1) space).
2. Find the first non-repeating character in a string. Listen-for: you choose a hash map, you handle the empty-string and all-repeating edge cases out loud.
3. Merge two sorted arrays. Then the follow-up: "How would you test this function?" — name the cases: empty inputs, duplicates, one array longer, negative numbers, overflow. This follow-up is the whole interview. A SWE solves it; an SDET solves it and enumerates the test matrix.
4. Validate whether a string of brackets is balanced. Stack-based. Edge cases: empty string, unmatched closing bracket, nested types.
5. Write a function to detect a cycle in a linked list. Floyd's tortoise-and-hare. Mention how you'd unit-test it with a known cycle, a non-cyclic list, and a single node.
Section 2 — Automation & framework design (8)
6. How would you design a test automation framework from scratch? Strong answer: Start with the layers — driver/config, page objects (or screenplay pattern), test data management, reusable utilities, reporting, and CI hooks. Emphasize maintainability and parallelization. Mention separating test logic from locators so UI changes don't break everything. They're checking: do you think in systems, not scripts.
7. Page Object Model — what is it and why use it? Encapsulates page elements + actions in classes so tests reference methods, not raw selectors. Cuts maintenance when the UI changes. Bonus: mention the Screenplay pattern as a more scalable evolution.
8. How do you handle flaky tests? Root-cause categories: timing/async (fix with explicit waits, never sleep), test interdependence (isolate state), environment, and bad data. Quarantine flaky tests, track them, fix the cause — don't just add retries. This is a senior signal.
9. Explicit vs implicit waits in Selenium? Implicit = global poll for element presence; explicit = wait for a specific condition. Best practice: prefer explicit waits; mixing them causes unpredictable timeouts.
10. How do you decide what to automate vs test manually? Automate high-value, stable, repetitive, regression-prone paths. Keep exploratory, one-off, and rapidly-changing UI manual. Tie it to ROI — automation has a maintenance cost.
11. What's the test pyramid? Many fast unit tests, fewer integration tests, very few slow E2E tests. Anti-pattern is the "ice cream cone" (mostly E2E). Listen-for: you can explain why — speed, reliability, and isolation of failures.
12. How would you test a "login" feature end to end? Positive, negative (wrong password, locked account), boundary (max length, special chars), security (SQL injection, brute-force lockout), session/cookie handling, and accessibility. Breadth here wins.
13. Selenium vs Playwright vs Cypress — when would you pick each? Playwright/Cypress for modern web apps (auto-wait, speed, great DX); Selenium for broad language/browser support and legacy. Show you choose tools by context, not hype.
Section 3 — API & backend testing (6)
14. What do you check when testing a REST API? Status codes, response schema/contract, payload correctness, headers, auth, error handling, idempotency, pagination, and performance/latency.
15. Difference between 401 and 403? 401 = not authenticated (no/invalid credentials); 403 = authenticated but not authorized. A surprising number of candidates miss this — get it right.
16. How do you test an API without a finished frontend? Postman/REST clients, contract tests, mocking/stubbing dependencies, and automated suites in CI. Mention schema validation (e.g., JSON Schema / OpenAPI).
17. What is contract testing and why does it matter in microservices? It verifies that a provider and consumer agree on the API contract (e.g., Pact), catching breaking changes before integration — critical when services deploy independently.
18. How would you test for a race condition? Concurrent requests, idempotency checks, and stress/load tools; assert on data consistency after parallel writes.
19. What's the difference between mocking, stubbing, and faking? Stub = canned responses; mock = stub + verifies interactions; fake = working but lightweight implementation (e.g., in-memory DB). Precise vocabulary signals seniority.
Section 4 — CI/CD & systems (4)
20. Where do automated tests fit in a CI/CD pipeline? Unit tests on every commit; integration on merge; smoke/E2E on deploy to staging; gated promotion to prod. Fast feedback first, slow tests later.
21. How do you keep a test suite fast as it grows? Parallelization, sharding, selective/affected-test runs, removing redundant E2E, and proper test isolation.
22. How do you manage test data across environments? Factories/builders for setup, teardown after each test, seeded vs synthetic data, and never depend on prod data. Idempotent setup is key.
23. A nightly pipeline started failing intermittently. Walk me through debugging it. Reproduce, check recent changes, isolate flaky vs real failures, examine logs/artifacts, check environment drift and external dependencies. Show a systematic method, not guessing.
Section 5 — Behavioral (use the STAR method) (5)
For each, answer in Situation → Task → Action → Result, and quantify the result.
24. Tell me about a critical bug you caught before release. 25. Describe a time you disagreed with a developer about quality. (Show you advocate for quality and collaborate — not a blocker, a partner.) 26. A release is tomorrow and tests are still failing. What do you do? (Risk-based: assess severity, communicate, propose a go/no-go with data.) 27. Tell me about a time you improved a slow or flaky test suite. (Great place to show measurable impact: "cut runtime 40%.") 28. How do you advocate for quality when the team is under deadline pressure?
Plus 7 rapid-fire you should be ready for: severity vs priority, smoke vs sanity testing, what is BDD, how do you measure test coverage (and why coverage % isn't the goal), what's a good bug report, shift-left testing, and how you'd test a feature with no requirements.
The mistake that fails most SDET candidates
It's not lack of knowledge — it's answering in your head instead of out loud. In the real room you'll ramble, forget the edge cases you "obviously" know, and undersell your test thinking. The only fix is reps under realistic pressure.
That's exactly what InterviewAce is built for: pick "SDET," and run a live AI voice mock interview that asks follow-ups and grades you on five dimensions real interviewers care about — correctness, communication, problem-solving, depth, and culture fit.
Do this now: Run one free SDET mock interview out loud at interview-prep.academy. 8,675 real questions, AI voice interviews, no credit card. Then come back and re-read the questions you fumbled.
FAQ
Is SDET a coding-heavy role? Yes — expect real coding rounds, usually slightly easier than pure SWE, but you must write clean, testable code and discuss edge cases.
What's the difference between QA and SDET? SDET writes production-grade automation and tooling and is expected to code; traditional QA leans more manual/exploratory. SDET sits between dev and quality.
How long should I prepare for an SDET interview? With daily out-loud practice, 2–4 weeks for most candidates. Focus on framework design and the "how would you test this?" follow-ups — that's where loops are won.
What's the most common SDET interview mistake? Solving the code but not enumerating the test cases. Always narrate your edge cases — it's the core SDET signal.