tldr: Hiring for Playwright in 2026 means screening for a specific blend of test-engineering judgment, modern web fluency, and CI/CD pragmatism. The strongest candidates can explain why Playwright works the way it does, not just demonstrate the syntax. This is the question bank we use internally, grouped from basics to senior, with the answers we look for.
A Playwright interview should screen for two things. Whether the candidate can write tests that age well. Whether the candidate understands the architecture well enough to debug a flake at 6pm on a Friday.
Most question banks online test the first thing badly and the second thing not at all. They lean on syntax recall and miss the judgment that actually matters in production. The questions below are the ones that separate strong candidates from people who have memorised a tutorial.
We have grouped them from basic (every candidate should answer) to advanced (mid to senior). The answers are short on purpose. Real answers in a real interview should be twice this long.
Basic questions
1. What is Playwright?
Playwright is Microsoft's open-source browser automation framework. It drives Chromium, WebKit, and Firefox through the Chrome DevTools Protocol from an out-of-process Node, Python, Java, or .NET runtime. Strong candidates will also mention auto-waiting, the locator model, or the integrated test runner as differentiators.
2. What is a locator in Playwright?
A description of how to find an element, evaluated fresh every time you act on it. Unlike older selector models that returned stale references, locators survive DOM re-renders. Look for candidates who explain why this matters for modern frontends (React, Vue, Svelte re-render constantly), not just what it is.
3. What is auto-waiting?
Every action on a locator waits for actionability conditions (attached, visible, stable, enabled) before firing. Most manual waits are unnecessary in Playwright. Candidates who still reach for waitForTimeout for everything are a yellow flag.
4. How do you assert something in Playwright?
Web-first assertions: await expect(locator).toBeVisible(), toHaveText(), toHaveURL(). They retry until the assertion passes or the timeout expires. Candidates should know that expect from Playwright is different from expect in Jest or other test runners and that the retry behaviour is the point.
5. What is the difference between page.goto() and page.waitForURL()?
goto navigates and waits for the load event. waitForURL waits for the URL to match without initiating navigation. Candidates often confuse these. Asking when to use each one separates people who have read the docs from people who have shipped tests.
6. How do you run tests in parallel?
Playwright's test runner parallelises by default. Workers run multiple tests at once within a single process group. Sharding splits a run across multiple machines via --shard=1/4. Strong candidates will mention that parallelism only works if tests are isolated (no shared state, no shared accounts) and that this is a discipline problem, not a config problem.
Intermediate questions
7. What is the recommended locator strategy and why?
Role-based locators (getByRole) for user-facing elements, getByTestId for ambiguous cases, CSS as a fallback, avoid XPath. The reason is that role-based locators map to what the user sees and double as accessibility coverage. Candidates who default to CSS classes or testids on everything reveal a gap. Our full take is in the Playwright locators guide.
8. How do you handle authentication in a Playwright test suite?
Store the authenticated state once with storageState and reuse it across tests. Avoid logging in at the start of every test (slow, fragile, hits rate limits). Strong candidates will also discuss how to handle MFA, expired sessions, and per-test variations of the same logged-in state.
9. How does Playwright handle iframes and shadow DOM?
Iframes are accessed through frameLocator. Shadow DOM is handled transparently by most locators (Playwright pierces open shadow roots automatically). Candidates who say "you can't test shadow DOM" or who reach for evaluate-in-browser tricks are out of date.
10. What is a fixture in Playwright Test?
A piece of setup or teardown logic scoped to a test, a file, or the whole run. Fixtures are how Playwright handles dependency injection (browser, page, authenticated state, custom test data). The right answer mentions that fixtures are composable and that overusing global setup is a smell.
11. How do you debug a flaky test?
Run with --debug or open the trace viewer for a failing run. The trace shows screenshots, DOM snapshots, console logs, and network activity for every step. Strong candidates will diagnose flake by looking at the trace before asking for code changes. Weak candidates will guess.
12. How do you write API tests in Playwright?
Use the request fixture or page.request. Playwright can issue HTTP calls directly without driving a browser, share cookies with browser contexts, and assert on responses with the same expect API. This is useful for setting up test state quickly and for hybrid suites that mix UI and API checks.
Advanced questions
13. How would you design a Playwright test architecture for a team of 30 engineers?
A real answer should cover Page Object Model or component-object hybrid, shared fixtures, a stable locator policy, parallel-safe test data strategy, environment-specific config, CI sharding, and reporting. The right answer also covers what not to over-engineer. Avoid premature abstractions, do not write a custom test framework on top of Playwright, do not hand-roll parallelism. Senior candidates will name the trade-offs.
14. How do you handle test data in parallel runs?
Three common patterns. Per-test data creation through API setup. Per-worker data isolation through user pools. Database snapshots restored per shard. Senior candidates will know that "shared seed data" is the pattern that quietly causes most parallel-run flake.
15. How does Playwright compare to Cypress and Selenium?
A short version of our full Playwright vs Cypress and vs Selenium takes. Multi-browser, true parallelism, broader language support, out-of-process control, auto-waiting. The strongest answers will also name the cases where Cypress or Puppeteer is still the right call.
16. How do you run Playwright in CI?
Docker (usually the official mcr.microsoft.com/playwright image), with parallel sharding, retries on failure, trace and HTML report upload as artifacts. Strong candidates will name specific CI platforms (GitHub Actions, GitLab, CircleCI) and the trade-offs of each. The full breakdown is in our Playwright Docker guide.
17. How would you stop a test suite from being flaky?
Diagnose first (use traces), then categorise. Locator flake is fixed with role-based selectors. Timing flake is fixed by removing manual waits and using web-first assertions. State flake is fixed with proper isolation. Environment flake is fixed at the infrastructure level. A senior engineer will treat flake as a system problem, not a per-test problem.
18. What is the role of accessibility in a Playwright test suite?
Role-based locators force you to write code that depends on accessible names and roles. Tests that pass tend to be tests against an accessible application. Playwright also integrates with axe-core for explicit accessibility audits. Senior candidates will frame accessibility as a first-class outcome of the locator strategy, not an afterthought.
19. How do you handle visual regression testing in Playwright?
expect(page).toHaveScreenshot() is built in. Mask dynamic regions, use a stable viewport, run in a Docker image to keep pixel rendering consistent. Our full take is in the Playwright visual regression testing guide. Watch for candidates who confuse visual testing with end-to-end testing. They cover different bugs.
20. Should we build a Playwright test suite ourselves or use a managed service?
This is a trick question worth asking. There is a real case for both. Strong candidates will name the trade-offs (engineering cost, maintenance load, time to coverage, control over the test code) rather than picking a side blindly. Anyone who answers "always build" or "always buy" has not run a real test programme.
What the strongest answers look like
Three patterns separate strong Playwright candidates from people who have memorised a tutorial.
First, they reach for architectural reasoning before syntax. Why does auto-waiting work? Why is the locator model better than the old selector model? Why does Cypress run in the browser? Candidates who can explain mechanisms will be able to debug things they have never seen.
Second, they understand the maintenance burden. Tests are easy to write and expensive to keep working. Strong candidates have opinions about flake, locator drift, parallel-run isolation, and the hidden cost of an in-house test programme. They have war stories.
Third, they know what to avoid. Custom frameworks built on top of Playwright. Hand-rolled parallelism. Tests that share global state. XPath. The senior signal is restraint.
An alternative path with Bug0
Hiring strong Playwright engineers is hard. Keeping them focused on shipping product instead of debugging flaky CI is harder. Most teams underestimate how much senior engineering time disappears into test maintenance after the first year.
Bug0 is the managed alternative. AI agents generate and maintain Playwright tests for your critical user flows, real browsers run them at scale on our infrastructure, and human QA experts verify every result before it reaches your engineers. The framework underneath is Playwright. The interview load is not yours.
Conclusion
Playwright interviews are easy to fail by testing the wrong things. Syntax recall is cheap. The judgment that separates a useful test engineer from a person who has read the docs lives in three places. Locator strategy, flake diagnosis, and the maintenance economics of a real test suite.
Screen for those, in roughly that order, and the seniority question answers itself.
FAQs
What should I study for a Playwright interview?
The official docs, especially the sections on locators, fixtures, auto-waiting, and parallel execution. Build a small test suite for a real application, run it in Docker, and put it in CI. Understanding why Playwright works the way it does matters more than memorising every API.
Is Playwright hard to learn?
The basics are straightforward, especially if you have used Cypress, Puppeteer, or Selenium before. The hard part is not the API. It is the discipline of writing tests that age well, which takes time and exposure to a real test suite under real maintenance pressure.
What languages are Playwright interview questions asked in?
Most commonly TypeScript or JavaScript, with Python second. The conceptual questions are the same across languages. The syntax differences are minor.
How many years of experience do you need to be senior in Playwright?
Two to four years of writing and maintaining a real test suite, ideally one that you have shipped, debugged in CI, and refactored at least once. Years of "I have used Playwright" without owning a suite are not the same thing.
What is the difference between QA automation and Playwright engineering?
QA automation is the broader discipline. Playwright is one of the tools. A strong QA automation engineer should be able to evaluate Playwright against Cypress, Puppeteer, and Selenium and make a recommendation based on the team and product context.
How does Bug0 reduce hiring pressure on Playwright engineers?
Bug0 handles the test generation, maintenance, and infrastructure. Your existing engineers can stay focused on product. The senior Playwright hire you were planning to make becomes optional, or becomes a hire for a different, more strategic role.