35. Interview Prep

A representative set worth being able to answer fluently, not memorized verbatim:

modern web app compatibility (Part 0/1).

Chapter 3).

hardcoded sleeps, and systematic flaky-test tracking (Chapter 30) rather than "I just add retries."

17).

setup (Chapter 32).

• "Why Playwright over Selenium?" — auto-waiting, native multi-browser support,
• "What's the Browser/Context/Page hierarchy, and why does it matter?" (Part 1,
• "How do you handle flaky tests?" — distinguish auto-waiting/explicit waits from
• "Explain the Page Object Model and why you'd use it" (Chapter 14).
• "How would you test [X] without a real backend?" — network mocking (Chapter
• "How do you speed up a slow test suite?" — parallelization, auth reuse, API-based

Interviewers often prefer live scenarios over recited definitions:

Viewer (Chapter 24) as the concrete tool.

where you'd add both UI and API assertions.

Pointers: The strongest answers connect a general principle to a specific tool/method by name (e.g., "I'd check the Trace Viewer output first" rather than "I'd look into it") — it signals hands-on experience rather than surface-level familiarity.

• "This test passes locally but fails in CI — how do you debug it?" — walk through: headless-specific behavior, missing --with-deps, environment variable differences, timing differences on a slower CI machine, and reach for Trace
• "How would you design tests for a multi-step checkout flow?" — talk through POM per step/page, API-based cart setup to skip repetitive earlier steps, and

Practice a tight, concrete explanation for each rather than a textbook definition:

updating one file instead of every test that touches that element."

in fresh before every test."

debuggable without re-running locally."

Pointers: Being able to explain why a decision was made (not just what it does) is consistently what separates a strong interview answer from a shallow one — this mirrors the "explain the why" thread running through this entire manual.

• POM: "Each page's locators and actions live in one class, so a UI change means
• Fixtures: "Reusable setup/teardown — for example, a session-scoped fixture that logs in once and shares that session across the whole suite, instead of logging
• CI setup: "Tests run automatically on every pull request via GitHub Actions, with the HTML report published as a downloadable artifact so failures are