100 Playwright Interview Questions and Answers (2026)

Introduction

This is the complete Playwright interview preparation set — 100 questions drawn from the same topics we cover across every tutorial on this site: fundamentals, locators, the test runner, framework architecture, API testing, flakiness, CI/CD, and the AI-assisted testing questions that started appearing in 2026 interviews. Each answer is written the way you should actually say it out loud: short, specific, and honest about trade-offs.

Use it as a self-quiz rather than a reading exercise. Read the question, answer aloud in under sixty seconds, then compare. Anywhere you hesitate is exactly the topic to revise before your interview.

How to Use This Guide

1. Work through one section per day rather than skimming all 100 in one sitting.
2. Answer aloud — writing the answer down hides the hesitation that shows up in a live round.
3. For every answer, prepare one concrete example from a real project you worked on.
4. Mark the questions you fumble and revisit them the day before the interview.
5. Practise the coding round separately: automate a login form and assert a dashboard heading while narrating your reasoning.

Playwright Fundamentals

Almost every Playwright interview opens here. The goal is not to recite documentation — it is to show that you understand what the tool does differently from Selenium and Cypress, and why that matters for a real suite.

1. What is Playwright and who maintains it?

Playwright is an open-source end-to-end automation framework from Microsoft that drives Chromium, Firefox and WebKit through a single API. It ships with its own test runner (@playwright/test), auto-waiting, tracing, network interception and parallel execution built in, so you rarely need third-party plugins to get a production suite running.

2. What is the difference between the Playwright Library and Playwright Test?

The Library (playwright) is just the browser automation API — you launch a browser and drive it from any script. Playwright Test (@playwright/test) adds the runner: fixtures, parallel workers, retries, reporters, projects and the config file. For anything test-shaped you want @playwright/test; the raw library is for scraping, tooling or embedding automation inside another product.

3. How does Playwright differ from Selenium?

Selenium talks to browsers over the WebDriver protocol and needs explicit waits; Playwright talks over the DevTools/CDP-style protocol with a persistent connection, giving it auto-waiting, network interception, and a much faster feedback loop. Playwright also bundles the runner, reporting and tracing, whereas Selenium relies on TestNG/JUnit/pytest plus separate reporting libraries.

4. How does Playwright differ from Cypress?

Cypress runs inside the browser, which makes debugging pleasant but limits multi-tab, multi-origin and true cross-browser (WebKit) support. Playwright runs out-of-process, supports multiple tabs, multiple origins, multiple browser contexts and real WebKit, and parallelises for free in open source.

5. Which languages does Playwright support?

TypeScript/JavaScript, Python, Java and .NET. The TypeScript version gets features first and has the richest runner, which is why most teams standardise on it.

6. What is a browser, a browser context and a page?

A browser is the launched process. A browser context is an isolated incognito-like profile inside that process with its own cookies, storage and permissions. A page is a single tab inside a context. Contexts are cheap, so Playwright gives every test its own context — that is what makes tests independent by default.

7. What is auto-waiting in Playwright?

Before every action Playwright runs actionability checks: the element must be attached, visible, stable (not animating), able to receive events, and enabled. It retries those checks until the timeout expires, which removes the vast majority of the sleeps and explicit waits you would write in Selenium.

8. What are web-first assertions?

Assertions from expect() such as toBeVisible(), toHaveText() and toHaveURL() retry until the condition is true or the timeout is reached. That makes them resilient to async rendering, unlike a plain assertion on a value you read once.

9. What is a locator and how is it different from an element handle?

A locator is a lazy, re-resolvable description of an element — it is looked up again on every action, so it survives re-renders. An ElementHandle points to a specific DOM node and goes stale when React or Angular replaces it. Prefer locators; use handles only for rare low-level work.

10. Which locator strategies should you prefer?

In order: getByRole, getByLabel, getByPlaceholder, getByText, getByTestId, and only then CSS or XPath. Role and label locators mirror how a user (and a screen reader) finds the element, so they break far less often than brittle CSS chains.

