Playwright TypeScript Pair Programming Interview Questions (2026)

TL;DR

A Playwright TypeScript pair programming interview measures problem framing, browser automation judgment, TypeScript fluency, debugging, and collaboration. Build the smallest trustworthy test, narrate decisions, verify it, and discuss how you would harden it for production.

Key Takeaways

• Clarify behavior, constraints, and evidence before typing the first locator.
• Prefer accessible locators, web-first assertions, and observable synchronization over DOM shortcuts and sleeps.
• Use TypeScript types to expose invalid test data and ambiguous helper contracts early.
• Keep each example isolated with owned state, deterministic data, and focused cleanup.
• Narrate trade-offs while preserving a small, runnable vertical slice.
• Debug from traces, network evidence, and failure signatures instead of adding retries blindly.
• Finish by running the test, explaining remaining risks, and naming the next improvement.

Playwright typescript pair programming interview questions test more than whether you remember an API. The interviewer wants to see how you clarify an ambiguous requirement, produce a small working test, read evidence, and improve the design without losing control of the session.

Treat the exercise as collaborative engineering. State assumptions, ask targeted questions, and run the test early. If you need a broader framework refresher first, review how to build a Playwright TypeScript framework, then return here and practice each prompt aloud.

TL;DR

Your working loop is simple: restate the requirement, identify the riskiest behavior, automate one end-to-end path, run it, inspect the result, and refactor only where the code has earned an abstraction. For a wider question bank, use the complete Playwright interview guide.

1. Core playwright typescript pair programming interview questions

Q: How do you start a Playwright pair programming exercise?

Begin by restating the user behavior and the expected observable outcome. Ask which environment, authentication state, browser coverage, and data constraints apply, then propose the smallest vertical slice that can prove the behavior. Open the existing configuration before creating files so your solution follows the repository rather than inventing a parallel structure.

Q: What should you clarify when the prompt says to test login?

Separate successful authentication from validation, locked accounts, session persistence, and authorization after login. Confirm whether credentials may be provisioned through an API and whether the identity provider belongs to the product or a third party. Define success as a durable signal such as an authenticated API response, protected URL, or account-specific element, not merely a click with no error.

Q: How much should you narrate while coding?

Explain decisions that affect correctness, such as locator choice, data ownership, and the event you will await. Keep syntax commentary brief because reading every keystroke hides the reasoning the interviewer needs to evaluate. Pause after each runnable increment to summarize what is proven and what remains uncertain.

Q: How do driver and navigator roles work in a pair interview?

The driver writes and runs the code while the navigator watches assumptions, edges, and direction. If the interviewer offers an idea, acknowledge it, compare it with the current approach, and either incorporate it or explain the constraint it violates. Role changes are healthy when they preserve shared context instead of becoming a silent takeover.

Q: What should you do after the interviewer points out a bug?

Reproduce or reason through the failure before editing, then thank them for the signal and correct the underlying assumption. Describe why the original code failed, whether nearby cases share the risk, and how one focused assertion would prevent regression. Defensiveness costs more than a mistake because pairing explicitly tests how you use feedback.

2. Locator and DOM Questions

Q: Which locator should you choose first?

Start with getByRole and the accessible name when the element represents an interactive control. Labels, text, alternative text, and test IDs are useful when they match the product's semantics or an explicit testing contract. Generated classes, deep CSS chains, and positional XPath usually encode layout rather than intent, so they should require a concrete justification.

Q: How do you handle a strict-mode locator failure?

A strictness error means the action target resolved to more than one element, which exposes ambiguity rather than random flakiness. Inspect the candidates, scope to the correct region or row, and refine by accessible name or a stable attribute. Using first() merely silences the evidence unless position is itself part of the requirement.

import { test, expect } from '@playwright/test';

