Practice

Playwright Interview Practice

Practice Playwright interview questions through real scenarios on locators, waits, assertions, API setup, framework design, CI, and debugging.

Interview Focus Areas

Playwright interviews usually test whether you can build reliable automation, not whether you memorized syntax. Your answers should connect code with stability, debugging, and framework thinking.

  • Locators and strict mode.
  • Auto-waiting and assertions.
  • Browser, context, page, and isolation.
  • API setup and network mocking.
  • Fixtures, Page Object Model, reports, trace viewer, and CI.

Common Playwright Questions

  1. What is Playwright and why would you choose it?
  2. How is Playwright different from Selenium?
  3. What are browser, browser context, and page?
  4. Why are role locators preferred?
  5. How do you handle flaky tests?
  6. How do you reuse login state?
  7. How do you run tests in CI?

Scenario-Based Questions

  • A click works locally but fails in CI. How do you debug it?
  • A test passes alone but fails in parallel. What do you check?
  • The same Save button appears in every row. How do you click the right one?
  • An API is unstable. How can you test the UI error state?
  • A test is slow because it logs in every time. How do you improve it?

Coding Round Examples

Fix a flaky wait

// Weak
await page.waitForTimeout(3000);
await page.click('.save');

// Better
await page.getByRole('button', { name: 'Save' }).click();
await expect(page.getByText('Saved')).toBeVisible();

Explanation: A strong answer removes fixed waiting, uses a readable locator, and verifies the result.

Best Answer Pattern

  1. State the problem in plain language.
  2. Name the Playwright feature you would use.
  3. Show a short example.
  4. Explain why it is reliable.
  5. Mention how you would debug if it still failed.

Practice Checklist

  • Prepare one example each for locators, waits, API setup, auth storage, POM, trace viewer, and CI.
  • Practice explaining failures, not only writing happy-path code.
  • Keep answers short, practical, and tied to real test reliability.
☰