11. What is the difference between page.click() and locator.click()?

page.click(selector) resolves the selector once at call time; locator.click() re-resolves the locator with retries and actionability checks. The locator API is the modern, recommended approach — the page-level selector shortcuts are legacy.

12. How do you handle strict mode violations?

Playwright throws when a locator matches more than one element. Fix it by narrowing the query (add a role, a name, a parent scope) rather than reaching for .first(). Using .first() hides ambiguity that will bite you when the page changes.

13. How does Playwright handle iframes?

Use page.frameLocator('iframe#checkout').getByRole('button'). FrameLocator behaves like a normal locator — lazy, retried and strict — so nested iframes just chain.

14. How do you handle shadow DOM?

Playwright pierces open shadow roots automatically with CSS and text engines, so getByRole and getByText normally just work. Closed shadow roots are not accessible — that is a browser restriction, not a Playwright limitation.

15. How do you handle new tabs and popups?

Wrap the trigger in context.waitForEvent('page'): const [popup] = await Promise.all([context.waitForEvent('page'), link.click()]). You then drive popup like any other page and can assert on both tabs.

16. How do you handle native dialogs (alert, confirm, prompt)?

Register a handler before triggering: page.on('dialog', d => d.accept('text')). Playwright auto-dismisses dialogs when no handler is registered, which is why an unhandled confirm looks like 'nothing happened'.

17. How do you upload and download files?

Upload with locator.setInputFiles(path) — or expect_file_chooser style page.waitForEvent('filechooser') when the input is hidden behind a button. Download with const [download] = await Promise.all([page.waitForEvent('download'), link.click()]) and then download.saveAs(path).

18. What is the difference between waitForTimeout and waitForLoadState?

waitForTimeout is a hard sleep and is a red flag in review — it either wastes time or is too short. waitForLoadState('networkidle'|'domcontentloaded') waits for an actual browser signal. In most cases you need neither, because assertions and actions auto-wait.

19. What does test.step() do?

It groups actions into a named step that shows up in the HTML report and trace. Steps make failures readable for non-authors — instead of 'click failed', the report says 'Step: submit checkout > click Pay'.

20. How do you run tests in headed mode and debug them?

npx playwright test --headed for a visible browser, --debug for the Playwright Inspector with step-through, and --ui for UI Mode with time-travel, watch mode and locator picking. UI Mode is the fastest local loop.

Test Runner, Config and Execution

This block separates people who have run a suite in CI from people who have only written tests locally. Talk about concrete numbers — workers, shards, timeouts, retry policy.

1. What lives in playwright.config.ts?

testDir, timeout and expect.timeout, retries, workers, reporter list, the use block (baseURL, trace, screenshot, video, storageState), and projects for browsers or environments. It is the single place where suite-wide policy is expressed.

2. What are projects and why use them?

A project is a named configuration of the same tests — chromium/firefox/webkit, desktop/mobile viewports, or staging/prod base URLs. Projects also express dependencies, which is how a 'setup' project can log in once before every other project runs.

3. How does parallelism work in Playwright?

Playwright runs test files in parallel across worker processes (one browser per worker). Tests inside a file run serially unless you call test.describe.configure({ mode: 'parallel' }). Each worker is a separate process, so no shared in-memory state.

4. How many workers should you use in CI?

Start at roughly the number of vCPUs — commonly 4 on a standard runner — then tune. Too many workers thrash CPU and memory and manufacture flakiness that looks like application instability.

5. What is sharding and when do you need it?

--shard=1/4 splits the suite across four machines running in parallel, then you merge the blob reports into one HTML report. You need it once wall-clock time on a single runner exceeds your feedback budget (usually around ten minutes).

6. How do retries work and are they a good idea?

retries: 2 in CI re-runs only failed tests, and a test that passes on retry is marked 'flaky'. Retries are a safety net for infrastructure noise, not a fix — track the flaky count as a metric and drive it down, otherwise retries slowly hide real bugs.

