34 Playwright interview questions with model answers

What they are assessing

Whether you understand the architecture rather than just the API surface.

Model answer

Playwright is a browser automation and testing framework from Microsoft that drives Chromium, Firefox and WebKit through a single API. Architecturally the key difference is that Playwright talks to browsers over a persistent WebSocket connection using each browser debugging protocol, rather than sending each command as a separate HTTP request through a driver executable as Selenium does with the W3C protocol. That single duplex connection is why Playwright is faster and why it can offer capabilities like network interception and event listening that are awkward in Selenium. It also ships as a full test framework with runner, assertions, fixtures and reporting, where Selenium is only the automation library.

Likely follow-up

So what would make you still choose Selenium on a project?

What they are assessing

The core object model. Getting this wrong signals very little hands-on use.

Model answer

A browser is the launched browser process, which is expensive to start so it is usually shared. A browser context is an isolated session inside that browser with its own cookies, local storage and cache, roughly equivalent to a fresh incognito profile but far cheaper than a new browser. A page is a single tab within a context. The practical consequence is the isolation model: each test gets its own context, so tests cannot leak state into each other, and creating a context takes milliseconds rather than the seconds a new browser would cost. That is a large part of why Playwright parallelises well.

Likely follow-up

How would you use contexts to test two users interacting at the same time?

What they are assessing

Operational awareness, since this is a common CI stumbling block.

Model answer

Playwright downloads and pins its own browser binaries with the npx playwright install command, rather than driving whatever browser happens to be on the machine. That is a real advantage over Selenium because the browser and the automation library are versioned together, so you do not get the overnight breakage caused by a browser auto-updating away from its driver. In CI you either run the install step or use the official Playwright Docker image, which has the browsers and system dependencies baked in. The trade-off is a larger initial download and the need to update browsers deliberately when you upgrade the library.

What they are assessing

Awareness of the ecosystem trade-off.

Model answer

Playwright has official bindings for TypeScript and JavaScript, Python, Java and .NET. The choice does matter more than with Selenium, because the Playwright test runner with its fixtures, parallelism model, trace viewer integration and built-in reporters is a first-class part of the Node offering. In Python you would typically pair it with pytest, and in Java with JUnit or TestNG, which works well but means some runner features come from the third-party framework instead. If the team has no strong language constraint, TypeScript gets the most complete experience and the fastest access to new features.

What they are assessing

Whether you follow the user-facing locator philosophy or default to CSS.

Model answer

Playwright recommends user-facing locators that resemble how a person finds an element: getByRole with an accessible name, then getByLabel, getByPlaceholder, getByText and getByTitle, with getByTestId as the deliberate fallback. The reasoning is that these are resilient to markup and styling changes, and they double as a light accessibility check, because if getByRole cannot find your button then a screen reader probably cannot either. CSS and XPath still work and are sometimes necessary, but they couple the test to implementation detail rather than to what the user perceives.

Likely follow-up

Why does getByRole act as an accessibility signal?

What they are assessing

A conceptual distinction that explains why staleness largely disappears.

Model answer

A Playwright locator is lazy: it describes how to find an element rather than holding a reference to one. The lookup happens at the moment you act or assert, and it re-resolves each time. A Selenium WebElement is a reference to an element found at a point in time, which is why re-rendering produces StaleElementReferenceException. Because locators re-query, that whole class of failure mostly disappears in Playwright, and you can safely declare locators once at the top of a page object or even at module level and reuse them.

Trap to avoid

Describing a locator as just Playwright naming for a WebElement. The laziness is the entire point of the question.

What they are assessing

Whether you have hit strict mode, which is a defining Playwright behaviour.

Model answer

Playwright runs locators in strict mode, so acting on a locator that resolves to more than one element throws an error rather than silently using the first match, which is what Selenium does. That is deliberate: silently picking the first match hides ambiguity and produces tests that pass against the wrong element. The fixes are to make the locator specific, chain it inside a parent scope, or express the intent explicitly with first, last or nth when several matches are genuinely expected. When I hit strict mode violations I treat them as a signal that the locator was ambiguous rather than an inconvenience to suppress.

Likely follow-up

When is using nth acceptable rather than a smell?

What they are assessing

Coverage of two cases that are painful in older tools.

Model answer

For iframes, use frameLocator to scope into the frame and then locate normally, which avoids the switch-in and switch-out dance Selenium requires and removes the classic bug of forgetting to switch back. Shadow DOM is handled transparently: Playwright locators pierce open shadow roots automatically, so getByRole and CSS work through them without special handling. Closed shadow roots remain inaccessible by design, which is a genuine limitation worth stating rather than pretending it works.

What they are assessing

The single most important Playwright concept.

Model answer