test('edits the matching account row', async ({ page }) => {
  await page.setContent(`
    <table>
      <tr><td>Starter</td><td><button>Edit</button></td></tr>
      <tr><td>Enterprise</td><td><button>Edit</button></td></tr>
    </table>
  `);

  const enterpriseRow = page.getByRole('row').filter({ hasText: 'Enterprise' });
  await enterpriseRow.getByRole('button', { name: 'Edit' }).click();
  await expect(enterpriseRow).toContainText('Enterprise');
});

Run it with npx playwright test tests/locators.spec.ts after saving the block under that path.

Q: How would you select one item in a dynamic list?

Wait for a stable list condition with toHaveCount or a known loading-state transition before reading the collection. Filter the locator by a business identifier, then act within that item instead of capturing an ElementHandle while the DOM may rerender. If duplicate names are legal, combine visible text with a unique row attribute or associated metadata.

Q: How do you work with an iframe?

Use frameLocator with a stable selector for the iframe and continue locating by role or label inside that frame. Confirm whether the frame is same-origin only if the test needs page JavaScript, because Playwright interactions themselves can cross origins. A production answer should also mention frame loading, payment-provider ownership, and the boundary between testing integration and retesting the vendor.

Q: Does Playwright pierce Shadow DOM?

Standard Playwright locators search through open shadow roots, so a role or text locator often needs no special traversal code. XPath does not pierce shadow roots, and closed roots remain inaccessible by design. During pairing, verify the actual component behavior before adding brittle selectors that mirror its internal shadow structure.

3. Async Control and Auto-Waiting

Q: Why must Playwright actions be awaited?

Actions return promises because browser commands cross an asynchronous protocol boundary. Omitting await can let the test advance, finish, or throw elsewhere before the command completes, producing misleading order and unhandled rejections. Type checking and lint rules help, but the candidate should still understand which operations schedule browser work.

Q: What does Playwright auto-wait for before a click?

The click target must resolve uniquely and satisfy relevant actionability checks such as visibility, stability, event reception, and enabled state. That protects browser mechanics, but it cannot know whether inventory loaded, a background job finished, or the business record reached the required status. Pair the action with an assertion on the outcome rather than assuming actionability equals application readiness.

Q: When is waitForTimeout acceptable?

A fixed delay can be useful temporarily while diagnosing animation or collecting evidence, but it is not a reliable synchronization contract. Replace it with a locator assertion, specific request or response, URL change, download, popup, or polled domain state. Keeping a sleep in the final exercise shows that the solution depends on timing luck and wastes the full delay on fast runs.

Q: How do you wait for a popup without racing it?

Create the page.waitForEvent('popup') promise before clicking the control that opens the window, then await both in a deterministic order. The same pre-registration pattern applies to downloads and other events that can occur immediately. Once the popup exists, assert a meaningful URL or content and close it if the test owns its lifecycle.

Q: How do you test an eventually consistent status?

Poll a read-only signal until it reaches the desired state, with a bounded timeout and diagnostic last value. Trigger the mutation once outside the polling callback so retries do not create duplicate orders or jobs. Playwright's expect.poll works well when no locator can expose the condition directly.

import { test, expect } from '@playwright/test';

test('waits for a background status', async () => {
  let status: 'pending' | 'ready' = 'pending';
  setTimeout(() => { status = 'ready'; }, 50);

  await expect.poll(() => status, {
    message: 'background job should become ready',
    timeout: 2_000
  }).toBe('ready');
});

Verify with npx playwright test tests/eventual-status.spec.ts.

4. Assertion and User-Outcome Questions

Q: What makes a strong Playwright assertion?

A strong assertion proves the business-visible consequence at the boundary most likely to catch the target defect. Web-first locator assertions retry and preserve useful expected-versus-actual context, unlike immediate boolean checks on extracted text. Prefer one decisive outcome plus a few risk-driven details over asserting every incidental DOM node.

Q: How do you write a reliable negative assertion?