7. What are the different timeout levels?

Global timeout for the whole run, test timeout per test, expect timeout per assertion, action timeout per click/fill, and navigation timeout. Set them explicitly in config instead of sprinkling per-call timeouts through the specs.

8. What is globalSetup and globalTeardown?

Module-level hooks that run once before and after the entire run — typically to seed a database, log in and save storageState, or spin up a mock server. They run in Node, not in a browser context.

9. What is the difference between beforeAll, beforeEach and fixtures?

beforeAll runs once per worker per file, beforeEach runs before each test. Fixtures do the same work but with dependency injection, automatic teardown, lazy instantiation and typed access — which is why mature frameworks use fixtures and keep hooks rare.

10. How do you tag and slice a suite?

Tag test titles (@smoke, @regression) and filter with --grep '@smoke', or use the tag option in modern versions. A two-minute smoke slice on every PR plus a full nightly regression is the standard split.

11. What reporters does Playwright provide?

list, dot, line, html, json, junit, blob, and github. Most teams run ['html', 'junit'] in CI so humans get the interactive report and the CI system gets machine-readable results. Custom reporters are a class implementing the Reporter interface.

12. What is the trace viewer?

A time-travel debugger: it records a DOM snapshot before and after every action, plus network, console and source. Configure trace: 'on-first-retry' so you get a trace exactly when something failed in CI without paying the cost on every green run.

13. How do you run a single test or a single file?

npx playwright test tests/login.spec.ts, add :42 for a line number, or use -g 'partial title'. In UI Mode you just click the test.

14. How do you handle multiple environments?

Read baseURL and credentials from environment variables in the config, keep a .env per environment (never committed), and add projects or a config-per-env file. Tests should never hardcode a URL.

15. What is test.describe.serial and when is it dangerous?

It forces tests in a block to run in order and skips the rest after a failure. It is useful for genuinely sequential flows, but it couples tests together, kills parallelism and makes failures cascade — use it sparingly.

16. How do you skip or conditionally run tests?

test.skip(), test.fixme(), test.fail(), and the conditional forms test.skip(browserName === 'webkit', 'reason'). Always include a reason — an unexplained skip becomes permanent.

17. How does Playwright isolate tests?

Every test gets a fresh browser context, so cookies, localStorage and sessionStorage start clean. That gives you isolation at the browser level; you still need to isolate data at the application level.

18. How do you reuse authentication state?

Log in once in a setup project, save the cookies and localStorage with context.storageState({ path }), then point use.storageState at that file. Tests start authenticated with no UI login, which typically removes several seconds from every test.

19. How do you run tests against multiple user roles?

Generate one storageState file per role in setup, then either define one project per role or expose a role-aware fixture that returns a context created from the right state file.

20. How do you update snapshots or baseline screenshots?

npx playwright test --update-snapshots. Baselines are OS- and browser-specific, so generate them in the same Docker image CI uses or you will chase phantom pixel diffs forever.

Framework Design and Architecture

Senior interviews live here. Interviewers are listening for trade-off language — what you chose, what you rejected, and what it cost you.

1. What is the Page Object Model and why use it?

A POM wraps a page or component in a class that exposes intent-level methods (login(user), addToCart(sku)) and hides locators. It centralises change: when the DOM moves, you edit one file instead of forty specs.

2. What is the biggest mistake teams make with Page Objects?

Putting assertions inside them and letting them grow into 2,000-line god objects. A page object should expose state and actions; the spec decides what is correct. Split by component, not by URL.

3. What is the Component Object Model?

Instead of one class per page, you model reusable UI components (header, data grid, date picker) and compose pages from them. It fits modern component-driven front ends far better than page-per-URL modelling.

4. What is a base page class for?

Shared plumbing every page needs: the page instance, navigation helpers, common waits, screenshot helpers, logging. Keep it thin — a fat base class becomes an inheritance trap.

5. What are custom fixtures and why are they better than hooks?

