The SDET interview loop, decoded

The loop has evolved over the last five years. SDETs used to get the same interview as SWEs — full LeetCode, data structures, all of it. Most companies have pulled back from that. They've realised that someone who can reverse a binary tree in a whiteboard setting doesn't necessarily write maintainable test infrastructure. The rounds have shifted toward practical problems. This is good news for people coming from a testing background. It's also confusing, because the new rounds are less standardised.

Round 1 — Live coding

The live coding round for SDETs is almost never "implement this algorithm." It's "write a function that handles some real testing scenario." Common prompts:

• Parse a log file and extract failing test names
• Write a function that retries a flaky async operation with exponential backoff
• Given a list of test results with timestamps, find the test that has the highest flake rate
• Write a type-safe wrapper around a fetch call

What they're actually checking: can you write clean, readable code that handles edge cases? Can you think out loud? Do you reach for the obvious solution first or over-engineer?

The edge cases matter as much as the happy path. If the prompt is "parse a log file," they want to see you ask: what if the file is empty? What if a line is malformed? What if the timestamp format changes?

// Canonical SDET coding prompt — retry with backoff
async function withRetry<T>(
  fn: () => Promise<T>,
  maxAttempts = 3,
  baseDelayMs = 100,
): Promise<T> {
  let lastError: unknown;
  for (let attempt = 0; attempt < maxAttempts; attempt++) {
    try {
      return await fn();
    } catch (err) {
      lastError = err;
      if (attempt < maxAttempts - 1) {
        await new Promise((res) => setTimeout(res, baseDelayMs * 2 ** attempt));
      }
    }
  }
  throw lastError;
}

When you write this live, narrate the decisions: why attempt < maxAttempts - 1 for the delay (you don't delay after the final failure), why exponential backoff (avoids thundering herd in distributed systems), what the caller is responsible for (not retrying on permanent errors).

Round 2 — System design in disguise

The system design round is usually presented as: "Design a test framework for X." X might be a payment processing system, a mobile app, a microservices API. The prompt is vague on purpose.

What they're actually asking is: do you understand the trade-offs in test architecture? Can you reason about test pyramid balance, isolation, CI run time, and maintenance cost?

Structure your answer around four questions:

1. What are we verifying? (Business-critical paths, API contracts, UI edge cases, performance thresholds)
2. At what layer? (Unit/integration/e2e — and why that distribution for this system)
3. What's the CI budget? (How many minutes can the full suite take? That determines parallelism strategy)
4. What breaks first? (In payment systems: network errors, idempotency failures. In mobile: device/OS version fragmentation)

The mistake candidates make is going straight to "I'd use Playwright for e2e and Jest for unit tests." That's the answer to a different question — framework selection comes after you've designed the coverage strategy.

Round 3 — Tool selection

"Would you use Cypress or Playwright for a React SPA?" This round feels like a trivia quiz. It isn't.

What they're testing: do you make decisions based on project constraints, or do you have a tribal preference? Can you articulate trade-offs without advocacy?

The right answer pattern is always context-first:

• What's the team's existing JavaScript/TypeScript experience?
• Is there a browser coverage requirement (cross-browser testing rules out some options)?
• Is there an existing framework already in use that would create maintenance burden to diverge from?
• What's the CI environment (Docker, GitHub Actions, bare VMs)?

Then give a recommendation based on those constraints, and name one trade-off.

"For a React SPA with a TypeScript-fluent team and no IE requirement, I'd start with Playwright. The fixture model is cleaner than Cypress's custom command approach for shared setup, and the multi-browser coverage doesn't cost extra. If the team was already heavy on Cypress and had existing command infrastructure, I'd probably stay there — migration cost outweighs feature delta for most projects."

That answer shows you've thought about real decisions, not hypothetical ones.

Round 4 — Behavioural

Behavioural rounds for SDETs have a specific flavour. The most common questions cluster around three themes:

Advocacy under resistance — "Tell me about a time you pushed for testing when the team didn't want to." What they're looking for: can you influence without authority? Do you understand the business case for testing, or just the technical one?

Trade-offs and shortcuts — "Tell me about a time you had to ship a feature with less test coverage than you wanted." What they're looking for: pragmatism. SDETs who've never shipped under pressure are less useful than SDETs who've shipped under pressure and can describe the risk trade-off they made.

Cross-functional conflict — "Tell me about a time you disagreed with a developer on approach." What they're looking for: communication style, not the outcome. Did you escalate appropriately? Did you write up the trade-off? Did you let it go when you lost the argument?

Prepare 3–4 real stories that can flex across these themes. Use the STAR format (Situation, Task, Action, Result) but don't make it stiff — "I used STAR format so now I'll say the word Task..." just makes you sound coached.

Questions you should ask back

The best candidates treat the closing Q&A as information gathering, not performance. Questions worth asking:

• "What does the oncall rotation look like for infrastructure that tests depend on?" (Tells you how mature the test infra is)
• "How do you handle flaky tests today — quarantine, delete, fix sprint?" (Tells you about engineering culture)
• "What's the ratio of SDET to SWE on the team?" (Tells you whether you'll be embedded or isolated)
• "What does the definition of done look like for a feature — is test coverage in scope?" (Tells you whether QA is gating or advisory)

These are not trick questions. They signal that you understand the operational side of the role.

POM and BDD in interviews

You will be asked about Page Object Model. You may be asked about BDD. Here's how to answer when you don't actually like them:

"POM made sense in Selenium-era Java test suites where selector management was the main problem. In modern Playwright and Cypress, fixtures and locator helpers solve the same problem with less ceremony. I've used POM, I understand why it exists, and I'd introduce it if the team was already there. I wouldn't reach for it on a greenfield project."

That's an honest, qualified answer. It's not "POM is bad." It's "POM is a tool that fits some contexts." Interviewers at companies that still use POM will push back — let them, agree that maintaining consistency matters, and note where you'd draw the line.

Same for BDD: "I've written Gherkin. I find it adds ceremony without documentation value unless the non-technical stakeholders are actively maintaining the scenarios. If they're not, it's just a layer between the test and the code. I'd use plain TypeScript with descriptive test names."

The 6-week prep timeline

If you're actively interviewing or will be within a month:

Weeks 1–2 — Live coding fluency. Write the retry function, the log parser, the flake rate calculator from scratch. Time yourself. Practice narrating decisions out loud.

Weeks 3–4 — System design vocabulary. Read one post-mortem about a test infrastructure failure. Draft a test architecture for a system you know (an e-commerce site, a mobile banking app). Present it out loud to yourself.

Weeks 5–6 — Story prep. Write down the 4 real incidents from your career that cover advocacy, trade-offs, conflict, and failure. Know the details without rehearsing the exact words.

The coding round is the one most people under-prepare. SDETs who come from manual testing backgrounds often spend all their time on the tool knowledge and arrive at the coding round unprepared. Invert that. The tools knowledge is catchable in weeks; the code fluency takes longer.