Top 25 Playwright Interview Questions (With Answers)

How to Use This Guide

Playwright and SDET interviews in 2026 lean heavily on practical, framework-level thinking rather than trivia about API signatures. Interviewers want to know whether you have shipped a suite that survived a real product roadmap, not whether you can recite the arguments to page.click(). Use this guide as a self-quiz: read each question, answer aloud in under sixty seconds, then compare with the model answer below. If you find yourself hesitating on any answer, that is exactly the topic to review before the interview.

The questions are grouped by theme — basics, locators and waiting, assertions, framework design, CI/CD, and advanced scenarios — so you can drill into whichever area your target role emphasises most. A junior SDET role will lean on the first two sections; a senior or staff role will spend most of the loop on framework design, flakiness debugging, and CI strategy.

Prerequisites

• Working knowledge of TypeScript or JavaScript — every Playwright API is async.
• Hands-on time with @playwright/test (not just the Playwright library).
• Familiarity with at least one CI system (GitHub Actions, GitLab CI, Jenkins).
• Understanding of the Page Object Model and fixture-based dependency injection.
• Comfort talking about flakiness — every senior interview probes this.

Basics

1. What is Playwright and how is it different from Selenium?

Playwright is a Node-first automation framework by Microsoft. It bundles browsers, auto-waits by default, supports API testing, and drives three engines (Chromium, Firefox, WebKit) through a single unified API — unlike Selenium, which relies on external drivers and has no built-in auto-waiting.

2. Which browsers does Playwright support?

