SDET and QA Automation Engineer Interview Questions (With Answers)

“How would you test an elevator?”

I’ve watched this question trip up people who are clearly good at the job. Someone who has spent years keeping a Cypress suite alive hears “elevator” and starts firing off cases in no particular order: press the button, press it twice, what if there’s a fire, what if a kid hits every floor. Three minutes in they’re still going. The interviewer stopped writing a while ago, and the note that does get written is short: “no structure.”

That’s the odd thing about SDET interview questions. The loop keeps switching hats on you. One round wants a tester who thinks about risk and real users, the next wants a developer typing a function into a shared editor while someone asks about time complexity. My honest take? Most candidates prep one side properly and wing the other. So this guide covers both: test strategy, “how would you test X” questions, framework design, API testing, flaky tests in CI, the coding round, and a couple of behavioral stories.

Quick note: the sample answers below are made up to show shape, not lifted from anyone’s real job, so swap in your own stories (and anything about how Selenium or Playwright behaves matches their official docs as of October 2026).

What SDET interviews look like

Titles vary (SDET, QA automation engineer, software engineer in test, test engineer), and so do the loops. Most still mix four kinds of rounds.

There’s usually a coding round, often easier than the software engineer version but not trivial. Then a test design round, where you’re handed a feature or an object and asked how you’d test it. Many companies add a framework or automation round, where you talk through how you’d structure a suite, or debug one. And there’s almost always a behavioral round, which for testers loves questions about bugs that escaped and arguments about release quality.

The balance depends on the company. A team that hires SDETs as developers who specialize in testing will push harder on coding. A team hiring a QA automation engineer for a web product will spend more time on Selenium or Playwright and on API tests. Read the job description closely. It usually tells you which one you’re walking into.

Test strategy questions and the test pyramid

Expect at least one of these early. They’re the questions that show whether you think about testing as a system or as a pile of scripts.

• How do you decide what to automate and what to leave manual?
• Explain the test pyramid. Do you agree with it?
• How would you build a test strategy for a new microservice?
• What’s the difference between smoke, sanity and regression testing?
• How do you decide when a release is ready?
• Shift-left testing: what does it actually mean on a team?

“Explain the test pyramid.” The idea, popularized by Mike Cohn, is simple: lots of fast, cheap unit tests at the bottom, fewer integration or service tests in the middle, and a small number of slow end-to-end UI tests at the top. The reason is cost. A UI test is slow, breaks when a button moves, and tells you something’s wrong without saying where.

The shape matters more than the exact layer names. Push each check as low as it can go.

Then give an opinion, because the follow-up is almost always “do you agree?” Mine: the pyramid is a good default and a bad law. For a UI-heavy app with thin backend logic, a fatter middle of component and API tests often pays off more than piling up unit tests for getters. What I’d never accept is the inverted version, the “ice cream cone,” where hundreds of end-to-end tests do all the work and the suite takes two hours.

“What do you automate?” Things that run often, are stable, and would hurt if they broke: login, checkout, the core API contracts. Leave manual (or exploratory) the things that change every sprint, need human judgment about look and feel, or run once. A short answer with a reason beats a long list.

For deeper unit and TDD questions, our guide to software testing and TDD interview questions goes further into mocking and test design.

“How would you test X?” questions

This is the round where structure wins. The object might be an elevator, a pen, a login page, a URL shortener, or a vending machine. The approach is the same.

Start with questions. Who uses it? What does it need to do? Are there limits on weight, speed, input length? Then sort your test ideas into groups out loud, so the interviewer can follow: functional, boundary and negative cases, performance and load, security, usability and accessibility, and recovery from failure.

Break the elevator into floors of concern: function, limits, safety, failure. Then test each floor.

Here’s how a strong elevator answer sounds, condensed. “First I’d ask how many floors, the weight limit, and whether it’s passenger or freight. Then functional: call it from each floor, choose a floor inside, check it stops level with the floor and the doors open. Boundaries: exactly at the weight limit, one kilo over, pressing every button at once. Safety: door sensors when something blocks them, the emergency stop, the alarm. Failure: power loss mid-trip, what state it recovers to. Then load: rush hour with every floor calling. I’d prioritize safety first, because that’s where a bug hurts people.”

