Playwright Interview Questions for Experienced (2, 3 and 5+ Years) with Answers

Experienced Playwright interviews focus on decisions, trade-offs and real problems you have solved. This guide groups the most common questions by experience level, with clear model answers and scenario questions used in SDET and automation lead interviews.

---

🎯 How Experienced Interviews Differ

Fresher interviews ask what a feature is. Experienced interviews ask why you chose it, how you scaled it, and what went wrong. Interviewers listen for real decisions, trade-offs and numbers (“we cut the suite from 40 to 9 minutes by…”).

Use this structure for every answer: concept, how you used it, the result. Questions are grouped by the experience level at which they are most commonly asked; prepare one level above your own.

For fundamentals, start with 200 Playwright + TypeScript interview questions.

---

🟢 2 Years of Experience: Strong Fundamentals

🤔 How does Playwright’s auto-waiting work, and when do you still need explicit waits?

Before each action Playwright checks that the element is attached, visible, stable, enabled and receives events (and editable for fill). Web-first assertions retry until they pass. Explicit waits are still useful for non-element conditions, such as waitForResponse for an API call, waitForURL after navigation, or waitForEvent('popup'). I avoid waitForTimeout completely. See Playwright waits.

🤔 What is the difference between page.locator() and page.$()?

locator() is lazy and re-resolves the element every time it is used, with auto-waiting and strictness. page.$() returns an ElementHandle immediately, which can become stale and does not auto-wait. Locators are the recommended API; element handles are discouraged.

🤔 Which locator strategy do you prefer and why?

User-facing locators first: getByRole with a name, then getByLabel, getByPlaceholder, getByText, then getByTestId. CSS for ids and test attributes, XPath only when I need text plus structure or parent navigation. They are resilient to styling changes and reflect what users see. See CSS and XPath selectors.

🤔 What is strict mode in Playwright?

Actions on a locator fail if it matches more than one element. It prevents clicking the wrong element. I fix violations by making the locator more specific or using filter, not by adding first() everywhere.

🤔 What is the difference between toHaveText and textContent with toBe?

await expect(locator).toHaveText() is a web-first assertion that retries until the text matches. expect(await locator.textContent()).toBe() reads once and fails if the page has not updated yet, which causes flakiness.

🤔 How do you handle a new tab, an alert and an iframe?

New tab: start page.waitForEvent('popup') before the click. Alert: page.once('dialog', d => d.accept()) before the action; Playwright dismisses dialogs by default. Iframe: page.frameLocator() or locator.contentFrame(). See alerts, popups, iframes and tabs.

🤔 What is a browser context and why is it important?

An isolated, incognito-like session with its own cookies and storage. Each test gets a fresh context, which gives isolation without restarting the browser. Contexts also let one test simulate multiple users.

🤔 How do you run a single test, a tag or a browser from the command line?

npx playwright test file.spec.ts:12, --grep @smoke, --project=firefox, and --ui or --debug for investigation. See CLI commands.

---

🔵 3 Years of Experience: Framework and Reliability

🤔 Describe the architecture of the Playwright framework you built.

Tests in tests/ grouped by feature; src/pages for page objects and components; src/api for API clients; src/fixtures extending test to inject pages, API clients and data; typed data and factories; config per environment through TEST_ENV; a setup project that saves storageState; tags for smoke and regression; HTML and JUnit reporters; GitHub Actions with sharding. Link this to framework structure and give your own numbers.

🤔 Fixtures or hooks: when do you use which?

Hooks for simple, file-specific setup. Fixtures for anything reusable: they combine setup and teardown, run only when requested, can be test- or worker-scoped and pass values directly into tests. In our framework all page objects, API clients and test users come from fixtures. See hooks and custom fixtures.

🤔 How do you avoid logging in through the UI in every test?

A setup project logs in once per role and saves storageState to a file; test projects depend on it and load that state. For multiple roles I use one storage file per role and a fixture or project per role. See save login session.

🤔 How do you handle test data in parallel runs?

Each test creates its own data through the API with unique values (timestamp plus workerIndex) and cleans it up in the same fixture. Shared static data is read-only. Worker-scoped fixtures provide one account per worker when accounts are expensive to create.

🤔 A test is flaky in CI but passes locally. What do you do?

Reproduce with --repeat-each and several workers; enable trace: 'on-first-retry' and inspect the failing attempt in the Trace Viewer: actionability log, DOM snapshot, network and console. Common causes are timing assumptions, shared data, environment differences and overlays. Fix the root cause; retries are only a safety net. See flaky tests and Trace Viewer.

🤔 How do you combine API and UI testing?

API for setup, cleanup and fast verification; UI for user-visible behaviour. For example, create an order through the API, then verify it on the orders page. page.request shares cookies with the page when the API needs the logged-in session. See the hybrid framework project.

🤔 When do you mock network calls?

