Playwright interview questions — UI automation fundamentals
Reviewed by Mark Dickie · Last updated
5 questions on this page you can answer and see marked on the spot. Go to the first one
Playwright is an open-source Node.js (and Python/.NET/Java) library for automating Chromium, Firefox, and WebKit browsers through a single API. For interview prep on the fundamentals, you need a firm grasp of locators and the locator engine, the auto-waiting model, browser contexts versus pages, and the built-in test runner with fixtures. Expect questions on how Playwright resolves elements, how it retries actionability checks before failing, and how you isolate tests with parallel worker processes.
What does a Playwright fundamentals interview test?
Interviewers probe whether you understand the mechanics behind a passing test, not just whether you can record one with the codegen tool. The core areas break down as follows:
| Concept | What to know |
|---|---|
| Locators | getByRole, getByText, getByTestId, and CSS chains; why role-based locators are preferred for resilience |
| Auto-waiting | Playwright waits for visibility, stability, enabled state, and receives events before performing each action |
| Browser contexts | Isolated cookie and storage per context; cheap to create; the unit of test isolation |
| Fixtures | The @playwright/test fixture system injects page, browser, and custom fixtures per test without global state |
| Assertions | Web-first assertions like expect(locator).toBeVisible() poll the DOM and retry until timeout |
How do locators and auto-waiting work together?
A locator is a description of how to find an element, not a handle to the element itself. When you call await locator.click(), Playwright re-resolves the DOM, then runs actionability checks: the element must be attached, visible, stable (not animating), receive pointer events, and be enabled. If any check fails, Playwright retries until the default 30-second timeout. You configure that timeout with test.setTimeout or per-action options. Knowing this retry loop is what separates someone who has used Playwright from someone who understands it.
- Choose role-based locators (
getByRole) first, then text or test-id fallbacks. - Let auto-waiting handle timing instead of hard-coded
page.waitForTimeoutcalls. - Use
expectweb-first assertions so the test polls the DOM instead of snapshot-checking once. - Isolate state with fresh browser contexts rather than clearing cookies by hand.
- Keep tests independent by relying on the fixture system to provide a clean
pageper test.
What should I review before a Playwright round?
Go over the async API surface: every Playwright call returns a Promise, and forgetting await is the single most common bug in written exercises. Review how test.beforeEach differs from fixture setup, how test.describe groups tests, and how test.use({ ... }) scopes configuration to a describe block. Brush up on network mocking with page.route, handling multiple tabs via context.waitForEvent('page'), and reading the trace viewer to diagnose a flaky failure. Finally, be ready to convert a manual test case into a Playwright test on a whiteboard, choosing locators that survive minor UI changes.
Key facts
- Tarmac has 11 Test Automation interview questions on this topic, 10 of them on this page, at difficulty 1–5 of 5.
- Tarmac tracked 782 job postings asking for Test Automation in September 2026.
- Roles asking for Test Automation advertise a median base salary of £75,000, across 183 job postings as of September 2026.
- Tarmac last reviewed these Test Automation interview questions on 14 September 2026.
At a glance
| Questions | 10 shown · 11 in the bank |
|---|---|
| Difficulty | 1–5 of 5 |
| Formats | Multiple choice, Short answer, Multiple answer, Fill in the blank, True / false, Flashcard |
What you'll review
- playwright fundamentals
Practice questions
Try one before you open the answer. Pick an option and press Check; it's marked on the spot.
In Playwright (current versions), which locator best finds a Save button by its ARIA role and accessible name, so the test doesn't depend on CSS class names or DOM position?#
Options
Show answer
page.getByRole('button', { name: 'Save' }) is the Playwright locator that finds an element by its ARIA role and accessible name. Because it matches what users and assistive technology see, it stays stable when CSS classes or DOM structure change.
page.getByRole('button', { name: 'Save' }) is a role-based locator: it matches elements by their ARIA role and accessible name, which is what a user or assistive technology perceives. The other options all rely on CSS class names, structural position (nth-child or an XPath index), or both, so they break when markup or styling changes without any change to the button's behaviour.
In Playwright Test, what does await expect(page.getByText('Welcome')).toBeVisible(); do when the text is not yet visible at the time of the call?#
Options
Show answer
expect(...).toBeVisible() retries until the element becomes visible or the expect timeout runs out, which is 5 seconds by default. Playwright's web-first assertions poll the page, so a test does not fail just because the element appears a moment later.
Playwright's web-first assertions such as toBeVisible() automatically retry until the condition becomes true or the expect timeout (5 seconds by default) is reached. The assertion fails only if the element never becomes visible within that window. A fixed sleep is not used, and the assertion is not skipped, so the other options describe behaviour Playwright does not have.
Put these six steps of a minimal Playwright script that uses the library API directly (not the test runner) into the order they must run, first to last. (Playwright is a browser automation library; the library API refers to calling chromium.launch(), browser.newContext(), etc. directly rather than using the @playwright/test runner and expect.) These six steps are: Launch the browser with chromium.launch(); Create a new browser context with browser.newContext(); Open a new page with context.newPage(); Navigate to the URL with page.goto(url); Read the heading's text with page.getByRole('heading').textContent(); Close the browser with browser.close(). Write the six steps in order, first to last, using their API call names separated by arrows.#
Show answer
chromium.launch() → browser.newContext() → context.newPage() → page.goto(url) → page.getByRole('heading').textContent() → browser.close() — Each step produces the object the next step needs: the browser is needed to create a context, the context to open a page, the page to navigate, navigation to load the heading content, and the browser must stay open until the read is complete.
Each step depends on the object created by the step before it. The browser must be launched before a context can be created from it; a context must exist before a page can be opened in it; the page must navigate to a URL before reading the heading's text content can return the loaded value; and the browser must not be closed until after the heading text is read, because closing the browser destroys the page. These six steps form a strict dependency chain — every step requires the object produced by the previous step — so there is exactly one valid order: launch the browser, create a context, open a page, navigate to the URL, read the heading text, then close the browser.
Which of the following statements about Playwright's auto-waiting and locators are true? Select all that apply.#
Options
Pick every one that applies.
Show answer
Correct: Playwright actions auto-wait for actionability checks, web-first assertions retry until they pass or time out, and locators are lazy. Locators re-resolve against the DOM each time they are used, so they do not bind to a node at creation. This is why explicit sleeps are rarely needed in Playwright tests.
Playwright actions run actionability checks (visible, stable, enabled, receives events) before acting, so explicit sleeps are unnecessary for that. Web-first assertions poll until they pass or time out. Locators are lazy descriptions that are re-resolved each time they are used. The statement about page.locator returning a bound ElementHandle describes the older handle-based API; locators do not pin a DOM node at creation time, so that option is false.
In Playwright, page.getByRole('button', { name: 'Save' }) returns a _____. Unlike an ElementHandle, it is not resolved when created; Playwright re-resolves it against the current DOM each time an action such as click() runs.#
Show answer
In Playwright, page.getByRole('button', { name: 'Save' }) returns a locator. Unlike an ElementHandle, it is not resolved when created; Playwright re-resolves it against the current DOM each time an action such as click() runs.
Playwright's page.getByRole() (like page.locator()) returns a Locator object. A Locator is a lazy description of how to find an element, so it is re-evaluated against the live DOM on every action, which is what makes auto-waiting and retries work. An ElementHandle, by contrast, points to a specific DOM node captured at one moment and can go stale. The blank therefore takes the answer 'locator'.
By default, Playwright runs browsers in headless mode. To watch the browser window open while the tests run, pass the _____ flag to the npx playwright test command.#
Show answer
By default, Playwright runs browsers in headless mode. To watch the browser window open while the tests run, pass the --headed flag to the npx playwright test command.
The Playwright test CLI runs browsers headless by default. Passing the --headed flag to npx playwright test launches the browser with a visible window so you can observe the test steps. The blank takes the answer '--headed', the documented CLI flag for this purpose.
In Playwright (current 1.x releases), when a test calls page.locator('#save').click(), the click action automatically waits for the matched element to be visible, stable, enabled, and receiving pointer events before it performs the click, so an explicit fixed sleep is not needed for that purpose. True or false?#
Options
Show answer
True. In Playwright, locator actions such as click() perform auto-waiting: they wait until the element is visible, stable, enabled, and able to receive events before acting. This built-in actionability checking is why fixed sleeps are generally unnecessary for element interactions.
Playwright's locator actions (click, fill, check, and others) run actionability checks before acting. The element must be attached to the DOM, visible, stable (not animating), enabled, and not obscured by another element, and Playwright retries these checks until the action's timeout expires. Because this waiting is built into the action, hard-coded sleeps are unnecessary for this case, making the statement true.
In Playwright, if a locator such as page.locator('button.primary') matches two or more elements on the page and you call .click() on it without narrowing the selector, Playwright automatically clicks the first matching element in document order. True or false?#
Options
Show answer
False. Playwright locators use strict mode by default, so calling click() on a locator that matches several elements throws a strict mode violation rather than clicking the first match. To target one element, narrow the locator with first(), nth(), filter(), or a more specific selector.
Playwright locators are strict by default. When an action such as click() is performed on a locator that resolves to more than one element, Playwright throws a strict mode violation error instead of choosing one. The developer must disambiguate with first(), nth(), filter(), or a more specific selector. Therefore the statement that it silently clicks the first match is false.
In Playwright (current 1.x, Node or Python), what checks does an action such as locator.click() perform automatically before it fires, and why does this make an explicit sleep before the click unnecessary?#
Show answer
Before performing the action, Playwright waits for the element located by the locator to pass its actionability checks: it must be attached to the DOM, visible, stable (not animating or moving across consecutive animation frames), enabled, and receive pointer events at the click point (not be obscured by another element). Playwright re-resolves the locator on each attempt and retries until these pass or the action timeout elapses, so the wait is driven by the actual element state rather than a fixed delay. Assertions like expect(locator).toBeVisible() use the same retry-until-timeout model.
Playwright's auto-waiting is built into actions: each action runs actionability checks (attached, visible, stable, enabled, receives events) and retries the locator resolution until they pass or the timeout is hit. This replaces fixed sleeps, which are either too short (flaky) or too long (slow). Web-first assertions share the same polling behavior, which is why waiting on a condition with an assertion is preferred over waiting on a fixed time.
In Playwright, what is a BrowserContext, and what isolation does the Playwright Test runner give each test by default?#
Show answer
A BrowserContext is an isolated, incognito-like session inside a single running browser instance, with its own cookies, localStorage, sessionStorage, and cache, and it is cheap to create compared with launching a new browser. By default, the Playwright Test runner gives each test its own fresh BrowserContext (and fresh Page), so state from one test does not leak into another, while the browser process itself is shared across tests in a worker.
Isolation in Playwright is scoped to the BrowserContext, not the browser process. Creating a new context per test gives clean storage and cookies without the cost of relaunching the browser. The runner's default of a fresh context per test is what makes tests independent; reusing authenticated state is done deliberately through storageState rather than by sharing a context.
Related interview questions
Job market
See test-automation salaries and hiring demand from live job postings.
The other 1 question
This page shows 10 and marks what you pick. That's as far as a page can go. A free account opens the other 1 and keeps every answer. What you miss comes back until it's right: after a day, then at longer gaps.
Free · the whole bank · 100 marked answers per 30 days · written feedback on the paid plan