SDET interview guide

An SDET (Software Development Engineer in Test, sometimes Software Engineer in Test) is closer to a developer who specialises in quality. Job titles and expectations differ widely between companies, so read the job description closely. The pattern below is the common one.

What the process usually contains

1. Coding round. A problem on strings, arrays or maps, often easy to medium difficulty, written in the language of the role. You are watched for clean code, edge cases and testing your own solution.
2. Test design round. "Test this function / API / feature", where they want coverage thinking more than memorised answers.
3. Framework and architecture round. Design an automation framework or review one.
4. Technical depth. The tool stack (Selenium, Playwright, Rest Assured), CI/CD, Git, Docker, SQL.
5. Behavioural round.

The coding round

Practise the standard problem types: reverse and palindrome, anagram, duplicates, first non-repeating character, two-sum, merge two sorted arrays, balanced brackets, word frequency, and basic SQL. Examples with solutions are in Java for testers.

How to work through one, in the order that interviewers like:

1. Repeat the problem and ask about inputs: can it be empty? negative? very large? case-sensitive?
2. Say the simple approach first, then improve it.
3. Write the code, saying what you are doing.
4. Run two or three examples by hand, including an edge case.
5. State the time and space cost.

Example: balanced brackets.

static boolean balanced(String s) {
    Deque<Character> stack = new ArrayDeque<>();
    for (char c : s.toCharArray()) {
        if ("([{".indexOf(c) >= 0) stack.push(c);
        else if (")]}".indexOf(c) >= 0) {
            if (stack.isEmpty()) return false;
            char open = stack.pop();
            if ("([{".indexOf(open) != ")]}".indexOf(c)) return false;
        }
    }
    return stack.isEmpty();
}

Then the SDET twist: "write tests for this function". Cover an empty string, only openers, only closers, nested and interleaved brackets (([)]), and very long input.

The test design round

You may get a function, an API or a product. A repeatable approach:

• Clarify the purpose and inputs.
• List equivalence classes and boundaries.
• Think of invalid, empty and huge inputs, concurrency, and failure of dependencies.
• Say which tests are unit, API and UI, and why.

The framework design round

Typical prompt: "Design an automation framework for a web app with a REST backend." A good answer covers:

Technical depth you should be ready for

• Git: branching, rebase vs merge, resolving a conflict, what a pull request review should check.
• CI/CD: a pipeline you wrote, stages, caching dependencies, running tests in Docker, publishing results.
• API automation: authentication handling, contract tests, schema validation, mocking dependencies (API testing questions).
• Design patterns in test code: Page Object, Factory for drivers, Builder for test data, Singleton and why it is risky with parallel tests.
• Performance and security basics: what you would check with a simple JMeter or k6 script, and common web risks.

Twelve more SDET questions

1. Design a test platform for a company with 100 microservices.

Start with goals: fast feedback, reliable results, and ownership by each team. A reasonable design: each service owns its unit and contract tests; a shared test framework library (HTTP client, data builders, reporting) gives consistency; contract tests catch interface breaks without running everything together; a small set of end-to-end journeys runs against an integrated environment; test environments are created on demand in containers; results go to one dashboard with flaky-test tracking. Say what you would build first and what you would measure (time to feedback, flake rate).

2. How do you make UI tests independent and fast?

Each test creates its own data through the API, logs in with a saved session, and runs in its own browser context. No test depends on another. Parallelise across workers or shards, and run only a smoke set on each pull request.

3. Explain the Builder and Factory patterns in test code.

A builder creates complex test data step by step with sensible defaults: new OrderBuilder().withItems(3).paidByUpi().build(). A factory decides which object to create, such as a driver for a chosen browser. Both remove repeated set-up and make tests read like what they check.

4. How do you test code that depends on time or randomness?

Inject the dependency so a test can control it: a clock you can set, a random source with a fixed seed. For code you cannot change, run the test around fixed boundaries (the end of a month, a leap day) or use a library that fakes time. Never make a test pass because "it was fast enough".

5. How do you decide between mocking a dependency and using the real one?

Use the real one where the interaction is the thing being tested and it is cheap and stable. Mock where the dependency is slow, costs money, is outside your control, or cannot produce the case you need (a timeout, a 500, a declined card). Keep a few tests against the real thing so mocks do not drift from reality.

6. What is observability, and how does it help testing?

Logs, metrics and traces that show what the system did. For testing it means a failing test can be explained: the trace shows which service call was slow or wrong. Add a request id to your test calls and look for it in the logs.

7. How would you test a feature behind a feature flag?

Test both states, on and off, and the transition. Include the flag in the test data set-up so each test chooses its state, check that turning it off removes the behaviour completely, and remember to remove the tests when the flag is removed.

8. How do you reduce flaky tests across a large suite?

Measure first: record every test's pass rate over time. Quarantine tests that fail intermittently so they stop blocking the team, assign owners, and fix by cause (waiting, shared data, order dependence, environment). Make "no new flaky tests" part of review. See flaky tests in CI.

9. Coding question: find two numbers in an array that add up to a target.

static int[] twoSum(int[] nums, int target) {
    Map<Integer, Integer> seen = new HashMap<>();
    for (int i = 0; i < nums.length; i++) {
        Integer j = seen.get(target - nums[i]);
        if (j != null) return new int[] { j, i };
        seen.put(nums[i], i);
    }
    return new int[0];
}

One pass, a map from value to index: O(n) time. The brute-force double loop is O(n squared); say it first, then improve.

10. Coding question: merge two sorted arrays.

static int[] merge(int[] a, int[] b) {
    int[] out = new int[a.length + b.length];
    int i = 0, j = 0, k = 0;
    while (i < a.length && j < b.length) out[k++] = a[i] <= b[j] ? a[i++] : b[j++];
    while (i < a.length) out[k++] = a[i++];
    while (j < b.length) out[k++] = b[j++];
    return out;
}

Then the SDET twist: write tests for it (empty arrays, one empty, duplicates, negatives, very large arrays).

11. What is a good code review comment on a test?

One that is specific and gives a reason: "this sleep will make the test slow and still flaky; wait for the confirmation toast instead". Praise good tests too. Focus on behaviour and maintainability, not style preferences a linter can enforce.

12. What would you do if a developer says your tests slow down the build?

Take it seriously: measure the run time per test, find the slow ones, parallelise, move checks down to API or unit level, and run the heavy suite on a schedule while a fast subset runs on every change. Agree a target time with the team and report against it.

How SDET differs from a QA engineer

A QA engineer focuses on what to test and whether the product is good enough. An SDET also builds the tooling: frameworks, test infrastructure, pipelines, sometimes developer-facing test libraries. In many companies the two overlap, and some use "SDET" for any automation role, so ask what the day-to-day work is.

Preparing

Build and keep one real project you can describe in depth. The portfolio project kit gives a structured one on a buggy app: a Playwright and API framework, a test plan and a bug list, so that "tell me about your framework" has a concrete answer.