SDET Interview Questions for Freshers: Practical Guide

What this guide can and cannot establish

An SDET title does not imply one standard hiring loop. A role may emphasise application code, test infrastructure, browser automation, APIs, mobile systems, performance, reliability, or a mixture. A source-backed preparation guide can identify durable concepts, but it cannot truthfully promise a round count, a cutoff, a preferred language, or a recurring company question without evidence from that employer.

The official ISTQB Foundation syllabus is useful here because it explains testing objectives, lifecycle context, static and dynamic testing, test techniques, test management, and tool support. Selenium's documentation explains maintainable browser-automation structures such as page objects. Playwright's documentation explains locators, automatic waiting, assertions, and isolated browser contexts. These sources describe the technologies and practices themselves. They do not claim that every interviewer will ask about them.

Use the questions below as reasoning drills. For each answer, distinguish a definition from an example, state assumptions, and connect the idea to an observable risk. If a job listing names a different tool or domain, transfer the reasoning instead of forcing the exact examples.

Testing fundamentals questions

What is the purpose of software testing?

Testing is not limited to executing a program and checking whether a screen looks right. The ISTQB syllabus describes testing as activities used to discover defects, evaluate work-product quality, reduce risk, verify specified requirements, validate stakeholder needs, and provide information for decisions. A strong interview answer should choose the objectives relevant to the situation instead of reciting every possible objective.

For a checkout change, for example, the useful question is not merely whether the happy path completes. The candidate should consider incorrect totals, duplicate actions, unavailable dependencies, inconsistent state, access control, recovery, and the evidence stakeholders need before release. This turns a broad definition into a risk-based answer without inventing a company-specific process.

How are verification and validation different?

Verification asks whether the work product meets specified requirements. Validation asks whether it meets users' and stakeholders' needs in its operating context. The distinction matters because a feature can conform to a written rule while still failing the real user need, or appear useful while violating an explicit contract.

In an interview, ask what requirement or need serves as the oracle. If the prompt is ambiguous, say what you would clarify. This is stronger than assuming that the current implementation defines correct behaviour.

What is the difference between static and dynamic testing?

Static testing evaluates work products without executing the software. Reviews and static analysis are examples. Dynamic testing executes software and observes behaviour. Both can expose risk, and neither should be presented as a universal replacement for the other.

For a code change, static work can reveal unclear requirements, unreachable code, insecure patterns, or interface mismatches before execution. Dynamic tests can reveal runtime integration failures, timing behaviour, incorrect state transitions, or rendering problems. A useful answer explains which evidence each approach can produce for the prompt at hand.

How are testing and debugging different?

Testing can reveal a failure and provide evidence about its conditions and impact. Debugging investigates the cause and changes the software to remove it. The activities interact, but finding a failure is not the same as proving its root cause.

An SDET adds value by making the failure reproducible and diagnosable. Record the observed result, expected result, relevant inputs, environment, state, and smallest known reproduction. Then narrow the failing boundary through logs, traces, controlled substitutions, or smaller tests. Do not label a component as the cause merely because its name appears in an error message.

Test-design questions

How would you test a field with input rules?

Start by asking for the contract: accepted forms, rejected forms, normalisation, required or optional status, character handling, storage constraints, and error behaviour. Group inputs that the system should treat alike, then select representatives. Examine boundaries where behaviour changes. Add malformed, missing, duplicated, and unexpected inputs when they are relevant to the interface.

Name the oracle for every test. A response code alone may not be sufficient if state changed incorrectly. A visible message alone may not be sufficient if sensitive data leaked into logs. Prioritise cases by risk and information value rather than producing a large generic checklist.

What are equivalence partitioning and boundary value analysis?

Equivalence partitioning groups values expected to be handled similarly so a representative can provide evidence about that class. Boundary value analysis focuses on edges where behaviour changes, because defects often occur around inclusion, exclusion, and adjacent values.

The interviewer may deliberately leave a boundary vague. Do not invent it. Ask whether the limit is inclusive, what unit applies, how empty input differs from missing input, and whether normalisation happens before validation. The quality of those clarifications often matters more than the length of the final case list.

How do you decide what not to automate?

Automation has creation and maintenance cost. A candidate should consider repeat frequency, stability of the interface, risk, determinism, data setup, observability, execution cost, and whether a cheaper test at a lower layer can provide the same evidence. Exploratory work, rapidly changing behaviour, or an assertion that needs human judgement may not be a good first automation target.

Avoid claiming that every regression case must be automated. Explain what the test protects, why its layer is appropriate, how failures will be diagnosed, and what event would justify removing or redesigning it.

API testing questions

How would you test an API endpoint?

Clarify the request and response contract, authentication, authorisation, idempotency expectations, state changes, error model, and dependency behaviour. Cover the successful path, invalid structure, invalid values, missing credentials, insufficient permission, absent resources, duplicate requests, concurrency where relevant, and dependency failure.