For a software example like a login page, the same groups apply, plus the things only software has: SQL injection and XSS in the inputs, rate limiting on failed attempts, password field masking, session expiry, what happens with two tabs open. Mention accessibility (can you log in with only a keyboard?) and you’ll stand out, because most candidates forget it.

Framework design questions

Senior SDET interviews spend real time here. You might be asked to sketch a framework on a whiteboard, or to explain the one you built.

• How would you design a UI automation framework from scratch?
• What’s the Page Object Model, and what are its downsides?
• Selenium or Playwright for a new project? Why?
• How do you handle waits and synchronization?
• How do you manage test data and environments?
• How do you run tests in parallel safely?

“How do you handle waits?” This is a favorite because bad answers are so common. Never Thread.sleep() as a fix. In Selenium, use explicit waits on a specific condition, like an element being clickable. Selenium’s own documentation warns against mixing implicit and explicit waits, since it can cause unpredictable wait times. In Playwright, actions auto-wait for the element to be visible, stable and enabled before acting, and its web-first assertions retry until a timeout, so most manual waits just disappear.

That leads straight into the tool question. My honest take: for a new web project, I’d lean Playwright for the auto-waiting, the built-in tracing and the easy parallel runs. I’d keep Selenium where there’s a big existing suite, a grid already in place, or a team with years of WebDriver skill. Interviewers don’t care much which one you pick. They care that you can name the trade-off.

Page Object Model: each page or component gets a class that hides its locators and exposes actions like login(user, password). Tests read like intent, and when the UI changes you fix one file. The downside people rarely mention is that page objects bloat into giant classes with forty methods. Saying you’d split them into smaller components shows you’ve maintained one, not just read about it.

For test data, my preference is that each test creates what it needs through an API call and cleans up after itself. Shared, hand-made test accounts are how one test’s leftovers break another test at 2 a.m.

API testing questions

Most SDET roles now test services more than screens, so expect a few of these.

• What would you check when testing a REST endpoint?
• How do you test an endpoint that depends on three other services?
• What’s contract testing, and when is it worth it?
• 401 vs 403: what’s the difference?
• How would you test idempotency on a payment API?

For a REST endpoint, go beyond “status 200.” Check the status code, the response schema, the actual values, headers, error responses for bad input, auth (401 when you’re not logged in, 403 when you are but aren’t allowed), and how it behaves with large or empty payloads. For dependencies, stub or mock them for fast tests, then keep a smaller set of tests running against real services in a shared environment. Contract tests (Pact is the common example) let a consumer and provider agree on the shape of requests without spinning up everything, which is worth it once several teams depend on the same API. If API design comes up from the other side, our post on API design interviews covers it.

Flaky tests and CI questions

Every SDET has a flaky test story, and interviewers know it.

• A test passes locally and fails in CI one time in ten. How do you debug it?
• Should you retry failing tests automatically?
• Where do your tests run in the pipeline, and how long should that take?
• How do you keep a growing suite fast?

A flaky test is a signal nobody trusts. After a while the trains just stop waiting for it.

For the one-in-ten failure, list causes before fixes. Timing (an element or a response that isn’t ready), shared state between tests, test order dependence, real time and time zones, network calls to unstable services, and differences between your laptop and the CI machine, like screen size or CPU. Then say how you’d narrow it down: run it in a loop, run it in isolation versus with the suite, grab logs, screenshots or a Playwright trace from the failing run.

On retries, I’d allow them as a short-term patch with the test flagged and tracked, never as a permanent fix. Silent retries teach the team to ignore red builds, and that’s worse than the flake itself. Quarantine the test, give it an owner, and fix or delete it.

The coding round for SDETs

Don’t skip coding prep. Many SDET loops include a real coding round, typically arrays, strings, hash maps and the occasional tree, at an easier level than the main engineering loop. Some add a test-flavored twist: write a function and then write the tests for it, or find the bugs in a given piece of code.

