// Interview Prep/Mock Interviews/Playwright / Cypress mock interview

🎭 Playwright / Cypress mock interview

Set a timer, work through each round out loud, then score your answers against the rubric. No one is listening — the goal is honest self-assessment, not a perfect performance.

Mid⏱ 45 min·Automation QA

// ROUND STRUCTURE

  1. 1
    Warm-up— 5 min

    Intro, which tools you've used, and what you've tested with them.

  2. 2
    Framework concepts— 15 min

    Auto-wait mechanisms, test isolation, selector strategies.

  3. 3
    Advanced features— 15 min

    Network interception, API testing from E2E, parallelism, auth storage.

  4. 4
    Design decisions— 10 min

    Playwright vs Cypress trade-offs, when to choose each, pitfalls.

  5. 5
    Wrap-up— 5 min

    Candidate questions and interviewer summary.

// INTERVIEW QUESTIONS

  1. 01

    How does Playwright's auto-waiting mechanism work? How is it different from Cypress's command retry?

  2. 02

    What is a browser context in Playwright? Why does it matter for test isolation?

  3. 03

    How would you intercept a network request in Playwright and return a mocked response?

  4. 04

    Walk me through stubbing an API call in Cypress with cy.intercept() and asserting the stub was hit.

  5. 05

    How do you run tests in parallel in Playwright? What are the constraints?

  6. 06

    How do you implement the Page Object pattern in Playwright? Show me the structure.

  7. 07

    How do you handle authentication in E2E tests efficiently — without re-logging in before every test?

  8. 08

    A test occasionally fails because an element 'is not visible'. Walk me through your debugging process.

  9. 09

    When would you choose Cypress over Playwright, and when would you choose Playwright?

// EXPECTED ANSWER POINTS

Compare your answers to these points — one per question, in order.

  1. Playwright auto-waits on every action: before clicking an element it checks it is attached to DOM, visible, stable (not animating), enabled, and receives pointer events. These are actionability checks, not configurable timeouts. Cypress retries the entire command chain up to a timeout — each command re-queries the DOM. Playwright's model is per-action; Cypress's is per-assertion chain.

  2. A browser context is an isolated 'incognito session' inside a browser process — it has its own cookies, localStorage, session storage, cache, and permissions. Multiple contexts share one browser process (cheaper than launching a new browser). This enables running multi-user scenarios in one test and true per-test isolation without browser restart overhead.

  3. Use page.route(). Call it before the action that triggers the request: `await page.route('**/api/users', route => route.fulfill({ status: 200, contentType: 'application/json', body: JSON.stringify({ users: [] }) }))`. The route intercepts matching requests and responds with the mock — the application never reaches the real server.

  4. cy.intercept('GET', '/api/users', { fixture: 'users.json' }).as('getUsers') — sets up a stub alias. After triggering the request: cy.wait('@getUsers') pauses until the stub is hit. Chain assertions: cy.get('@getUsers').its('response.statusCode').should('eq', 200). cy.get('@getUsers').its('request.url').should('include', '/api/users').

  5. Playwright parallelism: set fullyParallel: true in playwright.config.ts to run all tests (not just files) concurrently. The workers setting controls the number of parallel workers. Each worker gets an isolated browser context — no shared state. Constraint: tests must be fully independent (no shared files, no shared database rows, no test-order dependencies).

  6. Playwright POM: a class that receives a Page in its constructor. Methods return await-able Promises (or this for chaining). Use Playwright fixtures to inject page objects into tests — create a fixtures file that extends test from @playwright/test, define a custom fixture for each page object, and import the fixture in test files instead of the base test.

  7. Use Playwright's storageState. Run login once: `await page.context().storageState({ path: 'auth.json' })`. In playwright.config.ts set `use: { storageState: 'auth.json' }` globally or per project. Each test starts with a pre-authenticated context — no login round trip. For Cypress: use cy.session() which caches and restores cookies/localStorage between tests.

  8. Debugging steps: (1) Is the element in the DOM? Use page.$() / cy.get() and check if it returns the element at all — existence vs visibility are different. (2) Is something covering it? Check z-index, overlapping modals, or a sticky header using DevTools. (3) Is it in a scroll container? Use scrollIntoViewIfNeeded() or a scroll action. (4) Is it inside an iframe? Playwright and Cypress need explicit frame handling. (5) Use page.pause() (Playwright) or debugger (Cypress) to freeze execution and inspect.

  9. Choose Cypress: team prefers JavaScript-first DX with time-travel debugging, component testing is a priority (Cypress Component Testing is mature), Cypress Dashboard for CI recording. Choose Playwright: need multi-browser (Firefox, Safari/WebKit, Chromium), multi-language (TypeScript, Python, Java, C#), parallel workers without a paid plan, API testing integrated in the same test file, mobile emulation, or multi-page/multi-tab scenarios.

// SCORING RUBRIC

Strong (4–5)

Accurately describes Playwright actionability checks vs Cypress retry. Knows storageState for auth. Writes network interception correctly for both tools. Articulates trade-offs between tools based on concrete scenarios. Understands browser context as an isolation primitive.

Acceptable (3)

Can write basic tests in one or both tools. Knows interception exists and has used it. Less confident on browser contexts, parallel workers, or auth storage patterns. Trade-off answer is surface level.

Weak (1–2)

Cannot explain auto-wait beyond 'it just waits.' Has never intercepted a network request. Uses page.waitForTimeout() or cy.wait(number) as primary strategy. Cannot compare tools meaningfully.

// RED FLAGS

Answers or behaviours that signal a weak candidate to the interviewer.

  • Cannot explain what 'auto-wait' means beyond a vague 'it waits automatically.'

  • Has never intercepted a network request in either tool.

  • No understanding of browser contexts or what they provide.

  • Uses page.waitForTimeout() / cy.wait(number) as the primary synchronisation strategy.

  • Cannot articulate a single reason to choose Playwright over Cypress or vice versa.

  • No experience with storageState, cy.session(), or any auth caching strategy.

// FOLLOW-UP QUESTIONS

Questions a strong interviewer adds if you answered the main round well.

  1. 01

    How do you implement visual regression testing in Playwright?

  2. 02

    What is Playwright's fixture system and how does it improve test organisation compared to beforeEach hooks?

  3. 03

    How do you handle multi-tab or multi-window scenarios in Playwright?

// SELF-ASSESSMENT CHECKLIST

Tick these off mentally after the mock. Be honest — this is for you, not for the interviewer.

  • I explained Playwright's auto-wait mechanism with the specific actionability checks — not just 'it waits.'
  • I correctly described browser context and why it enables per-test isolation.
  • I described network interception syntax for at least one tool with enough detail to implement it.
  • I explained the storageState or cy.session() auth pattern — not re-login for every test.
  • I described a multi-step debugging process for the 'not visible' scenario.
  • I gave a structured, scenario-based comparison of when to choose Playwright vs Cypress.

// RECOMMENDED NEXT MOCK

🔬 SDET technical mock interview

Senior · 60 min

// STUDY THESE NEXT

Automation QA role track →Automation QA prep plan →Practical assignments →Scenario practice →