A Browser is a launched browser instance. A BrowserContext is an isolated, incognito-like session with its own cookies, storage and cache, and is cheap to create. A Page is a tab in a context. Playwright Test gives each test a fresh context, and extra contexts enable multi-user tests.
Full answer with examplesInterview questions / UI Automation
Playwright Interview Questions
Playwright interviews centre on locators, auto-waiting, web-first assertions, fixtures and parallelism. These questions mirror what senior SDETs are asked in 2026.
9 questions · 2 beginner· 5 intermediate· 2 advanced
beginner questions
Prefer user-facing locators: getByRole with an accessible name first, then getByLabel, getByPlaceholder or getByText, and getByTestId for elements with no stable accessible identity. Avoid CSS or XPath tied to DOM structure. Locators are lazy, strict, and re-resolved on every action, which makes them resilient.
Full answer with examplesintermediate questions
Web-first assertions such as expect(locator).toHaveText() take a locator and retry until the condition is met or the expect timeout (5 seconds by default) expires. Reading a value first with await locator.textContent() takes one snapshot and asserts immediately, so it fails on content that is still loading.
Full answer with examplesHow does Playwright auto-waiting work, and when is it not enough?
intermediate 2–5 yrs
Before acting, Playwright waits for actionability checks (attached, visible, stable, receives events, enabled, editable as relevant). Web-first assertions retry until timeout. It is not enough for app-level state like background jobs or data that changes without a DOM signal.
Full answer with examplesHow do Playwright fixtures work? Build a custom fixture with test.extend.
intermediate 2–5 yrs
Fixtures are on-demand setup and teardown units injected by name into tests. Create them with test.extend: code before await use(value) is setup, after it is teardown. They can be test- or worker-scoped, depend on other fixtures, run automatically with auto: true, and replace beforeEach hooks and base classes.
Full answer with examplesHow do you avoid logging in through the UI in every Playwright test?
intermediate 2–5 yrs
Log in once in a setup project, save cookies and local storage with storageState to a file, and have test projects depend on that setup and load the file via use.storageState. Prefer API login for speed, use one account per worker if tests mutate server-side state, and keep auth files out of git.
Full answer with examplesHow do you mock or modify network responses in Playwright, and when should you?
intermediate 2–5 yrs
Use page.route or context.route with a URL pattern, then route.fulfill to return a mock, route.continue to modify the request, or route.fetch to patch the real response. Mock error states, edge cases and unstable third parties, but keep some unmocked end-to-end tests to catch contract drift.
Full answer with examplesadvanced questions
Playwright runs test files in parallel worker processes; fullyParallel also splits tests within a file. Each worker has its own browser and each test a fresh context. Scale out with --shard=x/n in a CI matrix, the blob reporter and merge-reports. Tests must be independent with isolated data.
Full answer with examplesCollect evidence first: traces on retry, screenshots, video. Reproduce with --repeat-each and different worker counts. Classify the cause (timing, data, isolation, environment, real product race) and fix it with web-first assertions, isolated data and explicit signals. Track and quarantine; never just add retries.
Full answer with examplesHow Playwright interviews are structured
For junior and mid-level roles, expect concept questions first: how auto-waiting works, why getByRole is preferred, the difference between a Browser, a BrowserContext and a Page. Senior interviews move quickly to design and debugging: how you would share authentication across hundreds of tests, how you would shard a suite across CI machines, and what you would do with a test that fails one run in twenty. Many loops also include a live exercise where you write a short spec or fix a broken one.
What interviewers listen for
- Precise vocabulary. "Auto-waiting" covers actionability checks before actions (attached, visible, stable, enabled, receives events); retrying assertions are a separate mechanism. Candidates who blur the two struggle to explain flaky tests.
- Isolation. Each test gets a fresh browser context, so cookies and storage do not leak. Strong answers explain how storage state keeps that isolation while skipping the UI login.
- Restraint with mocking. Network mocking with
page.routeis valuable for error states and slow responses, but a suite that mocks everything no longer tests the integration. - A debugging method, not a guess. For a test that fails only in CI, describe reproducing with retries and traces, reading the trace viewer, and fixing the race rather than adding
waitForTimeout.
A worked example: the one-line anti-pattern
A favourite question shows expect(await page.locator('#status').textContent()).toBe('Paid') and asks what is wrong. The await reads the text once, immediately; if the status updates a moment later, the assertion fails. The web-first version, await expect(page.locator('#status')).toHaveText('Paid'), retries until the text matches or the assertion timeout expires. A complete answer adds that a role-based locator such as page.getByRole('status') would also be more robust than an id, and that the same reasoning applies to isVisible() checks. The full model answer is in web-first assertions.
Fixtures, parallelism and scale
Senior Playwright interviews often turn to suite architecture. Fixtures are Playwright's dependency-injection mechanism: test.extend defines a value such as a logged-in page or an API client, sets it up before the test that asks for it, and tears it down afterwards, so setup lives in one place instead of beforeEach blocks copied across files. Worker-scoped fixtures run once per worker process, which suits expensive setup such as seeding a database.
For parallelism and sharding, explain the two levels: workers run test files in parallel on one machine, and --shard=1/4 splits the suite across CI machines, with the blob reporter and merge-reports combining the results. Parallel runs only work if tests do not share data, so a good answer mentions unique test data per worker.
How to practise
Read each question and answer it aloud before revealing the model answer, then practise the skill in the Playwright practice lab: locator challenges show exactly what your locator matches, and test challenges run your spec against a demo app with planted bugs that your assertions must catch. When the concepts feel solid, take a timed mock interview with the Playwright stack selected.