Playwright Testing Interview Questions for 7 Years Experience
40 questions with answers for candidates with 7 years of experience — 1 easy, 15 medium, 24 hard.
What interviewers expect: 7 years experience
At seven years interviewers look for a quality leader who can set direction across teams. Expect questions on scaling suites to thousands of tests, measuring flakiness and coverage, choosing tools, upgrade strategy and shifting testing left with developers. You should describe measurable outcomes you delivered, such as cutting pipeline time or escaped defects.
This set is weighted towards Framework Design and CI/CD (8), Network Mocking (6), API Testing (5), Parallel Runs, Sharding & Reporting (4).
Scaling large suites Quality metrics Tooling decisions Cross-team influence
Solved at this levelStart practicing
3 QUESTIONS FREESign up to unlock the full question bank and track your progress.Unlock every question and answer, then continue practising company-wise and package-wise.
✓ 3 questions free • Unlock the rest in seconds
01
How does expect.poll work and when would you use it?
expect.poll calls a function again and again until the value it returns passes the matcher or the timeout runs out. It is useful for values that are not locators, such as an API status or a database count. Example: await expect.poll(async () => (await request.get('/api/job/7')).status()).toBe(200). You can tune the intervals and the timeout.
02
Why should the Playwright Docker image version match your package version?
Each Playwright version expects specific browser builds. The official Playwright Docker image tagged v1.x.y-noble contains the browsers for that exact version. If package.json has a different version, tests fail because browsers are missing or mismatched. Pin both together and update them in the same pull request.
03
How do you test how the UI handles a 500 error from the orders API?
Mock the endpoint with route.fulfill({ status: 500, json: { message: 'Server error' } }), then open the page. Assert the user sees a friendly error message and a retry button, and that no broken half-rendered table appears. Then make the retry return 200 and check the data loads. This covers a path that is hard to trigger on a real server.
04
How can you run only the tests affected by a code change?
Use npx playwright test --only-changed=origin/main. It looks at files changed against that git reference and runs the test files that changed or that import changed files. It suits fast pull request feedback in a large suite. It cannot see backend or config changes that tests do not import, so still run the full suite before release.
05
How would you structure a large Playwright framework for a team?
Separate tests, page objects, fixtures, utilities, test data and config; use tags, projects, shared auth setup, linting, code review and a CI pipeline with sharding and reports.
06
How do you run tests against a preview deployment created for each pull request?
Make baseURL come from an environment variable, such as process.env.BASE_URL, with a default for local runs. In the pipeline, wait for the preview deployment to be ready, read its URL from the deployment step and pass it to the test job. Add a quick health check request first, so a failed deployment is reported clearly instead of as hundreds of test failures.
07
Tests pass with one worker but fail with eight. How do you debug this?
This usually means tests share something: the same user account, the same records or a global server setting. Run the failing file with --workers=8 and --repeat-each to reproduce it. Look at which tests run at the same time in the report. Fix it by giving each test unique data, using workerIndex in names, or isolating shared settings per worker.
08
An axe scan reports 40 violations on a legacy page. How do you add accessibility checks without blocking every build?
Record the current violations as a known baseline, for example by snapshotting violation ids and targets, and fail only on new ones. Fix the worst issues first, such as missing labels and contrast on key flows, and shrink the baseline every sprint. Make new pages and components meet zero violations from day one. Report the trend to the team so the debt is visible rather than silently ignored.
09
One shard finishes in 4 minutes and another takes 15. How do you balance them?
Check whether fullyParallel is off, because file-level sharding puts big files together. Turn it on if tests are independent, or split the largest files. Use reportSlowTests and the merged report's durations to find heavy files, and move slow setup into API calls or shared storage state. Also check that one shard is not getting all the tests of a slow project such as WebKit.
10
Ten engineers write tests and quality varies a lot. How do you keep the framework consistent?
Write a short contribution guide with examples. Add ESLint with the Playwright plugin and the no-floating-promises rule, plus Prettier, enforced in CI. Require reviews from framework owners for shared fixtures and page objects. Provide generators or templates for new page objects, and run regular sessions to review flaky tests together.
The request fixture returns the full body only after the stream ends, so for a short finite stream you can read text() and parse each data line. For long-lived streams, test in the browser: open the page that uses EventSource, or open it inside page.evaluate, collect events into an array and assert with expect.poll. Mock the source with a route when you need precise timing.
--repeat-each=N runs every selected test N times in the same run, spread across workers. It is useful for checking a new or fixed test for flakiness before merging, for example npx playwright test checkout.spec.ts --repeat-each=20. Combined with several workers it also surfaces tests that collide with each other over shared data.
15
How do you test an async job API that returns 202 and finishes later?
Start the job and assert the 202 status and the returned job id. Then poll the status endpoint with expect.poll, with sensible intervals and a timeout, until it reports completed. Finally fetch the result and validate it. Also test the failure path, for example invalid input leading to a failed status with a clear error message.
16
A beforeAll creates one user and tests in the same file fail randomly in parallel mode. Why?
With fullyParallel, the file's tests run in different workers, so each worker creates its own user, or tests in one worker share one user and change its state. Shared mutable data causes random failures. Give each test its own data through a test-scoped fixture, or create a unique user per worker with workerInfo.workerIndex in the name.
17
How would you design a visual testing strategy for a large web application?
Snapshot stable, high-value screens and shared components, not every page. Render baselines only in a pinned Docker image, mask or mock dynamic data, and disable animations. Keep visual tests in their own project or tag so they can run on pull requests touching UI code. Define owners for baseline reviews and keep thresholds strict in config. Combine with functional assertions, because pictures alone do not tell you why something broke.
Turn on trace: 'on-first-retry', open the trace viewer, check network and timing, replace hard waits with web-first assertions, isolate test data and check for sharding conflicts.
19
How do project dependencies differ from globalSetup?
A setup project is a normal test file that other projects list in dependencies. It shows in the HTML report, can use fixtures, and records traces, so failures are easy to debug. globalSetup is a plain function that runs before everything without fixtures or traces. The docs now recommend project dependencies for login and data seeding.
20
A feature is controlled by a flag served from a config API. How do you test both states?
Mock the config endpoint in a fixture option so each test chooses the flag value, for example featureFlags: { newCheckout: true }. Run the flow with the flag on and off and assert the different UI. Mocking avoids changing shared environment settings that would affect other testers. Also keep one test against the real config to catch wiring mistakes.
21
What is the difference between unknown and any in TypeScript?
any switches off type checking, so any property access compiles even if it crashes at runtime. unknown accepts any value but forces you to narrow or validate it before use. For API JSON in tests, typing it as unknown and then validating or asserting a type is safer than any, because mistakes appear at compile time.
Use page.routeWebSocket with a URL pattern. The handler gets a WebSocketRoute: you can reply to messages with ws.onMessage and ws.send without any server, or call connectToServer() to sit in the middle and change messages in both directions. This lets you test live dashboards and chat apps, for example pushing a fake price update.
23
How do contract tests differ from functional API tests?
Functional tests check behaviour: given this input, the API returns the right data and status. Contract tests check that the shape agreed between consumer and provider, such as field names and types, has not changed. Playwright suits functional tests and simple schema checks. Dedicated contract tools help when many services evolve independently and need consumer-driven agreements.
24
Two test files edit the same global settings page and break each other when run in parallel. How do you handle it?
The best fix is to remove the shared resource, for example by giving each test its own tenant or user whose settings it can change. If that is impossible, put those tests in one file with test.describe.configure({ mode: 'serial' }), or in a separate project that runs with one worker after the main project. Document why, so the exception does not quietly spread.
25
How do test.slow() and longer timeouts help or hurt debugging?
test.slow() triples the timeout for a test that is genuinely long, such as a report export. It is honest and visible in code. But raising timeouts to make a flaky test pass hides the real cause, such as a missing wait or slow backend, and makes failures take longer. Investigate the trace first and change timeouts only with a reason.
26
How do you decide how many shards a suite should use?
Start from the target wall-clock time and the total test time per machine. If one machine with its workers takes 40 minutes and the goal is under 10, you need about four or five shards, plus some margin for setup like installing browsers. Past a point each shard spends more time on setup than on tests, and the app or test data may become the bottleneck, so measure each change.
readonly and as const stop test data from being changed by accident, for example one test editing a shared user object and breaking the next. as const also keeps literal types, so ['admin', 'viewer'] as const gives the type 'admin' | 'viewer'. That lets TypeScript reject invalid roles at compile time instead of during a run.
28
How do you upgrade Playwright safely in a large suite?
Read the release notes for breaking changes and deprecations. Upgrade on a branch, update the browsers and the Docker image to the same version, and run the full suite on all projects several times. Compare visual snapshots, which often change after browser updates. Upgrade regularly in small steps rather than skipping many versions.
29
The team wants to replace all end-to-end tests with component tests to save time. What do you advise?
Agree to move detailed UI checks down to component tests, because they are faster and more precise. But keep a thin layer of end-to-end tests for critical journeys like signup, checkout and payment, since component tests use mocked data and cannot catch broken APIs, routing or deployment issues. Decide per risk, measure runtime savings, and track escaped defects after the change.
30
The app polls a status endpoint every few seconds. How do you test the change from Pending to Done?
Mock the endpoint with a counter: return Pending for the first two calls and Done after that. Then assert the UI shows Pending and later Done using web-first assertions with a suitable timeout. You can also use page.clock to speed up the polling interval instead of waiting real seconds. This makes a slow real-world process quick and deterministic.
In a fixture or beforeEach, call the API (request.post) to create the user or order, use it in the UI test, then delete it in teardown. It is faster and more reliable than creating data through the UI.
34
How do you test a flow that needs two user roles, such as an admin and a customer, in one test?
Create two browser contexts in the same test, each with its own storageState file, for example admin.json and user.json made by a setup project. Wrap them in fixtures like adminPage and userPage so tests stay short. The admin approves an order in one context and the customer sees the update in the other, with fully separate cookies.
35
A fixture mocks every /api call, but one test needs a different response for /api/cart. How do you override it?
Register a new page.route for /api/cart inside that test. Handlers run in reverse order of registration, so the newer one runs first. Fulfil the cart request with the special data, and for anything else call route.fallback() so the request moves on to the fixture's general handler. This keeps the shared mock untouched and makes the override local and easy to read.
36
How do access modifiers help in page object classes?
private and protected hide internal locators and helper steps, so tests can only call meaningful public methods such as login or addToCart. This keeps tests readable and lets you change internals without breaking callers. readonly on the page field prevents it from being replaced. TypeScript enforces these at compile time only, not at runtime.
37
How do you assert an element's CSS class, attribute or value?
Measure first with the report timings. Then create data through the API instead of the UI, move read-only shared data into a worker-scoped fixture, and seed common reference data once in a setup project. Keep per-test data only for things a test changes. Cache login with storageState. This usually cuts setup time sharply without losing isolation.
Frequently asked questions
What is asked in Playwright Testing interviews for 7 years of experience?
At seven years interviewers look for a quality leader who can set direction across teams. Expect questions on scaling suites to thousands of tests, measuring flakiness and coverage, choosing tools, upgrade strategy and shifting testing left with developers. You should describe measurable outcomes you delivered, such as cutting pipeline time or escaped defects.
How many questions should I practise before a Playwright Testing interview?
Work through all 40 questions here, then the company-wise sets for the employers you are targeting. Quality matters more than count: be able to explain why each answer is right.
Which topics matter most for 7 years of experience?
Focus first on Scaling large suites, Quality metrics, Tooling decisions, Cross-team influence.