For error, empty and edge states, unreliable third-party services and features whose backend is not ready. Critical end-to-end journeys run against real services. I use page.route with fulfill, route.fetch to modify real responses, and HAR replay for stable fixtures. See network mocking.

🤔 How do you run tests across environments?

Base URLs per environment in config, selected by an environment variable; secrets from CI secret stores; .env locally with .env.example committed. Projects or separate config files for API and UI.

🤔 How do you implement visual testing, and how do you keep it stable?

toHaveScreenshot on key pages and components, with masks for dynamic content, small tolerances and baselines generated in the same Docker image as CI. Visual tests run in one browser project. See visual testing.

---

🟠 5+ Years of Experience: Architecture, Scale and Strategy

🤔 How would you design a test automation strategy for a new product?

Start from risk and the test pyramid: most checks at unit and API level, a focused set of end-to-end journeys in Playwright, visual checks for key screens, and contract tests between services. Define quality gates (smoke on every PR, full regression nightly), environments and data strategy, ownership, and metrics such as pipeline time, flaky rate and escaped defects.

🤔 How do you scale a suite of 3,000 Playwright tests?

fullyParallel plus sharding across CI machines with merged blob reports; login and data setup through API and storage state; tag-based selection so PRs run only relevant suites; trace on retry only; resource blocking where safe; regular removal of low-value or duplicate tests; and monitoring of the slowest tests. See parallel execution and sharding.

🤔 How do you measure and reduce flakiness at team level?

Track flaky tests from CI reports over time, fail release pipelines on flaky tests (--fail-on-flaky-tests), quarantine with a tag and a ticket, and require a root-cause fix within a set time. Review new tests with --repeat-each before merging.

🤔 How do you migrate a Selenium suite to Playwright?

Assess value first; do not port everything. Build the new framework skeleton, start with smoke journeys, run both suites in parallel for a period, migrate feature by feature with a concept map (waits to web-first assertions, switchTo to frameLocator and popup events), and retire Selenium tests as coverage moves. Measure execution time and flakiness before and after. See Playwright vs Selenium vs Cypress.

🤔 Which design patterns do you use in a Playwright framework?

Page Object and component objects, fixtures as dependency injection, factory and builder for test data, strategy for environment-specific behaviour, and facades for multi-step business flows. SOLID principles keep classes small and replaceable. See design patterns and SOLID.

🤔 How do you make the framework maintainable for a large team?

Clear layering and naming conventions, ESLint with the Playwright plugin, type checking in CI, code review checklists, documentation and examples, shared fixtures owned by the platform team, and pairing for onboarding.

🤔 How do you integrate Playwright into CI/CD and release decisions?

PR gate with smoke tests and type checks, nightly cross-browser regression, post-deployment smoke against each environment, reports and traces as artifacts, JUnit for dashboards, and notifications through a custom reporter. A failed gate blocks the merge or deployment. See GitHub Actions and Jenkins.

🤔 How are you using AI in test automation?

Playwright MCP for exploration and drafting, and Playwright Test Agents to plan, generate and heal tests, always with human review of plans, generated code and healed diffs. AI speeds up authoring and maintenance; deterministic tests in CI remain the source of truth. See Playwright MCP and Test Agents.

---

🧩 Scenario-Based Questions

🤔 The login page takes 8 seconds in the test environment and 200 tests log in through the UI. What do you change?

Log in once per role in a setup project and reuse storageState, or create sessions through an API. That removes 200 slow UI logins and their flakiness.

🤔 A button is sometimes covered by a toast notification and the click fails. How do you fix it?

Wait for the toast to disappear (await expect(toast).toBeHidden()) or close it, then click. Do not use force: true, which hides real user-facing problems.

🤔 Your suite takes 45 minutes on one CI machine. The team wants feedback in under 10. What is your plan?

Measure first (slowest tests, setup time). Then: fullyParallel, 4 shards with merged reports, API-based setup, storage state, smoke subset on PRs and full suite nightly, and remove redundant UI tests already covered at API level.

🤔 A healer agent “fixed” a failing test by changing the expected total. What do you do?

Reject the change and investigate: a changed expected value may hide a real bug. Healed changes are reviewed like any code change; skipped or changed assertions require confirmation from the product or development team.

🤔 Tests pass alone but fail when run in parallel. What is the likely cause?

Shared state: the same user, cart or record used by several tests. Make data unique per test or per worker and remove dependencies between tests.

---

💡 Tips for the Interview

• Prepare two stories: one about improving speed, one about fixing flakiness, each with numbers.
• Be ready to share your screen and walk through your framework; a public project from Project 2 or Project 3 is ideal.
• For lead roles, also review QA automation lead interview questions and manager round questions.
• Practise writing a test live, without an IDE’s autocomplete, for a simple login and an API call.

---

🎯 Next Steps

• 📄 Playwright Cheat Sheet
• 💼 AI + QA Automation Interview Questions
• 🧪 Playwright with TypeScript MCQ Assessment
• 🎭 Playwright Tutorial with TypeScript