Before performing an action, Playwright waits for the element to pass a set of actionability checks: attached to the DOM, visible, stable meaning it has stopped animating, able to receive events meaning it is not covered by another element, and enabled. Only when all of those hold does it act, and if they do not hold within the timeout it fails with a message saying which check did not pass. That is why well-written Playwright tests need almost no explicit waits, and why the framework is less flaky by default than a Selenium suite where the engineer has to remember to wait for each of those conditions themselves.

Likely follow-up

So does that mean you never need an explicit wait?

What they are assessing

Whether you understand the boundaries of auto-waiting rather than treating it as magic.

Model answer

Auto-waiting covers element actionability, not application state. You still wait explicitly when the thing you care about is not an element condition: waiting for a specific network response with waitForResponse, waiting for a URL change, waiting for a piece of application state such as a spinner disappearing before reading a count, or waiting for an event. Web-first assertions cover most of the rest, because expect retries until the condition holds. What you should not need is a fixed sleep, and reaching for waitForTimeout is nearly always a sign that the real condition has not been identified.

Trap to avoid

Claiming auto-waiting removes all waiting concerns. Interviewers ask this precisely to see whether you know where it stops.

What they are assessing

API precision plus judgement about which to reach for.

Model answer

waitForTimeout is a fixed sleep and the documentation itself discourages it in production tests. waitForSelector waits for an element to reach a state such as attached, visible or hidden, though in modern Playwright a locator with a web-first assertion usually expresses the same intent more readably. waitForLoadState waits for a page lifecycle event: load, domcontentloaded, or networkidle. I would add that networkidle is discouraged for most cases because applications with polling or analytics never reach it, so waiting on the actual element or response you care about is more reliable.

What they are assessing

Understanding of the retry model that prevents most race conditions.

Model answer

Web-first assertions such as expect(locator).toBeVisible or toHaveText automatically retry until the condition passes or the timeout expires, rather than evaluating once against a snapshot. That matters because the classic flaky pattern is asserting immediately after an action while the UI is still updating. With a retrying assertion, the test waits for the expected state to arrive, so it is both more reliable and faster than padding with sleeps. The distinction to hold is that assertions on a locator retry, while assertions on a plain value you already extracted do not.

Likely follow-up

Give an example where mixing those two produces a flaky test.

What they are assessing

Whether you understand retrying versus snapshot assertions in practice.

Model answer

The first form resolves the text once, at that instant, and then asserts on a plain string, so there is no retry: if the UI updates a moment later the assertion has already failed. The second passes the locator to expect, so Playwright polls, re-reading the text until it matches or the timeout expires. The second is therefore both more reliable and usually faster, because it proceeds as soon as the condition holds. This is one of the most common mistakes in Playwright suites written by engineers coming from Selenium habits.

What they are assessing

Awareness of a less-known feature and judgement about applying it.

Model answer

expect.soft records a failure and lets the test continue, so a single run can report several problems rather than stopping at the first. It is useful when you are verifying many independent properties of one page, such as a set of labels or a form validation summary, and you want the full picture in one run rather than fixing and re-running repeatedly. It is the wrong choice when a failed check means the rest of the test is meaningless, for example if login failed, because continuing produces a cascade of confusing failures.

What they are assessing

A defining feature of the Playwright runner.

Model answer

Fixtures are declared dependencies that the runner sets up and tears down for a test, requested by naming them in the test signature. Compared with beforeEach hooks they are composable, only run when a test actually requests them, are scoped either per test or per worker, and pass values in cleanly rather than through shared mutable variables. Custom fixtures let you express things like an authenticated page or a seeded account as a dependency, so tests declare what they need rather than inheriting setup from a hook chain that is hard to follow as a file grows.

Likely follow-up

What is the difference between test-scoped and worker-scoped fixtures?

What they are assessing

A very common practical problem with an idiomatic Playwright answer.

Model answer

Authenticate once in a setup project or global setup, then persist the browser storage state, cookies and local storage, to a file with storageState. Subsequent tests load that state when creating their context, so they start already authenticated with no UI login at all. That removes a slow, shared point of failure from every test. For suites with multiple roles you save one state file per role and select the right one per test or per project. The remaining consideration is expiry, so the state needs regenerating when tokens age out, and login itself still needs its own dedicated test.

What they are assessing

Framework design informed by Playwright specifics.

Model answer

Because locators are lazy, you can define them as class fields in the constructor and reuse them safely, which is cleaner than the re-find-every-time discipline Selenium needs. A page object holds the locators and the actions available on that screen, tests hold the assertions. Playwright also encourages a lighter touch than Selenium frameworks historically used: for simple screens a few exported locator helpers are often enough, and heavy inheritance hierarchies are usually over-engineering. Where the pattern really pays is composing workflows, so a test reads as a sequence of business steps and the fixture provides the entry state.

What they are assessing