Verify more than the transport status. Check the response schema and semantics, persistence, emitted events, side effects, audit evidence, and absence of forbidden side effects. If the endpoint modifies state, a later read or direct storage check may provide a stronger oracle. If retries are possible, explain how you would detect duplicate work.

What makes an API test trustworthy?

A trustworthy test controls or records its setup, isolates its data, asserts behaviour that matters, and cleans up without hiding failures. It should fail for a meaningful product regression rather than for an unrelated dependency, clock, random identifier, or shared account state.

When a dependency must be replaced, state what behaviour the substitute can and cannot prove. A mocked success response can test local handling, but it cannot establish that the real integration contract still works. Keep at least one suitable contract or integration check for that boundary when the risk warrants it.

Browser automation questions

What is a page object, and what should it contain?

Selenium's official guidance describes a page object as an interface to the services a page or component offers. It centralises knowledge of page structure so UI changes do not require locator edits throughout the suite. Public methods should represent user-relevant operations rather than expose raw locators everywhere.

Selenium also advises keeping test assertions in test code rather than placing them generally inside page objects, with a limited page-load check as a recognised exception. In an interview, explain where you would put locators, actions, assertions, and reusable components. Do not claim that page objects are mandatory for every small test suite.

Why are locators and waits important?

Playwright identifies locators as the central mechanism for finding elements and applying automatic waiting and retry behaviour. Its documentation recommends user-facing locators such as role and label where appropriate. A robust answer explains why a stable, meaningful locator is preferable to a brittle chain tied to incidental markup.

Avoid fixed sleeps as a default synchronisation strategy. Wait for the observable condition the user or system depends on, such as an actionable control, expected response, state transition, or visible result. If the application never exposes a reliable condition, identify that as a testability issue rather than masking it with a longer delay.

What is test isolation?

Isolation means one test should not depend on another test's order, residue, or success. Playwright provides a fresh browser context for each test in its standard model. Even with framework support, the candidate still needs to control server-side data, accounts, feature state, and external dependencies.

To diagnose an isolation failure, run the test alone, in a different order, and with repeated clean setup. Look for shared identifiers, global mutable state, incomplete cleanup, time assumptions, and asynchronous work that outlives the test. The solution should remove the dependency, not merely enforce a favourable order.

Debugging and coding questions

How would you investigate a flaky test?

First classify the uncertainty. The failure may come from application behaviour, test code, environment, data, a dependency, or an incorrect oracle. Preserve traces, logs, screenshots where appropriate, request records, and timing evidence from a failing run. Compare them with a passing run without assuming that the visible symptom is the root cause.

Check for fixed waits, unstable locators, shared state, clock or timezone assumptions, uncontrolled randomness, order dependence, late network work, and assertions made before the relevant state settles. A retry may measure frequency or reduce immediate disruption, but it is not proof that the defect is fixed.

What programming exercise should an SDET candidate expect?

There is no universal exercise. The current role description should determine the language and depth. Transferable preparation includes parsing structured data, transforming collections, validating input, handling errors, designing small interfaces, and writing tests for the solution. Explain complexity when it materially affects the prompt, but do not optimise before the contract is clear.

For an automation-focused exercise, separate test intent from driver details, keep setup explicit, return useful failure information, and show how the code would remain maintainable as the application changes. Working code matters, but so do naming, boundaries, error handling, and the quality of the tests around it.

A defensible answer structure

For a conceptual question, begin with the definition, distinguish it from the nearest confusing concept, give a small example, and name a limitation. For a test-design prompt, clarify the contract, identify risks, choose techniques, state oracles, cover failure paths, and prioritise. For a debugging prompt, separate observation from hypothesis, gather evidence, narrow the boundary, and verify the fix with a regression test.

This structure prevents filler because every paragraph does a job. It also makes unsupported claims visible. If you do not know a tool-specific fact, say what you would check in the official documentation rather than guessing. If the interviewer supplies a constraint, use it. If the constraint is absent, label your assumption and explain how a different answer would change the test.

Common weak answers and how to improve them

• A long taxonomy with no risk connection. Select the testing types that produce useful evidence for the actual prompt.
• A checklist with no oracle. State how each test decides whether behaviour is correct and whether forbidden side effects occurred.
• Tool syntax presented as strategy. Explain the intent, isolation, synchronisation, and maintenance choices behind the code.
• A fixed wait used as proof of readiness. Wait for a meaningful condition and investigate why the condition is difficult to observe.
• A bug label presented as a root cause. Preserve evidence, reproduce, narrow the boundary, and distinguish hypothesis from confirmation.
• A universal interview-process claim. Verify the current employer and role instead of converting a generic guide into a promised round sequence.

Sources and verification boundary

• https://istqb.org/wp-content/uploads/2024/11/ISTQB_CTFL_Syllabus_v4.0.1.pdf
• https://www.selenium.dev/documentation/test_practices/encouraged/page_object_models/
• https://playwright.dev/docs/writing-tests

The sources above support the testing and automation concepts used here. They do not publish a standard SDET hiring process, employer cutoff, salary, or guaranteed question set. Verify role-specific requirements on the employer's current listing.