Define what absence means before choosing toBeHidden, toHaveCount(0), or an API-level rejection. A locator can be hidden because it never rendered, disappeared correctly, or the entire page failed, so pair absence with positive evidence that the relevant state loaded. For permissions, checking a forbidden response or inaccessible route is stronger than only hiding a button.

Q: When should you use soft assertions?

Soft assertions are appropriate when several independent observations should be collected before ending the test, such as a profile summary audit. They are dangerous around preconditions because execution continues after failure and later actions may produce noise. Check test.info().errors before a destructive next phase if the collected results determine whether continuing is safe.

Q: How do you verify a file download?

Register the download event before the click, then inspect the suggested filename and save or stream the artifact to a test-owned location. Content, MIME type, row count, or checksum carries more value than confirming that some download began. Parallel workers need collision-free paths and cleanup limited to files they created.

import { test, expect } from '@playwright/test';

test('downloads the account export', async ({ page }) => {
  await page.setContent(`
    <a download='accounts.csv'
       href='data:text/csv,account%2Cstatus%0AA-17%2Cactive'>Export accounts</a>
  `);

  const downloadPromise = page.waitForEvent('download');
  await page.getByRole('link', { name: 'Export accounts' }).click();
  const download = await downloadPromise;

  expect(download.suggestedFilename()).toBe('accounts.csv');
});

Save it as tests/download.spec.ts and run npx playwright test tests/download.spec.ts.

Q: How would you include accessibility in the exercise?

Use accessible roles and names so the test follows the same semantic surface as assistive technology. Add focused checks for keyboard reachability, focus movement, form labels, error association, and critical announcements where those risks exist. Automated rules can find many violations, but they do not replace keyboard use, screen-reader exploration, or product judgment.

5. TypeScript and Test Design Questions

Q: How should test data be typed?

Model only valid domain states where possible, using required fields for true invariants and explicit optional fields for legitimate absence. Literal unions can prevent impossible values such as an unsupported account status, while builder functions should expose meaningful defaults without hiding scenario intent. Avoid casting unknown payloads directly because a compile-time assertion does not validate runtime JSON.

Q: What belongs in a page object?

A page or component object should group cohesive user operations and stable semantic regions. Scenario-specific expectations usually remain in the test so negative paths and alternative outcomes stay visible. Wrapping every click or fill call adds indirection without creating a domain boundary and often weakens Playwright's native error messages.

Q: How do typed fixtures improve a suite?

Fixtures make setup dependencies, scope, and teardown explicit while preserving type information at the test call site. Test-scoped fixtures fit mutable scenario objects, whereas worker scope is suitable only for resources designed to be safely shared. The use callback marks the handoff point, and cleanup after it must tolerate failures from the test body.

import { test as base, expect, type Page } from '@playwright/test';

type AppFixtures = {
  accountPage: Page;
};

const test = base.extend<AppFixtures>({
  accountPage: async ({ page }, use) => {
    await page.setContent('<main><h1>Account A-17</h1></main>');
    await use(page);
  }
});

test('shows the fixture-owned account', async ({ accountPage }) => {
  await expect(accountPage.getByRole('heading', { name: 'Account A-17' })).toBeVisible();
});

Run npx playwright test tests/account-fixture.spec.ts to verify the fixture and test together. Deepen this topic with Playwright TypeScript fixture interview questions.

Q: Should a helper return a Locator or extracted text?

Return a Locator when callers need Playwright's fresh DOM resolution, auto-waiting, or multiple assertion choices. Return a parsed domain value when the helper intentionally crosses from browser representation into business logic and can define validation clearly. Naming should reveal that boundary, such as totalLabel() for a locator versus readInvoiceTotal() for a number.

Q: When should you introduce an abstraction during live coding?

Wait until one complete scenario runs and a repeated responsibility has become visible. Extract the smallest cohesive unit, rerun the test, and explain what change the new boundary localizes. Premature factories, base classes, and generic utilities consume interview time while making an unfinished solution harder to inspect.

6. Authentication, Data, and Isolation