Config-level knowledge that separates casual from regular users.

Model answer

A project is a named run configuration with its own settings, most commonly one per browser so the same tests execute on Chromium, Firefox and WebKit. Beyond browsers, projects express device emulation, base URLs per environment, and setup dependencies: a common pattern is a setup project that performs authentication and saves storage state, with the main projects declaring a dependency on it so it always runs first. You can also use projects to slice the suite, for example a fast smoke project and a full regression project, and select them by name in CI.

What they are assessing

A capability that is central to Playwright and awkward in Selenium.

Model answer

page.route intercepts matching requests and lets you fulfil them with a stubbed response, abort them, or modify and continue them. That gives you deterministic control over the states that are hard to produce for real: an API returning 500, a slow response, an empty list, or a specific edge-case payload. You can also observe traffic with page.on for request and response events, and wait on a particular call with waitForResponse. Used well this removes a large amount of flakiness caused by depending on live backend data, and lets you test error handling that would otherwise be untestable.

Likely follow-up

What is the risk of mocking too much?

What they are assessing

Judgement about what the test is actually for.

Model answer

Mock when the test is about the UI behaviour rather than the integration: error states, loading states, empty states, and edge-case data that is hard to arrange for real. Mocking makes those deterministic and fast. Do not mock when the test exists to prove the system works end to end, because a suite where everything is stubbed can be entirely green while the real integration is broken. My usual split is a small number of genuine end-to-end journeys against a real backend, and a larger set of UI behaviour tests with the network mocked. The risk to watch is stub drift, where the mock no longer matches the real contract, which contract testing addresses.

What they are assessing

Whether you use the fastest route to set up state.

Model answer

Playwright ships an APIRequestContext, available as the request fixture, that makes HTTP calls directly with the same cookie and auth context as the browser if you want. I use it to create the state a UI test needs, such as seeding an order or a user, rather than clicking through several screens to reach the starting point. That cuts runtime and removes unrelated failure points, so a failing test actually indicates a problem in the area under test. It also lets you assert on the backend after a UI action, confirming the side effect persisted rather than trusting the interface.

What they are assessing

Whether you have debugged a CI failure with the tooling rather than by guessing.

Model answer

A trace is a recording of the run containing a DOM snapshot before and after every action, the action log with timings, network requests, console output, and optionally screenshots and video. The trace viewer replays it so you can step through the test and inspect the actual DOM at the moment of failure. Its real value is CI failures: instead of re-running with more logging and hoping to reproduce, you download the trace artefact and see exactly what the page looked like. Configuring trace on-first-retry is the usual setting, so you get the evidence without the storage cost of tracing every passing run.

Likely follow-up

What trace setting would you use in CI and why?

What they are assessing

Familiarity with the day-to-day workflow.

Model answer

The inspector, opened with PWDEBUG or the debug flag, pauses execution and lets you step through actions while highlighting locators and suggesting alternatives. Codegen records interactions and generates a starting script, which is useful for discovering locators rather than as a source of final tests. UI mode gives a watch-mode interface with time travel across the run. page.pause drops into the inspector at a chosen point. And the trace viewer covers after-the-fact analysis. The workflow I use is codegen or UI mode to explore, then hand-write the test properly, with traces for anything that fails in CI.

Trap to avoid

Presenting codegen output as production-ready tests. Generated locators and flat scripts are a starting point, not a suite.

What they are assessing

Systematic debugging on the most common real frustration.

Model answer

Start with the trace from the failing CI run, which usually answers it immediately by showing the DOM state at failure. Then work through the environmental differences: headless versus headed rendering, viewport size, machine speed and contention affecting timing, timezone and locale, missing fonts changing layout and therefore element positions, environment data differing, and animations behaving differently. Reproducing locally in headless at the same viewport catches a large share. If it is genuinely timing, the fix is nearly always to wait on the correct condition rather than to raise the global timeout, which only hides it.

What they are assessing

Understanding of the worker model, which shapes how tests must be written.

Model answer

Playwright runs tests in parallel across worker processes, with each worker running its own browser and each test getting a fresh context, so isolation is the default. By default files run in parallel while tests within a file run in order, and you can opt into full parallelism within a file. Worker count is configurable and typically reduced on CI. The implications for test design are the important part: tests must not depend on execution order or share mutable data, and anything unique-constrained such as an email needs generating per test, or workers will collide.

Likely follow-up

How would you handle a test that genuinely cannot run in parallel?

What they are assessing

Whether you treat retries as diagnostics rather than a cure.

Model answer

Retries are set in the config, commonly zero locally and one or two on CI, and Playwright reports a test that passed on retry as flaky rather than silently green, which is the important detail. That visibility is what makes retries acceptable: you get resilience against genuine infrastructure blips without losing the signal. The risk is treating the flaky count as noise and letting it grow, because a suite that only passes on retry has stopped being a quality signal and may be masking a real intermittent product bug. I pair retries with trace on-first-retry so every flaky run leaves evidence to diagnose.

