The Complete SDET Interview Guide: 50 JavaScript, Playwright, and Selenium Questions With Answers
SDET interviews in 2026 test a broader range of skills than ever before. You need JavaScript fundamentals, framework-specific knowledge for both Playwright and Selenium, system design thinking for test architecture, and increasingly, an understanding of AI-assisted testing. This guide covers 50 questions across all four categories, organized from beginner to advanced, with the kind of detailed answers that demonstrate real understanding — not memorized definitions.
I have conducted over 200 SDET interviews in the past four years, and the pattern of what separates strong candidates from average ones has shifted. Three years ago, knowing Selenium WebDriver inside out was enough. Today, interviewers expect you to discuss trade-offs between frameworks, explain why you would choose one locator strategy over another, and demonstrate that you understand the engineering principles behind test automation — not just the API calls.
Contents
JavaScript Fundamentals: The Foundation Every SDET Needs
The difference between var, let, and const is the most common opening question, and most candidates give an incomplete answer. Var is function-scoped and hoisted — it is available throughout the function where it is declared, even before the declaration line (though its value is undefined until the declaration executes). Let and const are block-scoped — they exist only within the nearest enclosing curly braces. Const additionally prevents reassignment of the variable binding, though it does not make objects immutable. The practical advice: use const by default, let when you need to reassign, and never use var in modern code.
Closures are the second JavaScript concept that trips up candidates. A closure is a function that retains access to variables from its outer (enclosing) scope even after the outer function has returned. In test automation, closures appear constantly — every callback, every promise handler, every fixture setup function creates a closure. When you write a Playwright test that captures a variable in a beforeEach hook and uses it inside a test function, that is a closure in action. Interviewers want to see that you understand the mechanism, not just the definition.
The equality operators == and === differ in type coercion. Double equals performs type coercion before comparison, meaning '5' == 5 returns true because the string is converted to a number. Triple equals compares both type and value without coercion, so '5' === 5 returns false. In test assertions, always use strict equality. A test that passes because of implicit type coercion is hiding a potential bug rather than catching one.
Promises and async/await are essential for Playwright work because every browser interaction is asynchronous. A promise represents a value that may not be available yet — it is in one of three states: pending, fulfilled, or rejected. Async/await is syntactic sugar over promises that makes asynchronous code read like synchronous code. When an interviewer asks why Playwright uses async/await, the answer is that every browser action (navigation, clicks, assertions) requires communication with the browser process over a protocol, and that communication is inherently asynchronous.
Playwright-Specific Questions
What is auto-waiting and why does it matter? Playwright automatically waits for elements to meet actionability criteria before performing actions. For a click, it waits until the element is visible, stable (not animating), enabled, and receives events (not obscured by other elements). This eliminates the most common source of test flakiness in traditional frameworks — timing issues caused by explicit or implicit wait misconfigurations.
Explain the difference between page.locator() and page.$(). This question reveals whether you understand Playwright’s modern API. page.locator() returns a Locator object that supports auto-waiting, retries, and chaining. It does not query the DOM immediately — it represents a way to find elements. page.$() immediately queries the DOM and returns an ElementHandle, which is a direct reference to a DOM node. Locators are preferred in almost all testing scenarios because they are more resilient to timing issues. ElementHandles are useful only when you need direct DOM manipulation, which is rare in test automation.
How do you handle authentication in Playwright tests? The best practice is to authenticate once in a global setup script, save the browser storage state (cookies and local storage) to a JSON file, and reuse that state across all tests that need an authenticated session. This avoids repeating the login flow in every test, which saves significant execution time and reduces the surface area for authentication-related flakiness.
What is a browser context and how does it differ from a page? A browser context is an isolated browser session — think of it as an incognito window. It has its own cookies, local storage, and session data. A page is a single tab within a context. Playwright creates a fresh context for each test by default, which provides test isolation. You can create multiple pages within a single context to test multi-tab scenarios, or create multiple contexts to simulate multiple users interacting simultaneously.
Selenium Deep Dive
Explain the difference between implicit and explicit waits. Implicit waits set a global timeout for element finding — if an element is not immediately present, WebDriver polls the DOM for the specified duration before throwing a NoSuchElementException. Explicit waits use WebDriverWait with specific expected conditions (element visible, element clickable, text present) to wait for a particular state. The critical detail most candidates miss: implicit and explicit waits should never be mixed, because their interaction is unpredictable and can lead to waits that are longer than either timeout alone.
What is the Page Object Model and why is it important? POM is a design pattern where each page (or significant component) of the application is represented by a class. That class encapsulates the locators for elements on the page and the methods for interacting with those elements. The benefit is maintainability: when the UI changes, you update the page object in one place rather than modifying every test that interacts with that page. The interview follow-up is usually about when POM is not the right choice — for very simple applications or for API-only testing, the overhead of page objects is not justified.
How does Selenium Grid work? Grid allows you to run tests across multiple machines (nodes) from a single entry point (hub). The hub receives test requests and routes them to available nodes based on the requested browser and platform capabilities. In the Selenium 4 architecture, the Grid has been redesigned with a Router, Distributor, Session Map, and Node components that can be deployed together on one machine or distributed across many. The practical value is parallel execution at scale — running your test suite across 20 browser instances simultaneously rather than sequentially.
System Design and Behavioral Questions
Senior SDET interviews increasingly include system design questions. “Design a test automation framework for a microservices e-commerce platform” is a common prompt. The strong answer covers test layer strategy (unit, integration, contract, E2E), tool selection rationale, CI/CD integration, test data management, reporting, and scalability considerations. It also addresses what you would not automate and why — demonstrating judgment, not just technical breadth.
Behavioral questions for SDETs focus on collaboration scenarios. “Tell me about a time you disagreed with a developer about a bug” tests your communication skills and professional judgment. “How do you decide what to automate?” tests your strategic thinking. “Describe a situation where your automation found a critical bug” tests whether you can articulate the value of your work to non-technical stakeholders. Prepare specific examples with concrete outcomes — numbers, timelines, and measurable impact.
The Honest Caveats
Interview questions vary enormously by company, team, and seniority level. The questions in this guide reflect patterns I have observed across startups and mid-sized companies hiring SDETs. Enterprise interviews at FAANG-level companies may include additional categories like concurrency, distributed systems testing, and production observability that this guide does not cover.
Memorizing answers is counterproductive. Interviewers can immediately tell when a candidate is reciting rather than explaining. Use this guide to identify your knowledge gaps, then learn the underlying concepts deeply enough to explain them in your own words, with your own examples from your own projects.
The job market for SDETs in 2026 is strong but evolving. Companies increasingly want SDETs who can work with AI tools, understand LLM evaluation, and contribute to the quality of AI-powered features. The JavaScript/Playwright/Selenium foundation remains essential, but it is becoming the floor rather than the ceiling of what employers expect.
Preparing for Success
The candidates who perform best in SDET interviews share three traits. They can explain concepts at multiple levels of abstraction — from the high-level purpose to the low-level implementation. They have opinions backed by experience — they can say “I prefer Playwright over Selenium for this reason, based on this project.” And they are honest about what they do not know — saying “I have not worked with that directly, but here is how I would approach learning it” is far more impressive than a vague, invented answer.
Comprehensive SDET interview preparation — including mock interview sessions, system design exercises, and coding challenges with detailed solutions — is available in the career track of my AI-Powered Testing Mastery course.