A fixture is a named dependency with setup and teardown that Playwright injects only into tests that ask for it. They compose, they are typed, they tear down in reverse order, and they avoid the shared mutable state that beforeEach blocks encourage.

6. How do you build a typed fixture in TypeScript?

Extend the base test: export const test = base.extend<{ loginPage: LoginPage }>({ loginPage: async ({ page }, use) => { await use(new LoginPage(page)); } }). Specs then import your test and destructure { loginPage }.

7. What is a worker-scoped fixture?

A fixture created once per worker instead of once per test, declared with { scope: 'worker' }. Use it for expensive shared resources — an API token, a seeded tenant, a database pool — but never for mutable per-test state.

8. How do you manage test data?

Small deterministic fixtures live in the repo as JSON; anything that must be unique per run is generated by a builder with a random suffix so parallel workers never collide. Create data through the API, not the UI, and clean it up in teardown.

9. How do you handle secrets in a test framework?

Environment variables injected from the CI secret store, never committed. A .env.example documents the required keys. Mask them in logs and never print a response body that could contain a token.

10. How do you structure a Playwright repository?

tests/ by domain, pages/ or components/ for objects, fixtures/ for test extensions, api/ for service clients, data/ for fixtures and builders, utils/ for helpers, and a single playwright.config.ts at the root. Predictability matters more than cleverness.

11. How do you add logging to a framework?

Wrap actions in test.step for report-level visibility and add a lightweight logger fixture for structured console output with the test name and worker index. Attach payloads with testInfo.attach so they land in the HTML report instead of scrolling past in CI logs.

12. What is dependency injection in the context of Playwright?

Fixtures are the DI container. Instead of a spec constructing pages, clients and data, it declares what it needs in the destructured argument list and Playwright builds the graph, including teardown ordering.

13. How do you support both UI and API testing in one framework?

Share the config, fixtures and reporting; separate the projects. An apiRequest fixture built from request.newContext() with baseURL and auth headers lets UI tests seed state over HTTP and lets API tests run headless with no browser at all.

14. How do you make a framework easy to onboard?

A README that explains the layout, a single npm script that runs a two-minute smoke suite, a template spec with comments, and lint rules that block anti-patterns. If a new engineer cannot land a green test on day one, the framework has too much friction.

15. How do you enforce conventions across a large team?

ESLint with the playwright plugin (no waitForTimeout, no focused tests, no conditional expects), a PR template, and code owners on the fixtures and config files. Automated rules scale; tribal knowledge does not.

16. When should you NOT use Page Objects?

For a handful of throwaway smoke tests, or for pure API suites where there is no page. Adding abstraction before you have duplication is speculative design and slows the team down.

17. How do you version and share a framework across teams?

Publish the shared core (fixtures, base page, clients, reporters) as a private npm package with semantic versioning, and let product teams depend on it while owning their own specs. Breaking changes get a migration note.

18. How do you measure the health of a test suite?

Four numbers: pass rate, flake rate, median duration, and mean time to diagnose a failure. If you cannot answer those, the suite is not yet a product.

19. What is the difference between a smoke, regression and E2E suite?

Smoke is a small critical-path slice that runs on every PR in a couple of minutes. Regression is the full suite that runs nightly or pre-release. E2E describes scope — a journey across multiple services — not schedule.

20. How do you decide what to automate at the UI level?

Automate a journey at the UI only when the risk lives in the UI. Business rules belong in API or unit tests, which are ten to a hundred times faster and far less flaky. A good ratio is a thin layer of UI journeys over a broad API layer.

API Testing, Network and Mocking

Playwright's request context is a first-class HTTP client, and interviewers increasingly probe it because hybrid UI+API tests are now standard practice.

1. How do you make API calls in Playwright?

Use the request fixture: await request.post('/api/orders', { data }). It shares cookie state with the browser context when you use page.request, or runs standalone with request.newContext({ baseURL, extraHTTPHeaders }).

2. What is the difference between request and page.request?

