Top 10 Playwright Interview Questions (With Answers)

Introduction

If you only have an evening before your interview, revise these ten. They come up in almost every Playwright screening round because they cover the full arc of the conversation: what the tool is, how it waits, how you locate elements, how you structure a framework, how you keep it stable, and how you run it in CI.

The Top 10 Questions

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

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

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

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

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

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

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

How to Answer Them Well

• Answer in two layers: one sentence of definition, then one sentence of trade-off or experience.
• Keep each answer under sixty seconds; let the interviewer ask for depth.
• Attach a number wherever possible — suite runtime, flake rate, worker count.
• If you do not know something, say so and describe how you would find out. Bluffing is a fast rejection.

Summary

These ten questions map to the ten things a hiring manager needs to believe about you: you understand the tool, you understand asynchronous UIs, you write maintainable locators, you can architect a framework, you can stabilise it, and you can ship it to CI. Rehearse them aloud until each one takes under a minute.