Q: How do you reuse authentication safely?

Create storage state through a controlled setup project or API login, then load it only for tests whose users may safely share that state. Accounts that mutate server data still need unique records or dedicated identities because isolated browser contexts do not isolate the backend. Never commit session cookies or tokens, and regenerate state when its expiry or environment changes.

Q: How do you generate parallel-safe test data?

Combine a run identifier, worker index, and random or monotonic suffix when the product permits those characters. Record the generated business key in logs or attachments so a failure can be traced and cleaned precisely. Randomness prevents collisions but does not replace deterministic assertions or ownership metadata.

Q: Where should cleanup happen?

Place resource cleanup in fixture teardown or a finally block that runs after the owning test, using an API when UI deletion is not under examination. Deletion must target exact IDs created by that case and tolerate partially completed setup. Broad environment cleanup can erase another worker's evidence and is unacceptable in shared systems.

Q: What changes when tests run in parallel?

Shared mutable accounts, fixed filenames, static variables, and order assumptions become visible failure sources. Each worker needs independent browser state and owned business data, while environment capacity may require a deliberate worker cap. Increase concurrency only after measuring server limits and checking that reports, ports, and artifacts do not collide.

Q: When is serial mode justified?

Serial execution is reasonable for a genuinely ordered workflow whose intermediate states are the subject of the test, but the dependency should be explicit and rare. It should not conceal poor setup APIs, expensive reusable logins, or tests that mutate the same record accidentally. Prefer one test containing the ordered journey when later steps have no independent meaning after an earlier failure.

7. API and Network Pair Programming Questions

Q: How do you use Playwright's request fixture?

Use the APIRequestContext supplied as request to create prerequisites, exercise service behavior, or verify server-side outcomes. Assert status and a focused response contract, then retain IDs needed for browser navigation or cleanup. Keep credentials and base URLs in configuration so the test does not embed secrets or environment-specific hosts.

Q: When should you call the API instead of using the UI?

Use the API for setup when the setup journey is not the behavior being evaluated and direct creation is supported. Keep the UI for the action or outcome whose integration risk matters, such as permission-driven controls or client validation. This split reduces runtime while preserving the one browser boundary the scenario intends to prove.

Q: How do you mock an API response with page.route?

Register the route before navigation or the triggering action, match the narrowest useful URL, and fulfill a schema-valid response. Assert that the application renders or handles the mocked condition, not merely that the route callback executed. Unroute or rely on a fresh context so the mock cannot leak into unrelated cases.

import { test, expect } from '@playwright/test';

test('renders a fulfilled orders response', async ({ page }) => {
  await page.route('https://app.example.test/**', async route => {
    const path = new URL(route.request().url()).pathname;
    if (path === '/api/orders') {
      await route.fulfill({ json: [{ id: 'O-42', status: 'ready' }] });
      return;
    }
    await route.fulfill({
      contentType: 'text/html',
      body: `
        <button>Load orders</button><output></output>
        <script>
          document.querySelector('button').onclick = async () => {
            const orders = await fetch('/api/orders').then(r => r.json());
            document.querySelector('output').textContent = orders[0].id;
          };
        </script>
      `
    });
  });

  await page.goto('https://app.example.test/orders');
  await page.getByRole('button', { name: 'Load orders' }).click();
  await expect(page.getByText('O-42')).toBeVisible();
});

Verify the result with npx playwright test tests/network-mock.spec.ts. Practice deeper service scenarios with Playwright API testing interview questions.

Q: Which network failures should a candidate demonstrate?

Choose one behaviorally meaningful failure such as 401, 429, 500, a delayed response, or a malformed payload. Verify the product's recovery path, including a useful message, retry control, preserved user input, or disabled unsafe action. Aborting every request proves little because it can prevent the application shell from loading and obscure the targeted boundary.

Q: How do you wait for a specific response?

