Playwright SDET Interview Questions 2026 — Auto-Waiting, Fixtures, API Mocking, Parallel Execution, and Every Question Panels Ask About Modern Browser Automation
Your SDET interview is in 48 hours and "Playwright experience" is listed under required skills. Master every Playwright interview question panels ask — auto-waiting mechanics and actionability checks (visible, stable, enabled, receives events), test and worker fixture architecture with dependency injection, API mocking with page.route() and fulfill(), parallel execution with workers and sharding strategy, Trace Viewer debugging with screenshots and DOM snapshots, locator strategy hierarchy (getByRole, getByText, getByTestId) and strict mode enforcement, and the Playwright vs Selenium vs Cypress comparison that demonstrates senior-level architectural thinking. Mitchell Agoma's 20-year guide from HMRC, MoD, Nationwide, and Accenture. Includes pre-interview checklist.
Published 6 August 2026 • By Mitchell Agoma
It is 11:47pm. You are staring at a job description for a Senior SDET role at a major SaaS company. The tech stack lists TypeScript, CI/CD pipelines, microservices, contract testing — and then, in bold under required skills, two words that trigger a specific anxiety: "Playwright experience." You have written Playwright tests. You have migrated Selenium suites to Playwright and celebrated when flaky tests stopped flaking. You have watched Trace Viewer replays and smiled at the auto-waiting magic that eliminated your Thread.sleep() calls. But when the interviewer leans forward and asks "explain how Playwright auto-waiting works — walk me through the actionability checks that run before every click, and what happens when an element fails the 'receives events' check" — you realise you have been trusting Playwright's magic without understanding the mechanics underneath. You know Playwright as a tool. The panel is testing whether you know Playwright as an engineering platform.
Mitchell has watched this exact gap eliminate SDET candidates who were otherwise brilliant across 20 years of hiring at HMRC, the Ministry of Defence, Nationwide, and Accenture. The candidate who could design a distributed Selenium Grid for 500 concurrent browsers froze when asked "how would you design a fixture hierarchy for a test suite that needs database connections, API clients, and browser contexts — and what happens when a worker fixture depends on another worker fixture?" The candidate who had written hundreds of page.route() intercepts could not explain the difference between route.fulfill(), route.abort(), and route.continue() — and the scenarios where each one is appropriate. And the candidate who confidently said "Playwright is better than Selenium because of auto-waiting" could not articulate a single production scenario where Selenium was genuinely the better choice — which told the panel they had adopted Playwright by trend, not by engineering judgment. The gap is not knowing that Playwright exists — every modern browser-automation candidate knows that. The gap is understanding Playwright as a browser automation platform: the auto-waiting mechanics that eliminate flakiness at the architecture level, the fixture system that provides test isolation with dependency injection, the network interception API that makes API mocking declarative, the parallel execution model that scales across machines, and the comparison framework that places it alongside Selenium and Cypress with engineering reasoning, not tool evangelism.
Here is the reality that keeps Mitchell's SDET candidates awake at 11:47pm: Playwright has become the dominant browser automation framework for modern web applications in 2026. Its auto-waiting eliminates the explicit-wait boilerplate that makes Selenium suites verbose. Its fixture system provides test isolation and dependency injection that Cypress cannot match. Its network interception API (page.route()) enables declarative API mocking without external proxy tools. Its Trace Viewer provides screenshots, DOM snapshots, network logs, and console output in a single timeline — debugging nirvana compared to Selenium's screenshot-on-failure approach. Its multi-browser support (Chromium, Firefox, WebKit) with a single API surpasses Cypress's Chromium-only limitation. Its parallel execution with worker sharding scales linearly across CPU cores. And in 2026, interview panels are not asking "have you used Playwright?" — they are asking "explain Playwright auto-waiting mechanics," "how would you design a fixture hierarchy for a multi-service test suite?" "when would page.route() be insufficient and you need a real mock server?" and "when would you choose Playwright over Cypress or Selenium — and defend that choice with architectural reasoning."
The SDET Interview Coach iOS app — with 800+ questions across 32 topics, Claude-graded mock interviews from Junior to Lead, and dedicated modules on Playwright architecture, auto-waiting mechanics, fixture patterns, API mocking, parallel execution, and the Playwright-vs-Selenium-vs-Cypress decision framework — gives you the structured practice to discuss Playwright browser automation with the precision of someone who has designed Playwright frameworks in production, for £4.99 per month on iOS and Google Play. And the AI Test Automation Playbook (£9.99) includes a dedicated chapter on modern browser automation — covering Playwright internals, fixture-driven test architecture, network interception patterns, Trace Viewer debugging workflows, and the Playwright-vs-Selenium-vs-Cypress decision framework that demonstrates engineering maturity. Do not let "Playwright experience" be the two words that cost you the offer. Walk in ready to discuss Playwright as a browser automation platform — not a tool you have been clicking through for two years.
What Interviewers Are Actually Testing When They Ask About Playwright — It Is Never "Can You Write page.click()?"
When an interviewer asks "tell me about your Playwright experience," they are not checking whether you can locate a button and click it. A candidate who says "I have automated hundreds of test cases using Playwright — I use page.click, page.fill, page.goto" has demonstrated they can write Playwright scripts. What the interviewer is actually testing is whether you understand Playwright as a browser automation platform — its architecture, its design patterns, its failure modes, and the engineering decisions that determine whether your Playwright suite runs reliably at scale or generates false confidence.
Signal 1: You Understand Auto-Waiting Mechanics — Actionability Checks That Eliminate Flakiness at the Architecture Level
The strongest candidates can explain exactly what happens between page.click('button') and the click event firing — and why this is Playwright's most important architectural decision. "Playwright's auto-waiting is not magic — it is a set of actionability checks that run before every interaction (click, fill, type, check, selectOption, etc.). When you call page.click('#submit'), Playwright waits for the element to satisfy five conditions before performing the click: (1) Attached — the element must be in the DOM. Playwright polls the DOM until the element is attached or the timeout expires. This is equivalent to Selenium's presenceOfElementLocated — but it is automatic, not opt-in. (2) Visible — the element must be visible, meaning it has a non-zero size and is not hidden by CSS (display: none or visibility: hidden). Playwright checks the computed style and bounding box. (3) Stable — the element must not be animating. Playwright checks that the element's bounding box has not changed in two consecutive animation frames. (4) Receives Events — the element must be the top-most element at its centre point — nothing is obscuring it. If another element (a modal overlay, a loading spinner) intercepts the click, the actionability check fails. (5) Enabled — the element must not be disabled (must not have the disabled attribute). Playwright performs these checks in a loop — it polls the element state, checks all conditions, and retries until all conditions pass or the timeout expires (default 30 seconds, configurable via actionTimeout in playwright.config.ts). Compare this to Selenium, where the SDET must manually implement every one of these checks. The interview-winning insight: 'auto-waiting is the architectural decision that makes Playwright tests reliable by default. In Selenium, reliability requires discipline — every SDET must remember to add explicit waits for every interaction. In Playwright, reliability is enforced by the framework.'" At HMRC, Mitchell's team migrated a 2,000-test Selenium suite to Playwright — and the flakiness rate dropped from 15% to 2% with zero code changes to the test logic.
Signal 2: You Master Fixture Architecture — Test Fixtures, Worker Fixtures, Scoping, and Dependency Injection
Playwright's fixture system is its most powerful architectural concept — and interviewers probe fixture questions deeply because fixtures determine the entire structure of a Playwright test framework. "Playwright fixtures are a dependency-injection system for tests. Instead of creating browser contexts, pages, and API clients in beforeEach hooks — you define fixtures that Playwright automatically creates, injects into tests, and tears down. The fixture lifecycle: a fixture is defined using test.extend(). The code before use() is the setup phase. The code after use() is the teardown phase — guaranteed to run even if the test fails. Test fixtures (default scope: per-test) — a new instance is created for every test. Worker fixtures (scope: 'worker') — a single instance is shared across all tests in a worker process. Use worker fixtures for expensive resources like database connection pools. Fixture dependency injection: fixtures can depend on other fixtures, and Playwright resolves the dependency graph automatically. The interview-winning insight: 'Playwright fixtures transform test setup from imperative (beforeEach/afterEach hooks) to declarative (define what the test needs, and Playwright manages the lifecycle).'" At Nationwide, Mitchell's team used a fixture hierarchy with worker-scoped database connection pooling and test-scoped per-test transactions. This reduced test execution time by 40%.
Signal 3: You Master API Mocking with page.route() — Network Interception, Mocking, and Partial Mocking
Network interception is Playwright's killer feature for modern web testing — and interviewers probe route() deeply because it demonstrates whether you understand the modern testing paradigm of controlling the network layer. "page.route() intercepts network requests and responses at the browser level — before they leave the browser. This is fundamentally different from external proxy-based mocking (WireMock, MockServer) because it operates inside the browser process. The three core operations: (1) route.fulfill() — return a mocked response without the request reaching the network. Ideal for slow/unreliable API endpoints, endpoints with side effects, and non-deterministic data. (2) route.abort() — block the request entirely. Use for analytics scripts, ad networks, tracking pixels. (3) route.continue() — let the request proceed to the real server but modify it (add headers, change method). Partial mocking — the pattern that demonstrates deep Playwright expertise: intercept specific endpoints and let all other requests pass through. Pattern matching supports glob patterns, regular expressions, and predicate functions. Routes execute in registration order — register most-specific patterns first. The interview-winning insight: 'page.route() enables controlling the network layer from within the test — no external mock server, no proxy configuration.'" At the Co-op, Mitchell's team used page.route() to mock the payment gateway API, reducing test execution time by 60%.
Signal 4: You Design Parallel Execution and Sharding — Workers, Sharding Strategy, and CI Integration
This is the question that separates candidates who have run Playwright locally on one machine from those who have run it at enterprise scale across CI pipelines. "Playwright's parallel execution model is built on worker processes and sharding. Workers: Playwright runs tests in parallel using worker processes — each worker is a separate Node.js process. Configured via workers in playwright.config.ts. Sharding: for very large test suites (1,000+ tests), sharding splits the suite across multiple CI jobs — each job runs a subset on its own machine. npx playwright test --shard=1/3 runs the first third. Three shards run in parallel on three separate CI jobs. Sharding strategy: shard by test file (default), shard by test (finer granularity), and balance shards by historical timing data. CI integration: in GitHub Actions, each shard is a separate job in the matrix. After all shards complete, a merge job combines reports. The interview-winning insight: 'A suite that takes 60 minutes on a single machine with 4 workers takes approximately 15 minutes on 4 shards with 4 workers each.'" At Accenture, Mitchell's team ran a 3,000-test Playwright suite across 8 shards on GitHub Actions with 4 workers per shard — total wall-clock time: 12 minutes (down from 90 minutes on a single machine).
Signal 5: You Debug with Trace Viewer — Screenshots, DOM Snapshots, Network Logs, and Timeline
Trace Viewer is Playwright's debugging superpower — and interviewers probe trace questions because they reveal whether you can diagnose failures systematically or just rely on screenshot-on-failure. "Playwright Trace Viewer provides a complete timeline of test execution — screenshots, DOM snapshots, network logs, console output, and action events, all synchronised on a single timeline. Enable in playwright.config.ts: use: { trace: 'retain-on-failure' }. Trace Viewer features: (1) Screenshot timeline — a filmstrip before and after each action. (2) DOM snapshot — interactive, searchable HTML at every action. (3) Network tab — full request/response with headers, body, timing. (4) Console tab — all console.log, console.error, and uncaught exceptions. (5) Source tab — the exact test code line that triggered each action. (6) Action list — every Playwright action with timing, result, and error details. My debugging workflow: find the failed action, check the screenshot, inspect the DOM snapshot, check the network tab, check the console. This diagnoses 90% of failures within 2 minutes. The interview-winning insight: 'Trace Viewer transforms debugging from trial and error into forensic investigation.'"
Signal 6: You Master Locator Strategy — getByRole, getByText, getByTestId, Locator Chaining, and Strict Mode
Playwright's locator philosophy is fundamentally different from Selenium's — and interviewers probe locator questions because they reveal whether you write tests that survive UI refactoring or tests that break every sprint. "Playwright locators follow a user-facing philosophy: locate elements the way users perceive them — by role, by text, by label — not by implementation details. The locator hierarchy, ranked by stability: (1) getByRole() — finds elements by ARIA role and accessible name. Uses the accessibility tree, immune to CSS changes and DOM restructuring. (2) getByLabel() / getByPlaceholder() — finds form controls by their label or placeholder. (3) getByText() — finds elements by visible text content, regardless of HTML structure. (4) getByTestId() — finds elements by data-testid attribute. The gold standard — explicit contract between developers and testers, immune to all UI changes. (5) locator() — the escape hatch for CSS selectors and XPath. Locator Chaining: chain locators to narrow results — readable, semantic chains replace complex CSS selectors. Strict Mode: Playwright enforces strict mode by default — if a locator matches multiple elements, it throws an error. The interview-winning insight: 'If your test uses page.locator('.btn-primary-blue-large'), it breaks when the designer changes the button to red. If your test uses page.getByRole('button', { name: 'Submit' }), it survives changing colors, CSS frameworks, DOM structure, and JavaScript frameworks.'" At Nationwide, Mitchell's team migrated all Selenium locators to Playwright's semantic locators — test maintenance dropped by 80% because locators no longer broke on CSS class changes.
The one-sentence answer that anchors every strong Playwright interview response: "Playwright is not 'a faster Selenium' — it is a browser automation platform built on auto-waiting actionability checks that eliminate flakiness at the architecture level, a fixture system that provides test isolation through dependency injection instead of imperative setup hooks, a network interception API (page.route()) that enables declarative API mocking inside the browser process, a parallel execution model with worker sharding that scales linearly across machines, and a locator philosophy (getByRole, getByTestId) that makes tests survive UI refactoring; the skill interviewers are testing is not whether you can automate a login flow, but whether you can design a Playwright test architecture that runs reliably at scale — catching regressions that a framework designed with Thread.sleep() and CSS selectors would miss, while explaining the architectural trade-offs that determine when Playwright, Selenium, or Cypress is the right tool for a specific engineering context."
Playwright vs Selenium vs Cypress — The Architecture-Level Comparison Every Senior SDET Must Articulate
This question appears in virtually every senior SDET interview where browser automation is discussed: "Why Playwright over Selenium or Cypress?" The panel is not interested in which tool you prefer. They are testing whether you can make architecture-level technology decisions with trade-offs explicitly stated — and whether you understand the full browser automation tool landscape, not just the one tool you have used.
Playwright — Auto-Waiting, Multi-Browser, Network Interception, Trace Viewer
Strengths: The architecture was designed for modern web applications — auto-waiting is built into every interaction, not added as an optional layer. Multi-browser support with a single API — Chromium, Firefox, and WebKit — making cross-browser testing a first-class feature. Network interception with page.route() — declarative API mocking from within the test, no external proxy or mock server required. Fixture system with dependency injection — test isolation without beforeEach/afterEach boilerplate. Trace Viewer — full timeline debugging with screenshots, DOM snapshots, network logs, and console output synchronised. Parallel execution with worker sharding — linear scaling across machines. Mobile emulation — built-in device viewport, touch events, geolocation, and permissions mocking. Component testing — test React, Vue, and Svelte components in a real browser. VS Code extension — record, run, and debug tests from the IDE. Weaknesses: WebKit support is based on Playwright's own WebKit build — not the same engine as Safari on macOS/iOS, so WebKit tests do not guarantee Safari compatibility. Smaller community than Selenium — fewer Stack Overflow answers, fewer third-party integrations. JavaScript/TypeScript-first — while Playwright supports Python, Java, and .NET, the primary development happens in TypeScript. No true Safari support — Playwright's WebKit is a different build than Apple's Safari.
Selenium — The Cross-Language, Cross-Browser, Legacy-Ready Standard
Strengths: True cross-browser support including Safari (via safaridriver), Opera, and Internet Explorer — browsers that Playwright cannot automate. Language-agnostic — Java, Python, C#, JavaScript, Ruby, Kotlin — the broadest language support of any browser automation tool. Mature ecosystem — largest community, most Stack Overflow answers, most third-party integrations. W3C WebDriver standard — the protocol is a web standard, ensuring long-term stability. Selenium Grid — distributed execution across machines. Weaknesses: No auto-waiting — explicit waits are opt-in, leading to the flaky-test epidemic. Slower execution — HTTP round-trip overhead between test and browser driver adds latency to every command. No built-in network interception — API mocking requires external proxy tools. No Trace Viewer — debugging relies on screenshots and logs. Verbose test code — 2-3x longer than equivalent Playwright tests.
Cypress — Developer-First, Real-Time Reload, Chrome-Family Only
Strengths: Developer experience — real-time test reloading, time-travel debugging, automatic screenshots and videos, polished Test Runner UI. In-browser execution — tests run inside the browser, giving direct access to the application's JavaScript context. Automatic waiting — Cypress automatically waits for commands and assertions. Component testing — first-class support for React, Vue, Angular, and Svelte. Weaknesses: Chromium-family only — no Firefox, no Safari, no WebKit support. This is Cypress's biggest architectural limitation and the primary reason teams migrate to Playwright. No multi-tab or multi-window support. No native mobile emulation. Same-origin restriction — visiting multiple domains requires complex workarounds. Less granular network interception than Playwright's route() API. Cypress Dashboard required for parallelisation, with per-test-run costs.
When Playwright Wins vs When Selenium Wins vs When Cypress Wins — The Decision Framework
"Choose Playwright when: your team writes JavaScript or TypeScript — Playwright's TypeScript-first API is the most ergonomic. Your application requires cross-browser testing (Chromium, Firefox, WebKit). You need network interception for API mocking — page.route() eliminates external mock servers. You need parallel execution at scale — worker sharding scales linearly. You value debugging productivity — Trace Viewer cuts debugging time by orders of magnitude. Your team values reliability by default — auto-waiting eliminates the flaky-test epidemic. Choose Selenium when: your team writes Java, Python, or C# — Selenium's language bindings are more mature than Playwright's non-JS bindings. Your organisation requires true Safari testing — Playwright's WebKit is not Apple's Safari. Your organisation has a large existing Selenium codebase — the migration cost exceeds the reliability benefit. Your organisation needs Internet Explorer support. Your organisation values long-term protocol stability — the W3C WebDriver standard guarantees stability. Choose Cypress when: your team only tests in Chromium-family browsers. Developer experience is the top priority — Cypress's real-time reload and Test Runner UI are unmatched. Your application does not use multiple tabs, multiple windows, or cross-origin flows. My decision framework: for new TypeScript/JavaScript projects in 2026, Playwright is the default choice — it matches or exceeds Selenium and Cypress on every dimension except Safari testing and non-JS language support. For Java/Python/C# teams with Safari requirements, Selenium is the pragmatic choice. For Chromium-only projects where developer experience is paramount, Cypress remains competitive — but the team must accept the architectural limitations."
Common Mistakes SDET Candidates Make in Playwright Interviews
Mitchell has watched hundreds of candidates make the same Playwright interview mistakes across 20 years at HMRC, the Ministry of Defence, Nationwide, and Accenture. Here are the five most common — and how to avoid them at 11:47pm before your interview.
Mistake 1: Using page.waitForTimeout() Instead of Proper Waits
"I add page.waitForTimeout(3000) to let the page load before interacting." This is the #1 signal of a candidate who has not internalised Playwright's auto-waiting philosophy. page.waitForTimeout() is a fixed sleep — it wastes time when the element appears early and still fails when the element takes longer. The fix: "I rely on Playwright's auto-waiting — every interaction (click, fill, type) automatically waits for actionability. If I need to wait for a specific condition, I use: await page.waitForSelector('.loading-complete') for DOM elements; await page.waitForResponse(...) for API responses; await expect(page.getByText('Dashboard')).toBeVisible() for visible text with built-in retry. I never use page.waitForTimeout() in production test code. If a sleep 'fixes' a test, it is masking a real timing issue."
Mistake 2: Not Using Fixtures for Test Isolation
"I create pages and contexts in beforeEach hooks and clean up in afterEach hooks." This works for simple suites but creates massive code duplication as the suite grows. The fix: "I use Playwright's fixture system. Every test that includes a fixture as a parameter gets a fresh, ready-to-use instance — no setup code, no teardown code, no duplication. Fixtures compose: a test can request page, apiClient, dbConnection, and todoPage — and Playwright creates them all with proper dependency ordering. Fixtures guarantee teardown even on test failure."
Mistake 3: Ignoring Strict Mode Violations
"I use page.locator('.btn') and it works — it clicks the first button." Playwright's strict mode throws an error if a locator matches multiple elements — but candidates who add .first() everywhere to silence strict mode are creating fragile tests. The fix: "I use strict mode as a signal — if a locator matches multiple elements, it is too broad. Instead of silencing with .first(), I narrow the locator: use getByRole with a name, use filter() to narrow by text, use locator chaining to scope the search. I never use { strict: false } — it creates silent bugs."
Mistake 4: Hardcoding Selectors Instead of Using Test IDs
"I use page.locator('.submit-btn.primary.large') to click the submit button." CSS-class-based selectors break every time the UI team refactors the CSS — and modern frontend frameworks generate dynamic class names. The fix: "I advocate for data-testid attributes: the development team adds data-testid="submit-button" to every interactive element. Tests use page.getByTestId('submit-button'). data-testid attributes are explicit contracts between developers and testers — they survive CSS refactoring, framework migrations, and text changes. If data-testid is not available, I fall back to getByRole or getByText."
Mistake 5: Not Leveraging Trace Viewer for Debugging
"My test failed in CI — I added console.log statements and re-ran it locally to debug." Console.log debugging is slow, imprecise, and often fails to reproduce the CI failure locally. The fix: "I configure trace-on-failure in playwright.config.ts: use: { trace: 'retain-on-failure' }. When a test fails in CI, Playwright saves the trace as a zip file — I download it and open it in Trace Viewer. The trace shows: screenshots at every action, the DOM snapshot, network requests, console output, and the action timeline. This forensic debugging workflow diagnoses 90% of failures within 2 minutes. The SDET Interview Coach app includes Trace Viewer scenarios where the AI presents a failure trace and asks you to diagnose the root cause."
Playwright Test Runner Architecture — Configuration, Global Setup, and Reporter Patterns
Interviewers at senior levels probe the Playwright test runner architecture because it tests whether you can design a framework that scales across multiple teams, environments, and CI pipelines — not just write individual tests.
Configuration — playwright.config.ts, Projects, Test Directory, Retries, and Timeouts
"playwright.config.ts is the single source of configuration truth. Key settings for production suites: (1) testDir — the directory containing test files. (2) projects — define multiple test configurations that run in parallel or selectively. Projects can represent different browsers (Chromium, Firefox, WebKit) or different test suites (smoke, regression, visual, api) with different directories, fixtures, and settings. (3) retries — retries: process.env.CI ? 2 : 0 — retry in CI to absorb transient failures, no retries locally. (4) timeout — per-test timeout. Adjust based on complexity. (5) expect.timeout — per-assertion timeout. (6) use — global options: baseURL, trace, screenshot, video, actionTimeout, navigationTimeout. (7) webServer — start a local dev server before tests, eliminating manual server startup."
Global Setup and Teardown with Project Dependencies
"Global setup and teardown run once before and after the entire test suite. Defined via globalSetup: './global-setup.ts' in playwright.config.ts. Global setup runs before any workers start — ideal for: seeding a test database, generating authentication tokens, starting external services. Project dependencies: Playwright projects can depend on other projects — { name: 'e2e', dependencies: ['setup'] }. The setup project runs first (e.g., logging in and saving authentication state), and the e2e project reuses the saved state. The interview-winning insight: 'project dependencies enable composable test setup. Instead of every test file performing login, a single setup project authenticates once, saves the state, and every test project reuses it. This reduces authentication overhead from O(n) per test to O(1) per test run.'"
Reporter Architecture — Built-in Reporters, Custom Reporters, and CI Integration
"Playwright provides multiple built-in reporters: (1) HTML Reporter — interactive HTML report with test results, screenshots, traces. (2) JSON Reporter — structured JSON for custom dashboards and analytics. (3) JUnit Reporter — JUnit XML format, compatible with virtually every CI platform. (4) Line/Dot/List Reporters for CI log output. (5) Blob Reporter — binary blobs that can be merged after sharded execution. Multiple reporters can be combined. Custom reporters implement the Reporter interface — ideal for sending results to Slack/Teams, updating TestRail/Xray, logging to monitoring systems. The CI integration pattern: JUnit reporter for GitHub Actions annotations, HTML reporter archived as a CI artifact, Blob reporter for sharding. The interview-winning insight: 'the reporter architecture reflects the difference between a test that runs and a test suite that communicates.'"
Authentication Patterns — storageState, globalSetup, and Session Reuse
"Authentication is the most common test setup challenge — and Playwright provides three patterns. Pattern 1 — storageState: run a setup project that logs in and saves the authentication state to a JSON file. All test projects reuse it via use: { storageState: 'auth.json' }. Pattern 2 — global setup with request context: for API-token-based authentication, obtain tokens before any browser tests start. Pattern 3 — per-test authentication with fixtures: for tests needing different user roles (admin, user, guest), each role gets its own fixture. The decision framework: if all tests use the same user, use storageState (fastest). If different tests need different roles, use per-test fixtures. If authentication is API-based, use global setup."
Pre-Interview Playwright Checklist — 6 Final Actions Before You Walk In
You are hours away from your Playwright SDET interview. Here is the checklist that Mitchell's most successful candidates complete before walking in. The difference between a candidate who "has Playwright experience" and one who lands the offer is often these six verifications — because they demonstrate that you think about Playwright as an engineering platform, not a script runner.
☑️ 1. Explain Auto-Waiting Mechanics to Yourself Out Loud
Can you describe what happens between page.click('#submit') and the click firing? Walk through the five actionability checks — attached, visible, stable, receives events, enabled. Explain what "receives events" means (the element must be the top-most element at its centre point — nothing obscuring it) and why it is the check that eliminates the most flaky tests. Practice this explanation until it flows naturally — it is the most common Playwright interview question in 2026.
☑️ 2. Articulate Your Fixture Strategy
Can you explain when to use test fixtures vs worker fixtures? Test fixture: new instance per test (clean state, test isolation). Worker fixture: single instance per worker process (expensive resources, shared across tests). Have a concrete example ready: "In my current framework, I use a worker-scoped fixture for the database connection pool (created once per worker) and a test-scoped fixture for per-test database transactions (created and rolled back per test for isolation)."
☑️ 3. Demonstrate page.route() Fluency
Can you explain the difference between route.fulfill(), route.abort(), and route.continue()? Fulfill: return a mocked response (request never reaches the network). Abort: block the request entirely. Continue: let the request proceed but modify it. Have a scenario for each: "I use fulfill() for slow/unreliable API endpoints, abort() for analytics and tracking pixels, and continue() for adding auth headers." Be ready to explain pattern matching (glob, regex, predicate) and route ordering.
☑️ 4. Know Your Locator Hierarchy
Can you articulate your locator strategy from most to least preferred? 1. getByRole (semantic, accessibility-based, survives UI refactoring). 2. getByLabel / getByPlaceholder (form-specific, user-facing). 3. getByText (visible text content). 4. getByTestId (explicit data-testid attributes, the gold standard). 5. locator() (CSS/XPath, the escape hatch). Be ready to explain why CSS selectors are your last resort — and why data-testid attributes are worth advocating for with your development team.
☑️ 5. Prepare the Playwright-vs-Selenium-vs-Cypress Decision Framework
Have at least two specific scenarios where Playwright genuinely wins and two where Selenium genuinely wins. Playwright wins: modern TypeScript projects needing cross-browser testing, auto-waiting, and network interception. Selenium wins: Java/Python/C# teams needing true Safari support and W3C protocol stability. Cypress wins: Chromium-only projects where developer experience is the top priority. Avoid tool evangelism — the strongest answer acknowledges that each tool has legitimate use cases.
☑️ 6. Open the SDET Interview Coach App One More Time
The SDET Interview Coach iOS app Playwright modules cover every topic in this guide: auto-waiting mechanics with scenarios where the AI evaluates whether you understand actionability checks at the protocol level; fixture architecture questions calibrated to your seniority level; API mocking with page.route() scenarios; parallel execution and sharding scenarios at enterprise scale; Trace Viewer debugging where the AI presents a failure trace; and the full Playwright-vs-Selenium-vs-Cypress comparison with follow-up questions. Use Job Match to generate 50 bespoke Playwright questions from any job description that mentions browser automation — and walk into your interview having already practised the exact questions your panel will ask.
Ready to Transform Your Testing?
The AI Test Automation Playbook gives you everything you need: Playwright setup, Claude AI integration, MCP deep dive, 10+ ready-to-use prompts, CI/CD pipeline setup, and a 30-day implementation roadmap.
By Mitchell Agoma, Senior SDET & AI Testing Specialist with 8+ years of experience