Top SDET Interview Questions and Answers

An SDET (software development engineer in test) interview sits between a QA interview and a software engineering interview. You’ll be asked about testing like a QA engineer, and asked to code like a developer. Most candidates prepare well for one half and get caught out by the other. This guide covers the questions that come up most in each round, with short sample answers you can adapt.

The short answer: most SDET interviews have five parts, and these are the questions to prepare for each:

1. Coding: string, array and hash map problems, plus writing tests for your own code.
2. Automation frameworks: how you’d design one, page object model, waits, flaky tests.
3. API testing: status codes, contract testing, tools like Postman and REST Assured.
4. CI/CD: running tests in a pipeline, parallel runs, test reports.
5. Testing concepts and scenarios: the test pyramid, test strategy, “how would you test this?”

If you’re still deciding between the two roles, read QA engineer vs SDET first.

Automation framework questions

1. How would you design a test automation framework from scratch?

“I’d start with what we’re testing and who will maintain it. For a web app with a REST backend, I’d use Playwright with TypeScript for UI tests and a lightweight HTTP client for API tests, in the same repo. The structure would be: page objects for UI interactions, a separate layer for API clients, test data factories so each test creates its own data, config per environment, and tests that read like user journeys. Reporting goes to HTML and to the CI dashboard, and the whole suite runs in parallel on every pull request, with a smaller smoke set on deploy.”

What they’re listening for: layering, maintainability, test data strategy, CI, and that you’d choose tools for a reason.

2. What is the page object model?

A design pattern where each page or component of the app gets a class that holds its locators and actions. Tests call methods like loginPage.signIn(user) instead of repeating selectors. When the UI changes, you fix one class instead of fifty tests.

3. Selenium vs Playwright vs Cypress: which would you pick?

• Selenium: the most mature, supports many languages and browsers, and suits large Java or Python teams with existing suites.
• Playwright: fast, auto-waits for elements, supports Chromium, Firefox and WebKit, and has strong tooling for tracing and parallel runs.
• Cypress: a great developer experience for JavaScript front-end teams, runs in the browser, with more limits on multiple tabs and cross-origin flows.

Good answer: “It depends on the team’s language and the app, but for a new web project I’d lean to Playwright because of auto-waiting and built-in parallelism.”

4. How do you handle waits?

Never use fixed sleeps. Use explicit waits for a specific condition (element visible, network call finished), or tools that wait automatically. Fixed sleeps make suites slow and still flaky.

5. How do you deal with flaky tests?

“First I measure it: rerun the suite and track which tests fail intermittently. The usual causes are timing, shared test data, tests that depend on order, and unstable environments. I fix the cause with proper waits, unique test data per test and independent tests. While I’m fixing it, I quarantine the test from the blocking pipeline so it doesn’t teach the team to ignore red builds. Automatic retries hide the problem, so I use them sparingly and report retried passes.”

6. What should you automate, and what shouldn’t you?

Automate stable, repeated, high-value checks: regression, smoke tests, API contracts, data-driven cases. Don’t automate one-off checks, features that change weekly, or anything that needs human judgement, like whether a layout looks right. Exploratory testing stays manual.

API testing questions

7. How do you test a REST API?

Check status codes, response body and schema, headers, error handling for bad input, authentication and permissions, and performance under load. Test positive, negative and boundary cases. Our full list of API testing interview questions goes deeper, and what is API testing covers the basics.

8. What’s the difference between 401 and 403?

401 means the request isn’t authenticated (no valid credentials). 403 means the user is authenticated but not allowed to do this.

9. What is contract testing?

Testing that a service and its consumers agree on the shape of requests and responses, so a provider change can’t silently break a consumer. Pact is a common tool for this.

CI/CD questions

10. How do you run tests in a CI pipeline?

“Unit and API tests run on every pull request and block the merge. The UI suite runs in parallel across several workers on merge to main. A short smoke suite runs after each deploy to staging and production. Failures post to the team channel with a link to the report, screenshots and traces.”

11. How would you cut a test suite from 60 minutes to 10?

Run tests in parallel, move checks down the pyramid (from UI to API or unit level), remove duplicate tests, reuse logged-in sessions instead of logging in through the UI every test, and split a fast smoke suite from a nightly full run.

Testing concept questions

12. Explain the test automation pyramid

Many fast unit tests at the base, fewer API and integration tests in the middle, and a small number of end-to-end UI tests at the top. UI tests are slow and fragile, so you keep them for critical user journeys.

13. What’s the difference between a test case, a test scenario and a test plan?

A scenario is what to test (“user resets a password”), a test case is the exact steps and expected result, and a test plan is the overall document: scope, approach, environments and schedule. See test case vs test scenario vs test plan.

14. How would you test a login page?

Cover valid login, wrong password, unknown user, empty fields, password masking, lockout after repeated failures, “remember me”, password reset, SQL injection and script injection in inputs, session timeout, and behaviour on mobile and slow networks. Then say which you’d automate (most of it) and which you’d test by hand.

Coding questions

Expect easy to medium problems. Common ones:

• Reverse a string or the words in a sentence.
• Find duplicates in an array.
• Check whether two strings are anagrams.
• Count the frequency of each character.
• Find the first non-repeating character.
• Parse a log file and count errors by type.

The SDET twist: after you code it, they’ll often ask, “How would you test this function?” Have a list ready: empty input, one element, duplicates, very large input, special characters, null.

Example: first non-repeating character (Python)

Count each character in one pass with a dictionary, then return the first character whose count is 1. That’s O(n) time. Tests: "aabbc" returns "c", "aabb" returns none, "" returns none, "x" returns "x".

Scenario and behavioural questions

• “A release is tomorrow and you’ve found a critical bug. What do you do?”
• “Developers say testing slows them down. How do you respond?”
• “Tell me about a bug that reached production. What did you change afterwards?”

Answer behavioural ones with a short story and a clear result. The structures in interview answer frameworks help.

How to prepare in two weeks

1. Days 1 to 5: one coding problem a day in your main language, then write tests for it.
2. Days 6 to 8: build a small framework against a public demo site: page objects, a few API tests, a CI workflow. Put it on GitHub; it’s the best portfolio piece an SDET can have.
3. Days 9 to 11: revise API testing, CI/CD and the test pyramid.
4. Days 12 to 14: mock interviews, and tailor your resume to each listing’s tools. If it says Playwright and TypeScript, those words should be in your top bullets, if they’re true. Tailr is a Chrome extension that does this from the job listing you’re viewing, using only your real experience, and tracks every application you send.

For the testing basics behind all this, see our top QA interview questions.

Try Tailr

Conclusion

SDET interviews test two skill sets at once: you need to code cleanly and think like a tester. Prepare easy-to-medium coding problems and always be ready to test your own code, be able to design a framework out loud, know API testing and CI well, and explain how you’d fix flaky tests. Build one small framework project before the interview, and you’ll have a real example for almost every question they ask.