page.request reuses the page's cookies and storage state, so it is authenticated exactly like the user in the browser. The standalone request fixture is independent — better for pure API suites and for setting up state as a different user.

3. Why seed data over the API instead of the UI?

Speed and stability. Creating an order through five UI screens takes twenty seconds and can fail for reasons unrelated to the thing you are testing; one POST takes 200 milliseconds and fails only if the API is broken.

4. How do you validate an API response schema?

Parse the body with Zod (or Ajv/JSON Schema) and assert the parse succeeds. Schema validation catches contract drift — a field renamed or a type changed — that a handful of field-level assertions would miss.

5. How do you intercept and mock network calls?

page.route('**/api/products', route => route.fulfill({ json: mockData })). You can also modify a real response with route.fetch() then fulfill, or block third-party noise with route.abort().

6. When should you mock and when should you hit the real API?

Mock to force hard-to-reproduce states — empty lists, 500s, slow responses — and to isolate front-end behaviour. Hit the real API for the critical journeys where integration is exactly the risk you are testing.

7. How do you test error and edge-case states?

Fulfil the route with the failure you want: route.fulfill({ status: 500 }) or route.abort('failed'). This is the cheapest way to cover retry logic, error toasts and empty states that QA can rarely reproduce manually.

8. How do you assert on network requests?

page.waitForRequest / page.waitForResponse with a URL predicate, or collect requests via page.on('request'). Useful for verifying analytics events and that the front end sends the payload the contract expects.

9. How do you handle authentication in API tests?

Fetch a token once in a worker-scoped fixture and inject it as extraHTTPHeaders on the request context. Refresh it when it expires rather than logging in per test.

10. How do you test GraphQL with Playwright?

POST the query and variables to the single endpoint and assert on data and errors. Intercept with page.route and branch on the operationName inside the request body, since every GraphQL call shares one URL.

11. Can Playwright test WebSockets?

Yes — page.on('websocket') gives you frame-level events, and newer versions support routeWebSocket for mocking. For a pure protocol test outside the browser you would use a Node WebSocket client inside the same suite.

12. How do you test file downloads from an API?

Request the endpoint with the request fixture, read response.body(), and assert on content type, size and parsed content — no browser needed.

13. How do you handle rate limiting in API tests?

Use a dedicated test account or tenant, back off and retry on 429 inside the client wrapper, and cap worker count for the API project. Never disable the limit in a shared environment.

14. What is contract testing and does Playwright replace it?

Contract testing (Pact and similar) verifies producer and consumer agree, independently of a deployed environment. Playwright API tests verify a deployed system. They complement each other — Playwright does not replace contract tests.

15. How do you combine UI and API assertions in one test?

Act in the UI, then assert the resulting state over the API — or seed via API and assert the UI renders it. That hybrid pattern catches integration bugs that a pure UI test would miss and runs far faster than a full UI journey.

Flakiness, Debugging and Stability

Every senior interview probes this. Answer with a process, not a trick — how you detect flakiness, how you diagnose it, and how you stop it coming back.

1. What causes flaky tests?

Four families: timing (asserting before the app settles), shared state (tests fighting over the same data), environment (network, third-party services, CI resource starvation), and non-determinism in the app itself (animations, random ordering, dates). Diagnosing which family you are in is most of the fix.

2. How do you debug a test that fails only in CI?

Enable trace on-first-retry, download the trace artifact, and open it with npx playwright show-trace. The DOM snapshot plus network log almost always shows the difference between CI and local — usually data, timing or viewport.

3. How do you fix a test that fails intermittently on a click?

Look at what the actionability check was waiting for in the trace. Typically an overlay, a toast or an animation intercepts the click. The fix is to wait for the blocking element to disappear, not to add a sleep or force: true.

4. Is force: true ever acceptable?

Rarely. It skips actionability checks, which means it also skips the very signal that would tell you the UI is not ready. Legitimate uses are narrow — a custom control that never reports as stable, for example — and should carry a comment explaining why.

