SDET Interview Preparation: A 6-Week Plan

SDET interviews are broad. In a single loop you can be asked to reverse a string, design a page object model, explain why a test is flaky, validate a JSON response, sketch a test strategy for a payments service and describe a time you disagreed with a developer. Preparing for all of that at once is overwhelming, so most candidates either over-prepare one area (usually coding puzzles) or improvise everything.

This plan spreads preparation across six weeks at roughly an hour or two on weekdays and a longer session at the weekend. Adjust the pace to your situation: compress it if you have an interview booked, or stretch it if you are preparing ahead of a job search. The structure matters more than the exact timing.

The rounds you are preparing for

Interview loops vary by company and level, but most SDET processes combine some of the following.

Recruiter or hiring manager screen

A conversation about your background, the role and logistics. Expect “walk me through your current framework” and questions about the tools on your CV. The goal is to show you can explain your work clearly and that your experience matches the job description.

Coding round

Usually in the language you will use day to day (Java, JavaScript or TypeScript, or Python). For SDET roles, problems tend to be practical rather than heavily algorithmic: string and array manipulation, maps and sets, parsing, simple recursion, and occasionally a classic data structure question. Interviewers watch how you clarify requirements, test your own code and handle edge cases, which is where testers can stand out.

Automation and framework round

The core of most SDET loops. You may be asked to write a UI test live, explain locator strategy and waits, discuss page objects and fixtures, or design a framework from scratch. Senior candidates are expected to discuss parallelism, test data, reporting, CI integration and maintainability.

API testing round

HTTP methods and status codes, idempotency, authentication versus authorisation, schema validation, and writing tests with REST Assured, Playwright’s request context or Postman. Some interviewers give you an API and ask what you would test.

System design for SDET

Increasingly common at mid and senior levels. You are given a system (a checkout service, a ride-booking app, a notification pipeline) and asked how you would test it: risks, test layers, environments, test data, observability, release gates. It is less about drawing boxes and more about structured risk-based reasoning.

Behavioural round

How you work with others: handling disagreements, pushing back on a release, owning a production bug, improving a process. Answers need to be specific stories, not principles.

Before week 1: gather your inputs

Spend an evening on these, because they shape everything else:

• Collect three or four job descriptions for roles you want. Highlight the languages, tools and responsibilities that repeat. That list is your syllabus.
• Audit your CV against them. The ATS resume checker shows which keywords from a job description your CV is missing. The skills gap checklist helps turn those gaps into a study list.
• Choose one primary language and stick with it for coding practice. Switching between Java and JavaScript mid-preparation costs more than it gains.
• Do one mock interview cold. Use the Mock Interview before studying anything. It gives you an honest baseline and tells you which weeks to stretch.

Week 1: foundations and language fluency

Goal: remove friction in your primary language and refresh testing fundamentals.

• Language basics you will need under pressure: strings, arrays or lists, maps, sets, iteration, sorting with comparators, exceptions, and (for JavaScript) promises and async/await.
• Work through ten to fifteen of the easier JavaScript Challenges, or the equivalent exercises in your language. Focus on writing clean code that handles empty input, duplicates and boundaries.
• Review testing fundamentals: test levels, the test pyramid and its critics, black-box techniques (equivalence partitioning, boundary values, decision tables), severity versus priority.
• Read through the testing fundamentals questions and manual testing questions. Answer each out loud before reading the answer.

End-of-week check: can you solve an easy string or array problem in your language in under 20 minutes, while talking through edge cases?

Week 2: coding patterns

Goal: build a repertoire of patterns that cover most SDET coding questions.

• Frequency counting with maps (anagrams, first non-repeating character, duplicates).
• Two pointers (palindromes, reversing, merging sorted arrays).
• Sliding window for substrings and subarrays.
• Parsing and transforming data: JSON, CSV lines, log entries. This is where SDET interviews diverge from generic developer interviews.
• Basic recursion and working with nested structures (flattening arrays, traversing nested objects).

For each problem, practise the same routine: restate the problem, ask clarifying questions, list test cases before coding, write the solution, then walk through your test cases. Interviewers notice when a tester tests their own code.

If you work in JavaScript, spend time on the async and closure challenges as well. Predict-the-output questions on the event loop are common; the article on async JavaScript for testers covers the patterns.

End-of-week check: two medium problems in a row, each in about 30 minutes, with tests stated up front.

Week 3: UI automation depth

Goal: be able to write and defend UI automation code live.

• Locator strategy: why role-based and test-id locators beat long XPath or CSS chains. See the Playwright locators guide.
• Synchronisation: auto-waiting and web-first assertions in Playwright, explicit waits and why not to mix implicit and explicit waits in Selenium. See Selenium waits explained.
• Page objects, fixtures and test isolation.
• Flaky tests: causes and a diagnosis workflow. Interviewers love this topic because it reveals real experience. See the flaky tests field guide.
• Hands-on: complete challenges in the Playwright Lab or the Selenium Lab, depending on the role.
• Questions: Playwright, Selenium or Cypress.