The twist is where SDETs can shine. When you finish your solution, test it out loud without being asked: empty input, one element, duplicates, very large input. Our list of coding interview patterns covers the common problem types.

Behavioral SDET questions, with STAR answers

Behavioral rounds for testers keep coming back to a few themes: a bug that escaped, a release you pushed back on, and convincing developers to care about quality. Two fictional examples in two voices. For timing and structure, see our STAR method guide.

A bug that escaped is a crack someone has to own. The good stories are about the barrier you put up afterwards.

“Tell me about a bug that reached production.” (A QA automation engineer, structured.)

Situation: “This was a mobile release. A day or so after it went out, support started forwarding tickets from users in a few European countries saying checkout just wouldn’t finish. Meanwhile our whole automated suite was green.”

Task: “Checkout tests were mine. So, partly my miss. I wanted to know how we didn’t see it, and I really didn’t want to be having the same conversation three months later.”

Action: “Took me most of a day to find, honestly. Prices like 12,99 were getting parsed wrong, because a lot of locales use a comma as the decimal separator. And every single test account we had was set to US English. Every one. So I set up test users for a handful of locales, German, French, Brazilian Portuguese, and parameterized the checkout tests to run under each of them. I also put a currency formatting check on the API, so if this broke again we’d know in seconds instead of waiting for a UI test to tap through five screens. In the incident review I said up front that it was a gap in my test data, not the developer’s fault. That was true, and it kept the meeting from turning into a blame thing.”

Result: “Over the next few months those locale runs caught two more formatting bugs before they shipped. The part I liked more, though: people started asking ‘which locales does this touch?’ in planning without me bringing it up.”

“Describe a time you pushed back on a release.” (An SDET, more casual.)

“So, release was Thursday. Wednesday afternoon I’m poking at the payment retry code and I notice that if the network times out at the wrong moment, the customer gets charged twice. Not every time. Maybe one run in twenty on our test environment, which is exactly the kind of number people shrug at. The PM wanted to ship, and I get it, a lot was riding on that release. But ‘I’ve got a bad feeling about this’ doesn’t win that argument. So I wrote a test that forced the timeout on purpose, ran it until it failed, and pulled up the logs: two charges, same order. Then I did a rough estimate of how many real users would hit it in a week. That changed the mood in the room pretty fast. My suggestion was to ship everything else on Thursday and keep the retry change behind a feature flag. Nobody fought that. The developer added an idempotency key the following week and it went out clean. If I had to boil it down? A test that fails on demand beats any amount of arguing.”

Practicing with OfferBull

You can read every question here and still freeze on “how would you test a pen?” The skill isn’t knowing test types. It’s laying them out calmly, in order, while someone interrupts with “okay, what about at minus twenty degrees?”

That’s what OfferBull is built for. It’s an AI mock interview app for iOS and Android: an interviewer voice asks questions out loud and you answer by speaking. Paste the job description or upload your resume and you get questions that match the role, so a Playwright and API testing job won’t drill you on mobile device labs. It asks follow-ups based on your answers, the way a real interviewer would push on your flaky-test story. If you get stuck while practicing, it can show answer suggestions and a STAR structure. Practice in English or Chinese.

Use it in the weeks before your interview. In the interview itself, it’s just you and the elevator.

Start an AI mock interview

FAQ

Is an SDET interview easier than a software engineer interview? The coding round is often a bit easier, but the loop isn’t. You’re also judged on test design, automation architecture and quality judgment, which software engineer loops mostly skip.

Which language should I use for the coding round? The one you write tests in every day, usually Java, Python, JavaScript or TypeScript. Fluency beats picking a “better” language you’re shaky in.

Do I need to know both Selenium and Playwright? Know one well and the other well enough to compare. If the job description names one, go deep on that one.

---

Practice This Out Loud

Tonight, set a three-minute timer and answer “how would you test a login page?” out loud, sorting your ideas into groups as you go. Then tell your best flaky-test story in under two minutes. If both hold up, try them in a voice mock interview that asks follow-ups. → Practice Now