5. How do you keep flake rate below one percent?

Use retrying assertions everywhere, give every test its own data and context, quarantine a newly flaky test the day it appears, and treat every intermittent failure as a bug with an owner. Track the number weekly.

6. What is quarantining and how do you do it responsibly?

Move a flaky test out of the blocking suite so it stops eroding trust, but file a ticket with an owner and a deadline. A quarantine with no expiry date is just deletion with extra steps.

7. How do you handle animations in tests?

Disable them globally in the test environment (CSS media query prefers-reduced-motion or an injected stylesheet), and use the animations: 'disabled' option for screenshots. Fighting animations with waits is a losing game.

8. How do you make tests deterministic when the app uses dates or random data?

Freeze the clock with page.clock (or inject a Date shim), seed random generators, and assert on structure rather than exact values where the value genuinely varies.

9. How do you debug a locator that does not match?

Use UI Mode or codegen's pick-locator to inspect what Playwright sees, and page.locator(...).count() to check matches. Nine times out of ten the element is inside an iframe, behind a role you did not expect, or rendered later than you assumed.

10. What is the difference between a bug and a flake?

A flake fails non-deterministically with the same inputs; a bug fails consistently. The dangerous middle ground is a real race condition in the product that presents as a flake — which is why you investigate before you retry.

CI/CD, Docker and Scaling

Interviewers want evidence you have run this suite somewhere other than your laptop. Concrete pipeline details score highly.

1. How do you run Playwright in GitHub Actions?

Checkout, setup-node with cache, npm ci, npx playwright install --with-deps, npx playwright test, then upload playwright-report as an artifact with if: always() so you get the report on failure too.

2. Why use the official Playwright Docker image?

mcr.microsoft.com/playwright ships the browsers and all system dependencies at matching versions, which removes the whole class of 'works locally, missing libnss3 in CI' failures and makes screenshots reproducible.

3. How do you speed up a slow pipeline?

Shard across runners, cache dependencies and browsers, reuse authentication via storageState, seed data over the API, run smoke on PRs and full regression nightly, and delete tests that no longer earn their runtime.

4. How do you merge reports from sharded runs?

Use the blob reporter on each shard, upload the blobs, then npx playwright merge-reports --reporter=html ./all-blob-reports on a final job.

5. How do you publish reports so stakeholders can read them?

Publish the HTML report to GitHub Pages, S3 or an artifact server, and post the summary plus link to Slack. A report nobody can open is a report nobody trusts.

6. Should test failures block a deployment?

The smoke suite should block, because it covers revenue-critical paths and runs fast. The full regression usually gates a release rather than every merge. Blocking on a flaky suite trains people to bypass the gate.

7. How do you handle test data in a shared CI environment?

Namespace everything by run id, create data through the API in setup, delete it in teardown, and never assume a record exists. Parallel pipelines will collide otherwise.

8. How do you run cross-browser tests efficiently?

Run the full suite on Chromium for every PR and the critical slice on Firefox and WebKit nightly. Running everything on three engines every commit rarely pays for the runtime it costs.

9. How do you integrate Playwright with a test management tool?

Emit JUnit XML for the CI system, and use a custom reporter or annotations to push results to Xray, TestRail or Zephyr keyed by a test id annotation in the title.

10. How do you monitor production with Playwright?

Run a tiny synthetic suite of critical journeys on a schedule against production with read-only accounts, alert on failure, and keep it strictly separate from the regression suite so noise does not reach the on-call rota.

Advanced Topics, Accessibility and AI

The differentiator questions in 2026. Even a short, honest answer about MCP and AI-assisted testing puts you ahead of most candidates.

1. How do you do visual regression testing in Playwright?

expect(page).toHaveScreenshot() with baselines committed per platform, maxDiffPixelRatio to absorb noise, and animations disabled. Generate baselines in the same Docker image CI uses.

2. How do you test accessibility?