Chromium (with Chrome and Edge channels), Firefox, and WebKit (Safari's engine). One test file can run against all three via the projects config.

3. What language bindings does Playwright have?

TypeScript/JavaScript (primary), Python, Java, and .NET. TypeScript is the best-supported binding and gets features first.

4. What is @playwright/test versus the Playwright library?

The library (playwright) is the raw automation API — useful for scripts and embedding. @playwright/test wraps it with a full test runner, parallelism, fixtures, config, retries, and reporters. Use @playwright/test for anything test-shaped.

5. What does a Playwright test's default isolation look like?

Every test gets its own BrowserContext — a fresh, cookie-less, storage-less browsing profile. That isolation is what makes parallel workers safe without hand-rolled cleanup.

Locators & Waiting

6. Why prefer getByRole over CSS selectors?

Role-based locators are more stable across refactors and mirror how assistive tech sees the page, so they double as an accessibility guardrail. A CSS selector breaks the moment a designer changes a class name; a role selector survives.

7. How does auto-waiting work?

Before every action Playwright verifies actionability — attached, visible, stable, enabled, receives events — and retries within the action timeout (30s default). No manual sleep needed.

8. Difference between locator.click() and elementHandle.click()?

Locators are lazy references, re-queried on every use; element handles are snapshots that can go stale as the DOM changes. Always use locators.

9. When would you use waitForResponse instead of an assertion?

When the UI update depends on a specific backend request completing, and you want to know the request succeeded before continuing — for example, waiting for a POST /orders to return 201 before asserting the confirmation page.

10. What is the difference between locator.first() and locator.nth(0)?

Functionally identical for the first element, but first() reads more clearly. Both are strict-mode friendly compared to leaving a multi-match locator unresolved.

Assertions

11. What is a web-first assertion?

An assertion that auto-retries against the live page until the condition passes or the assertion timeout expires. Every expect(locator).toBe*() from @playwright/test is web-first.

12. Difference between toHaveText and toContainText?

toHaveText requires an exact match after whitespace normalization. toContainText checks for a substring — more forgiving of dynamic content like timestamps.

13. When would you use expect.soft()?

When validating several independent facts in one test and you want to see every failure at once — for example, a landing-page smoke check where nav, hero, and footer are all verified.

Framework Design

14. How do you organise a Playwright project?

pages/ for page objects, components/ for reusable widgets, fixtures/ for custom test fixtures, data/ for test data and builders, tests/ split by ui/api/e2e, utils/ for helpers, and one central playwright.config.ts.

15. When would you avoid the Page Object Model?

For tiny throwaway suites where the overhead is not worth it, or when a shared component (not a page) is the right abstraction — favour composition over rigid inheritance.

16. How do you share login state across tests?

Log in once in globalSetup, save the authenticated storageState to a JSON file, and reference it in playwright.config.ts under use.storageState. Every test starts already authenticated.

17. What are fixtures and why do they matter?

Fixtures are dependency-injection helpers built into @playwright/test. They construct dependencies (page objects, API clients, authenticated sessions), inject them into any test that names them, and tear them down automatically. They are the mechanism that keeps individual tests short and readable.

18. How do you handle data-driven tests?

Loop over a data table with for...of and generate one test per case inside the loop. Each case gets its own name, trace, and pass/fail line — much better than a single test with an internal loop.

CI/CD & Reporting

19. How do you speed up a slow Playwright suite in CI?

Enable fullyParallel, use --shard across a matrix of runners, cache Playwright browsers between runs, and disable video/trace on green runs (retain-on-failure). Consider splitting smoke and full-regression tags to keep PR feedback fast.

20. How do you debug a failing CI run?

Enable trace: 'on-first-retry', upload the trace as a build artifact, then open it locally with npx playwright show-trace trace.zip — you get a full DOM+network timeline of the failure.

21. Should you retry tests in CI?

Yes — retries: 2 on CI, 0 locally. Retries mask genuinely flaky tests, so track your flake rate week over week and fix any test that consistently retries. Retries are a safety net, not a substitute for reliability.

22. Which reporters do you use and why?

list for local console output, html for the interactive HTML dashboard, and junit for CI dashboard integration (GitHub Actions summary, GitLab widgets, Jenkins). Wire in Allure only if leadership needs long-term trend dashboards.

Advanced Scenarios

23. How would you mock a third-party API in Playwright?

Use page.route() to intercept requests to the target URL and reply with a fixture. That keeps the test independent of the third party's availability and lets you exercise error paths (rate-limited, 500, network timeout) deterministically.

24. How do you test file downloads?

Wait for the download event: const [download] = await Promise.all([page.waitForEvent('download'), page.getByRole('button', { name: 'Export' }).click()]) — then inspect download.suggestedFilename() and save it with download.saveAs().

25. How do you handle authentication for API tests?

Inject an APIRequestContext through a fixture, hit the token endpoint once in setup, and attach the token to every subsequent request via extraHTTPHeaders. Keeps auth logic out of individual tests.

26. How do you keep visual regression tests useful rather than noisy?

Mask dynamic regions (timestamps, avatars) with the mask option on toHaveScreenshot, run on a single browser/OS to eliminate rendering differences, and gate diffs by a small pixel threshold. Store baselines per project so cross-browser drift is visible.

Common Interview Pitfalls

• Claiming Playwright has 'no flakiness' — every senior interviewer will push back. Talk about how you measure and reduce it.
• Confusing @playwright/test with the raw library — know which one you are describing.
• Answering framework questions with feature lists instead of trade-offs — interviewers want to hear what you chose and why, not everything Playwright supports.
• Reaching for waitForTimeout in a live coding round — it signals immediately that you do not trust auto-waiting.
• Forgetting to mention Trace Viewer when asked about debugging — it is Playwright's killer feature.

Debugging Story Questions

Senior loops almost always include an open-ended 'tell me about a flaky test you fixed' question. Prepare a two-minute story with a clear structure: the symptom (which test, how often it failed), the diagnosis (trace showed a race with an unhandled request), the fix (waitForResponse on the specific endpoint), and the systemic follow-up (an ESLint rule banning waitForTimeout so the same class of bug cannot re-enter the codebase). Real stories with real numbers beat generic advice every time.

When to Use Playwright (and When Not To)

Reach for Playwright for end-to-end browser automation, cross-browser regression suites, and API+UI hybrid tests. It is the strongest option in the market for those jobs and has been for two years.

Do not use Playwright for pure unit tests (use Vitest or Jest), for load testing (use k6 or Gatling), or for accessibility audits alone (use axe-core, though Playwright integrates with it). Choosing the right tool for each job is itself an interview signal.

FAQ

How long should I prepare before a Playwright interview?

If you have shipped a real suite, one focused evening reviewing this guide is usually enough. If you are new to Playwright, plan on a week: build a small five-test suite with a fixture, a page object, and a CI workflow, and you will be able to answer every question here from experience.

Do interviewers care about the Selenium comparison?

Yes — most teams migrating today are moving off Selenium, so knowing where Playwright wins (auto-waiting, bundled browsers, Trace Viewer, single API for three engines) and where Selenium still shines (Java ecosystem, mobile via Appium) is a common opening question.

Should I bring a code sample?

A public GitHub repo with a small Playwright suite — POM, fixtures, a GitHub Actions workflow — is worth ten answers on a whiteboard. Interviewers can see how you actually write tests.

What about live coding rounds?

Expect a small task like 'automate this login form and assert the dashboard heading'. Narrate as you go, prefer getByRole locators, and lean on web-first assertions instead of manual waits — the interviewer is watching your habits as much as your code.

Summary

Playwright interviews in 2026 test practical framework thinking more than API trivia. The candidates who stand out talk about auto-waiting as a design philosophy rather than a feature, describe Page Objects and fixtures with real trade-off language, and can tell a concrete story about a flaky test they diagnosed with the Trace Viewer.

Work through every question here, build a small reference suite you can point to on GitHub, and rehearse one strong flakiness-debugging story. Do that and you will walk into your next SDET loop able to answer both the fundamentals and the senior-level design questions with equal confidence.