End-of-week check: write a login-and-verify test from scratch without documentation, then explain every locator and wait you chose.

Week 4: API testing and data

Goal: be fluent with HTTP and able to design an API test suite on the spot.

• HTTP semantics: methods, status codes, headers, idempotency, caching basics.
• Authentication flows (API keys, bearer tokens, OAuth 2.0 at a conceptual level) and authorisation testing, including IDOR.
• Writing tests in your stack: REST Assured, Playwright’s request fixture, or Postman with scripts.
• Schema validation, negative testing, pagination and error formats. The API testing checklist is a good structure for “what would you test on this endpoint?”
• SQL for verification: joins, aggregations, finding duplicates. Many loops include at least one query.
• Practise against the API Playground and review the API testing and SQL questions.

End-of-week check: given an endpoint description, list at least fifteen distinct test ideas in ten minutes, grouped by category.

Week 5: framework design and system design

Goal: handle the senior-level conversation.

Framework design

Be ready to design a framework on a whiteboard: layers (tests, page objects or API clients, utilities, configuration), test data strategy, environment configuration, parallel execution, reporting, CI integration, and how you keep it maintainable as the team grows. Work through the framework design questions.

System design for SDET

Practise with a simple structure you can apply to any system:

1. Clarify the system, users and critical flows.
2. Identify risks: what would hurt users or the business most if it broke?
3. Choose test layers: unit, component, contract, API, UI, performance, security. Justify what goes where.
4. Plan environments and test data: what is mocked, what is real, how data is created and cleaned up.
5. Define release gates and observability: what blocks a deploy, and how you detect problems in production.

Do three practice designs this week, out loud, with a timer. The system design for SDET questions and CI/CD questions are good prompts.

Week 6: behavioural stories, mocks and polish

Goal: convert knowledge into calm, structured answers.

• Write six to eight stories using a simple structure such as STAR (Situation, Task, Action, Result). Cover: a hard bug you found, a flaky suite you fixed, a disagreement with a developer or manager, a time you pushed back on a release, a process you improved, a mistake you made and what changed afterwards.
• Make results concrete and honest. If you do not have a measured number, describe the observable outcome instead (“the team stopped re-running the pipeline by habit”) rather than inventing one.
• Do at least three full mock interviews, mixing topics. Review your weakest answers and redo them the next day.
• Re-run your end-of-week checks from weeks 1 to 5 and spend remaining time on whichever failed.
• Polish your CV with the resume builder so the framework you describe in interviews is visible on paper.

How to talk about your framework

“Tell me about your framework” appears in almost every SDET interview, and many candidates answer with a list of tools. A stronger answer follows the same arc as a design discussion:

1. Context: what the product is, what the team looks like, and what problem the framework solves.
2. Architecture: the main layers and why they exist. For example: “tests call page objects and API clients; test data is created through the API in fixtures; configuration comes from environment variables.”
3. Key decisions and trade-offs: why this tool, why this structure, what you deliberately did not do.
4. Reliability and speed: how you handle waits, flakiness, parallel runs and test data isolation.
5. Integration: where it runs in CI, what blocks a merge or release, how results are reported.
6. Your contribution: be precise about what you built versus what you inherited.
7. What you would change: this shows judgement, and interviewers often ask anyway.

Rehearse a two-minute version and a ten-minute version. The two-minute version is for screens; the ten-minute version is for the framework round, where the interviewer will interrupt with follow-up questions.

Questions to ask your interviewers

Your questions are part of the assessment, and they are your chance to find out whether you want the job. Good questions for SDET roles:

• How is quality ownership split between developers, SDETs and QA engineers here?
• Where do automated tests run, and what blocks a merge or a release today?
• How do you handle flaky tests? Is there a quarantine process?
• What does the current test pyramid look like, and where would you like it to be?
• How much of this role is building test infrastructure versus writing tests for features?
• What would success look like for this role after six months?
• How are testing estimates and test debt treated in planning?

Avoid questions you could answer from the careers page, and save compensation details for the recruiter conversation.

If you have less than six weeks

Prioritise by the job description and your baseline mock interview. A reasonable compressed order is: framework story and behavioural stories (they appear in every loop), then the automation round for the tool in the job description, then API testing, then coding patterns, then system design. Run a mock interview every few days rather than leaving all practice to the end.

Key takeaways

• SDET loops typically cover coding, automation frameworks, API testing, system design and behavioural rounds. Prepare for each deliberately.
• Start with job descriptions and a cold mock interview, so you study what matters.
• In coding rounds, state test cases before you write code. It is your advantage as a tester.
• Practise UI automation and API testing hands-on, not only by reading answers.
• Structure system design and framework answers around risks, layers, trade-offs and your own contribution.
• Prepare specific, honest behavioural stories and thoughtful questions for your interviewers.