What they are assessing

Practical delivery experience.

Model answer

Use the official Playwright container or run the install step with dependencies so browsers and system libraries are present. Set workers appropriately for the runner, since over-parallelising on a small agent causes timing flakiness. Enable trace on-first-retry, screenshots on failure and video on retry, and publish them as artefacts along with the HTML report. Shard across multiple machines for large suites using the shard option. Tier the run so a fast smoke project gates pull requests and the full suite runs on merge or schedule. And pass the base URL and secrets through environment variables rather than committing them.

What they are assessing

Awareness of how to scale beyond a single machine.

Model answer

Sharding splits the test suite across multiple machines, each running a slice with the shard option, and the reports are merged afterwards. Workers give you parallelism within one machine; sharding gives you parallelism across several. You need it when the suite has grown beyond what a single runner can complete inside your acceptable feedback window even at full worker count. Before reaching for it I would check that the suite is not slow for avoidable reasons, such as UI logins on every test or coverage that belongs at the API layer, because adding machines to an inefficient suite is paying to hide the problem.

What they are assessing

Whether you can weigh migration cost honestly rather than chasing the newer tool.

Model answer

Not as a big-bang rewrite, because that stops delivery and usually recreates the same problems in new syntax. The cases where migration is justified are a suite that is slow and flaky largely due to synchronisation, a team already in the JavaScript or TypeScript ecosystem, or a need for capabilities like network interception and tracing that are painful in Selenium. Where migration is not justified is a stable suite in a language with strong Selenium investment and a team that knows it well. My usual approach is to write new tests in Playwright while leaving the existing suite in place, and migrate high-value flaky tests opportunistically.

Likely follow-up

How would you run both suites side by side without confusing the team?

What they are assessing

Honesty about your preferred tool, which builds credibility.

Model answer

It automates browsers only, so native mobile testing needs Appium, and mobile support in Playwright is viewport and user-agent emulation rather than real devices. The ecosystem is younger than Selenium, so there are fewer third-party integrations and less legacy community material, though it is growing quickly. Language support is real but the Node experience is the most complete. Browser binaries are pinned per version, which is a strength for stability but means larger downloads and deliberate upgrades. And, like any UI automation, it cannot judge whether something looks right or is usable without adding visual tooling.

What they are assessing

Balanced comparison of the two modern options.

Model answer

Cypress runs inside the browser, which gives an excellent interactive debugging experience but imposes architectural constraints: multi-tab and multi-origin work is limited, and it is JavaScript-centric. Playwright runs out of process, so multiple tabs, contexts, origins and true parallelism are straightforward, it supports WebKit for Safari coverage, and it offers multiple languages. Cypress has a long-established community and a very polished local experience. For a new project needing cross-browser coverage including Safari, real parallelism, or non-JavaScript bindings, I would choose Playwright; for a JavaScript team prioritising developer experience on a simpler app, Cypress remains reasonable.

What they are assessing

Sequencing and adoption thinking rather than tooling knowledge.

Model answer

Start narrow and prove value fast. Pick the two or three highest-value journeys, usually revenue paths, and automate those first so there is a visible smoke suite within a couple of weeks. Wire it into CI immediately, because tests nobody runs decay. Set the conventions early while the suite is small: locator strategy favouring roles and test ids, storage-state auth, no fixed sleeps, and a review standard. Ask developers for test attributes as a small concrete contribution. Then grow coverage by risk rather than by chasing a coverage percentage, and push anything that does not need a browser down to the API layer.

Likely follow-up

What would you deliberately not automate in the first month?

What they are assessing

Awareness of built-in capability plus its practical pitfalls.

Model answer

Playwright has built-in screenshot comparison through toHaveScreenshot, which stores a baseline and fails on pixel differences beyond a configurable threshold. The pitfalls matter more than the API: rendering differs across operating systems and browsers, so baselines must be generated on the same platform as CI, usually via a container. Dynamic content such as dates, avatars and animations produces false positives, so you mask those regions or freeze them. I would also scope visual checks to a few stable, high-value screens rather than everything, because a visual suite that cries wolf gets ignored within a sprint.

What they are assessing

Long-term suite ownership.

Model answer

Keep the browser out of anything that does not need it, pushing business-logic coverage to the API layer. Use storage-state authentication rather than UI logins. Set up state through API calls instead of clicking through screens. Mock the network for tests about UI behaviour so they do not wait on real backends. Tune workers and shard when genuinely needed. Then maintain it: track duration per test, prune tests that duplicate lower-layer coverage, and treat the flaky count as a standing metric rather than something you look at when the suite becomes unbearable.