Most Asked Playwright Interview Questions in 2026

Introduction

These are the questions that come up again and again across screening calls, technical rounds and panel interviews — collected from the topics candidates report being asked most often. They are ordered roughly the way an interview flows: tool comparison first, then core mechanics, then framework, stability, CI and AI.

The Most Frequently Asked Questions

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.

7. 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.

8. 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.

9. 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.

10. 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.

11. 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.

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. 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.

14. 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.

15. 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.

16. 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().

17. 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.

18. 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.

19. 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.

20. 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.

Patterns Behind the Questions

Notice what these twenty questions have in common: almost none of them ask for API syntax. They ask why the tool behaves the way it does, and how you handled the consequence in a real suite. Interviewers assume you can look up a method signature; they cannot look up your judgement.

• Comparison questions test whether you chose Playwright deliberately or inherited it.
• Mechanics questions (auto-waiting, contexts, assertions) test whether you understand asynchronous UIs.
• Architecture questions test whether you can own a framework rather than only write specs.
• Flakiness and CI questions test whether you have maintained a suite past its first month.
• AI and MCP questions test whether you are current with how the role is changing.

Summary

Prepare these twenty with a concrete example attached to each and you will recognise most of what any Playwright interview throws at you. For deeper coverage, work through the full 100-question set; for a last-minute refresher, use the Top 10 and Top 5 lists.