Create page.waitForResponse with a predicate that checks URL and method before triggering the action. Await the captured response, assert its status or selected payload, and still verify the user-visible result when this is an end-to-end test. A broad substring match can capture analytics or preflight traffic, so predicates should encode the intended request precisely.

8. Debugging and Flakiness Questions

Q: How do you triage a timeout during pairing?

Read the error's waiting condition, target locator, and elapsed stage before changing timeouts. Inspect whether the page reached the expected route, whether the request completed, and whether the element is absent, duplicated, covered, or disabled. Fix the earliest false assumption, then rerun the narrow test enough times to challenge the diagnosis.

Q: What does a Playwright trace tell you?

Trace Viewer correlates actions, DOM snapshots, network activity, console output, timing, and attachments across the failed run. Use it to find the first divergence rather than focusing only on the final assertion. Configure focused retention because traces can contain tokens, personal data, and application source that require controlled access.

Q: Are retries a valid flakiness solution?

Retries can preserve delivery while collecting repeat evidence, but a pass on retry remains a flaky result. Compare first-run and retry artifacts, classify the signature, assign ownership, and remove the causal race or shared state. High retry counts inflate runtime and can normalize real product instability.

Q: How do you investigate an intermittently missing locator?

Check whether the locator is semantically correct and unique in every UI state, including loading, empty, localized, and responsive variants. Correlate DOM snapshots with the network call or state transition that should produce the element. Adding a longer timeout only helps when the condition is valid but legitimately slower, not when the wrong screen or data loaded.

Q: How do you test time-dependent behavior?

Prefer a product-supported clock seam, injected date service, or controlled backend state over waiting for real minutes to pass. Freeze or advance time only within the test's ownership boundary, then verify calendar, timezone, daylight-saving, and expiry semantics explicitly. Real-time waits make feedback slow and leave boundary failures dependent on when CI happens to run.

For senior incident drills, work through the Playwright debugging interview guide and practice explaining the evidence chain without guessing.

9. Refactoring, Coverage, and CI Questions

Q: How do you refactor a passing exercise safely?

Keep the green test as a behavioral guard, make one structural change, and rerun immediately. Extract names that express domain intent while leaving Playwright calls visible enough for useful traces and stack frames. If the refactor requires flags for unrelated flows, the boundary is probably too broad.

Q: Where can a discriminated union help test code?

A union can model mutually exclusive states such as card, bank transfer, or invoice payment without optional fields that form invalid combinations. A switch on the discriminant lets TypeScript flag an unhandled new variant during type checking. This technique is valuable for data builders and expected outcomes, but it should not mirror unstable presentation details.

Q: How do you design a small test matrix?

Select dimensions tied to risk, such as role, locale, browser engine, or account state, then use pairwise or representative combinations when a Cartesian product adds little confidence. Keep case names and data readable in reports, and ensure each row has an independent oracle. A loop is appropriate for symmetric cases, while materially different behavior deserves separate tests.

Q: What performance evidence can Playwright provide?

Playwright can capture request timing, browser performance entries, screenshots, and traces for diagnostic checks. It is not a substitute for a controlled load-testing tool because one browser cannot model production concurrency or stable percentile distributions. Use browser measurements for budgets and regression signals only after defining environment, warmup, sampling, and noise handling.

Q: What should a practical Playwright CI configuration include?

Use a lockfile install, explicit browser installation, bounded workers, CI-only retries, and artifacts that survive failures. Type-check separately because Playwright transpiles TypeScript but does not perform complete type checking. Keep the same primary test command locally and in CI so environmental differences remain visible.

import { defineConfig } from '@playwright/test';

export default defineConfig({
  testDir: './tests',
  fullyParallel: true,
  retries: process.env.CI ? 1 : 0,
  workers: process.env.CI ? 2 : undefined,
  reporter: [['html', { open: 'never' }]],
  use: {
    screenshot: 'only-on-failure',
    trace: 'on-first-retry'
  }
});

