Core Concepts Interviewers Test
Interviewers frequently start with 'why Playwright over Selenium', expecting candidates to mention Playwright's auto-waiting mechanism (no explicit sleeps needed for most interactions), its ability to control multiple browser contexts from a single browser instance for true test isolation without relaunching the browser, and native support for modern web features like network interception, and multiple browser engines (Chromium, Firefox, WebKit) from one API. A strong answer also distinguishes a BrowserContext, an isolated, incognito-like session, from a Page, a single tab within that context, since confusing the two is a common gap in candidates' mental models.
Cricket analogy: Explaining why Playwright beats Selenium is like explaining why DRS beats the old system, both watch the game, but one has smarter, faster, more reliable checks built in rather than relying on a human's fixed reaction time.
Locators and Selectors Deep Dive
A classic interview question is 'what's the difference between a Locator and an ElementHandle', and the expected answer is that a Locator is a lazy, auto-retrying reference that re-queries the DOM every time an action or assertion is performed on it, while an ElementHandle is a direct, static reference to a specific DOM node at the moment it was captured, which becomes stale if the DOM changes. Interviewers also probe whether candidates know to prefer page.locator() over the older page.$() and page.$$() APIs, since the latter return ElementHandles and don't benefit from auto-waiting or retry-ability at all.
Cricket analogy: A Locator is like a scorecard entry that always shows 'current striker' and updates live as batters rotate, while an ElementHandle is like a photo of the striker at one specific ball, it doesn't update if a new batter comes in.
// Locator: lazy, auto-retrying, re-queries the DOM each time
const submitBtn = page.locator('button[type="submit"]');
await submitBtn.click(); // waits for actionable state automatically
// ElementHandle: static snapshot, no auto-waiting, can go stale
const handle = await page.$('button[type="submit"]');
await handle?.click(); // may throw if the DOM has since changed
// Interview tip: page.locator() is preferred in virtually all modern code
await expect(page.locator('.toast')).toHaveText('Saved successfully');Advanced Topics: Network, Auth, Parallelism
Senior-level interviews probe network interception via page.route(), asking candidates to mock an API response or simulate a failure (route.fulfill() vs route.abort()) to test error-handling UI without depending on a real backend. Another common thread covers parallelism internals: candidates should be able to explain that Playwright Test distributes test files across worker processes (not individual tests within a file, by default), and that fullyParallel: true changes this so individual tests within a file can also run concurrently in separate workers.
Cricket analogy: Mocking an API with page.route() is like a training net where the bowling machine simulates a specific delivery on demand, a yorker every time, rather than waiting for a real bowler to happen to bowl one.
A strong interview answer on parallelism mentions: by default, Playwright Test parallelizes at the file level across workers; setting fullyParallel: true in the config additionally parallelizes individual tests within the same file, which is useful for suites with large describe blocks containing many independent tests.
Debugging and Troubleshooting Questions
Interviewers often ask how a candidate would debug a test that fails only in CI but passes locally, and the expected toolbox includes the Trace Viewer (npx playwright show-trace trace.zip) which replays a full DOM snapshot, network log, and console output for the failed run, plus enabling trace: 'on-first-retry' in config to capture that data automatically. Candidates should also know npx playwright test --debug launches the Playwright Inspector for step-through debugging, and npx playwright codegen can record a user flow into working locator code, useful both for writing new tests and for verifying what selector Playwright would choose for a given element.
Cricket analogy: The Trace Viewer replaying a failed test is like the third umpire reviewing ball-by-ball footage after a controversial decision, rather than relying on memory of what happened live in real time.
A common interview trap: candidates say Playwright tests 'never need retries' because of auto-waiting. That's incorrect. Auto-waiting handles element readiness, but CI environments introduce genuine external flakiness (network latency, resource contention) that legitimate retries (retries: 2) are designed to absorb.
- Be ready to explain why Playwright's auto-waiting and BrowserContext isolation beat Selenium's model.
- Know the Locator vs ElementHandle distinction: lazy and auto-retrying versus a static, staleness-prone reference.
- Understand page.route() for mocking responses (route.fulfill()) and simulating failures (route.abort()).
- Explain Playwright's default file-level parallelism versus fullyParallel: true for per-test parallelism.
- Know the debugging toolbox: Trace Viewer, --debug Inspector, and codegen.
- Correctly explain that auto-waiting does not eliminate the need for CI retries.
- Be able to reason about storageState and multi-context isolation in system-design-style questions.
Practice what you learned
1. What is the key structural difference between a Locator and an ElementHandle?
2. How does page.route() with route.fulfill() help in testing?
3. By default, at what level does Playwright Test parallelize execution?
4. What does npx playwright test --debug do?
5. Why is it incorrect to say Playwright tests never need retries because of auto-waiting?
Was this page helpful?
You May Also Like
Playwright Best Practices
A practical guide to writing reliable, maintainable Playwright tests by choosing the right locators, avoiding flaky waits, and keeping tests isolated and fast.
Page Object Model in Playwright
How to structure Playwright tests using the Page Object Model to separate UI locators and actions from test logic for better maintainability.
Playwright Quick Reference
A condensed cheat sheet of the most-used Playwright locators, assertions, actions, and CLI commands for day-to-day test writing.