Integrate @axe-core/playwright and assert there are no violations of the rule sets you care about, plus lean on getByRole locators so your tests fail when the accessibility tree breaks.

3. How do you test mobile viewports?

Use devices from @playwright/test in a project: { ...devices['iPhone 14'] }. It sets viewport, user agent, device scale and touch support. It is emulation, not a real device — say so in the interview.

4. Can Playwright do performance testing?

It can capture page metrics, Core Web Vitals and network timings, and it is excellent for single-user performance regressions. It is not a load testing tool — use k6 or Gatling for concurrency.

5. What is component testing in Playwright?

Experimental support for mounting a React/Vue/Svelte component in a real browser and testing it in isolation, giving you real rendering without a full app boot. Useful for design systems.

6. What is the Playwright MCP server?

A Model Context Protocol server that exposes browser control to an AI agent, letting tools like GitHub Copilot drive a real browser — navigate, inspect the accessibility tree, and generate tests from what they actually observe rather than from guessed selectors.

7. How does AI change test automation work?

It accelerates the mechanical parts: scaffolding page objects, drafting specs, explaining failures and suggesting locators. It does not decide what is worth testing, own the risk model, or judge whether a failure is a bug — that judgement is still the engineer's job.

8. How do you use Copilot responsibly in a test framework?

Give it strong context (the framework conventions, a template spec), review every generated locator against the accessibility tree, never let it paste secrets into prompts, and treat generated tests as a draft that must pass review like any other code.

9. What is agentic testing?

An AI agent that explores the app, proposes and executes test scenarios, and reports findings, typically via MCP browser control. It is promising for exploratory coverage and gap discovery; deterministic regression suites remain hand-owned.

10. Where do you see test automation heading?

Toward fewer, higher-value UI journeys over a broad API and contract layer, with AI generating and maintaining the mechanical layers while engineers own risk, architecture and interpretation. The scarce skill is judgement, not typing tests.

Behavioural and Experience Questions

Technical rounds end here, and this is where offers are won or lost. Use concrete stories with numbers — before, action, after.

1. Tell me about a flaky test you fixed.

Pick one story with a measurable outcome: the symptom, how you diagnosed it (trace viewer, logs), the root cause (usually shared data or a race), the fix, and the resulting flake rate. Numbers make it credible.

2. How did you migrate from Selenium to Playwright?

Describe a strangler approach: new tests in Playwright, port the highest-value Selenium journeys first, run both suites in parallel until confidence is high, then delete. Mention what you measured — runtime, flake rate, maintenance hours.

3. How do you decide test coverage with limited time?

Risk-based: revenue paths, regulatory paths, and the areas with the most production incidents first. Coverage percentage is a vanity metric; incidents caught before release is not.

4. How do you handle a developer who says your test is wrong?

Show the trace. Evidence-first conversations stay technical instead of turning territorial, and roughly half the time the test really is wrong — say that out loud in the interview, it signals maturity.

5. How do you convince leadership to invest in automation?

Translate to their metrics: release frequency, escaped defects, hours of manual regression removed, mean time to detect. 'We cut a two-day regression cycle to forty minutes' lands; 'we have 800 tests' does not.

Final Preparation Tips

• Never claim Playwright removes flakiness — explain how you measure and reduce it instead.
• Know the difference between @playwright/test and the raw library; interviewers use it to separate readers from users.
• Bring one framework decision you regret. Nothing signals seniority faster than a well-reasoned mistake.
• Mention the Trace Viewer whenever debugging comes up — it is Playwright's flagship feature and candidates forget it.
• In the coding round, prefer getByRole locators and web-first assertions, and narrate as you type.

Summary

One hundred questions is more than any single interview will cover, but the point is coverage of the shape of the conversation: fundamentals to prove you know the tool, runner and config to prove you have run it at scale, architecture to prove you can own it, flakiness and CI to prove you have maintained it, and AI to prove you are current. Prepare a story for each of those five areas and you will be ready for almost any Playwright interview in 2026.