Save this as playwright.config.ts, run npx tsc --noEmit, then verify execution with npx playwright test.

10. Advanced playwright typescript pair programming interview questions

Q: What do you say when a reviewer suggests force: true?

Ask which actionability check is blocking and whether a real user could perform the same action. Force may be legitimate for a deliberate low-level interaction, but it often hides an overlay, animation, disabled control, or incorrect target. Inspect the obstruction first and retain force only when the product contract explicitly makes normal actionability irrelevant.

Q: How would you automate CAPTCHA or one-time passcodes?

Do not defeat production anti-bot controls in an end-to-end suite. Request a test-environment bypass, seeded token, controllable identity-provider stub, or approved API that preserves the application's side of the contract. Keep a small separately governed integration check for the real provider if the organization owns permission and safe test identities.

Q: How do you test a third-party payment flow?

Cover the product-owned checkout state machine with the provider's sandbox, contract tests, and deterministic webhook fixtures. Verify idempotency, declined payments, delayed confirmation, duplicate callbacks, and user recovery without entering real financial credentials. Limit full browser journeys to critical integration paths because vendor UI and availability are outside the team's direct control.

Q: How do you explain coverage when time is almost over?

Name the behavior the current test proves, the assumptions it depends on, and the highest-risk missing case. Prioritize one negative path or boundary rather than listing every theoretical permutation. Distinguish what belongs at unit, API, contract, and browser layers so the interviewer sees a coverage strategy instead of an oversized UI backlog.

Q: How should you finish the pair programming session?

Run the narrow test and any relevant type check, then read the result aloud. Summarize the requirement, key design choices, unresolved risks, and the next production-hardening step in under a minute. Leave the code in a coherent state even if optional extensions remain, because a small verified solution is stronger evidence than several half-built abstractions.

How Interviewers Grade Your Answers

Interviewers usually grade the whole working system, not isolated API recall. A candidate who produces a short, deterministic test and can explain its limits often scores above someone who writes more code but never runs it.

Use a three-part answer when discussing a design choice: state the decision, connect it to the observed risk, and name the evidence that would validate it. That structure keeps responses concrete without sounding memorized. Interviewers also watch whether you can change direction after new information while maintaining a stable mental model of the code.

Common Mistakes

• Coding before confirming the expected outcome, available test seams, or ownership of external systems.
• Choosing nth(), first(), or a long CSS chain when the ambiguity should be resolved through semantics or scope.
• Replacing a race with waitForTimeout, a larger timeout, or multiple retries without identifying the failed condition.
• Building page objects, factories, and utilities before one representative scenario works.
• Sharing mutable users or records across workers, then treating parallel failures as browser flakiness.
• Asserting only that an element exists instead of proving the business outcome or rejected state.
• Mocking so much of the application that the browser test no longer exercises a meaningful integration.
• Ignoring TypeScript errors because the Playwright runner can still transpile and execute the file.
• Treating interviewer feedback as interruption rather than additional evidence about the problem.
• Ending when the code looks complete without running it, reading the failure, or explaining remaining risk.

Conclusion

The best preparation for playwright typescript pair programming interview questions is repeated, timed practice with runnable code. Clarify first, automate one trustworthy path, use semantic locators and observable waits, keep state isolated, and narrate the trade-offs that shape the solution.

Choose five prompts from this guide and solve them in a shared editor while recording your explanation. Then use QAJobFit practice for another interview round or upload your resume to align preparation with the role you want.

Interview Questions and Answers

Frequently Asked Questions

Related Guides

• Cypress TypeScript Pair Programming Interview Questions (2026)
• Playwright Fixtures Interview Questions for TypeScript Testers (2026)
• Principal SDET Java Pair Programming Interview Questions (2026)
• QA Lead API Pair Programming Interview Questions (2026)
• Test Architect TypeScript Pair Programming Interview Round (2026)
• TypeScript Coding Interview Questions for Playwright Testers (2026)