Why Playwright Eliminates More Candidates Than They Expect

Interview Insights · Playwright

Why Playwright Eliminates More Candidates Than They Expect

SECTION 01The waiting mistake that ends Playwright rounds early

The first thing I watch in a Playwright exercise is what you do when the page is slow. Many candidates come from older Selenium habits, where adding a sleep felt like a fix. In Playwright that habit tells me you have not understood the tool. Playwright actions such as click() and fill() already wait for the element to be attached, visible, stable, enabled and able to receive events. Web-first assertions such as toBeVisible() and toHaveText() keep retrying until they pass or time out.

So when a candidate writes await page.waitForTimeout(5000), I hear two things. First, the test will be slow on a fast day. Second, it will still fail on a slow day. The table below shows the waiting tools I expect you to know and when each one makes sense.

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

test('order is saved', async ({ page }) => {
  await page.goto('/orders/new');
  await page.click('#save');
  await page.waitForTimeout(5000); // hope the spinner is gone
  const msg = await page.locator('.toast').textContent();
  expect(msg).toBe('Order saved');   // no retry: reads once
});

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

test('order is saved', async ({ page }) => {
  await page.goto('/orders/new');

  const saved = page.waitForResponse(
    r => r.url().includes('/api/orders') && r.request().method() === 'POST'
  );
  await page.getByRole('button', { name: 'Save' }).click();
  expect((await saved).ok()).toBeTruthy();

  // web-first assertion: retries until text matches or times out
  await expect(page.getByRole('status')).toHaveText('Order saved');
});

Look at the last line of the weak version. textContent() reads the value once and hands a plain string to expect, so there is no retry at all. That single detail separates people who used Playwright from people who copied a snippet. When I see a candidate switch to await expect(locator).toHaveText(...) without being told, I relax.

SECTION 02Locators that survive a redesign, and locators that do not

The second filter is how you find elements. I often hand over a small form and ask the candidate to automate it. Weak candidates open DevTools, copy the generated selector and paste something like div:nth-child(3) > button.btn-primary. It works today and breaks the next time a designer moves a div.

Playwright's own guidance pushes user-facing locators: getByRole, getByLabel, getByPlaceholder, getByText and, when the team agrees on it, getByTestId. These locate elements the way a real user or a screen reader would. They also make the test easier to read in a code review, which is what I am really judging.

await page.locator('//div[2]/form/div[3]/input').fill('asha@test.com');
await page.locator('div.row > div:nth-child(2) > input').fill('Secret#1');
await page.locator('button.btn.btn-primary.mt-3').click();

// Three selectors tied to layout and styling classes.
// A new wrapper div or a CSS rename breaks all three.

await page.getByLabel('Email').fill('asha@test.com');
await page.getByLabel('Password').fill('Secret#1');
await page.getByRole('button', { name: 'Sign in' }).click();

// Narrowing inside a region when names repeat:
const cart = page.getByRole('region', { name: 'Cart' });
await cart.getByRole('button', { name: 'Remove' }).first().click();

// Filtering a list row by its text:
await page.getByRole('listitem')
  .filter({ hasText: 'Blue T-shirt' })
  .getByRole('button', { name: 'Add' })
  .click();

If you must use CSS, say why. 'The table cells have no roles, so I asked the developer for a data-testid and used CSS as a stop-gap' is a perfectly good answer. Interviewers do not expect perfection. They expect a reason.

SECTION 03Isolation and debugging: the filters seniors are judged on

The last two filters catch candidates who are fine at writing single tests but have never kept a suite healthy. Playwright gives each test its own browser context, which is like a fresh incognito profile. That means no shared cookies, no leaked local storage and no order dependency between tests. Candidates who log in once and expect later tests to stay logged in get confused fast.

The right pattern is to log in once in a setup project, save the authenticated state to a file with storageState, and let every test start from that file. When something still fails in CI, I expect you to reach for the trace viewer rather than adding retries and hoping.

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

export default defineConfig({
  testDir: './tests',
  retries: process.env.CI ? 1 : 0,
  use: {
    baseURL: process.env.BASE_URL,
    trace: 'on-first-retry',
  },
  projects: [
    { name: 'setup', testMatch: /auth\.setup\.ts/ },
    {
      name: 'chromium',
      use: { storageState: 'playwright/.auth/user.json' },
      dependencies: ['setup'],
    },
  ],
});

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

const authFile = 'playwright/.auth/user.json';

setup('log in once', async ({ page }) => {
  await page.goto('/login');
  await page.getByLabel('Email').fill(process.env.TEST_USER!);
  await page.getByLabel('Password').fill(process.env.TEST_PASS!);
  await page.getByRole('button', { name: 'Sign in' }).click();
  await expect(page.getByRole('heading', { name: 'Dashboard' })).toBeVisible();
  await page.context().storageState({ path: authFile });
});

// Open a saved trace locally:
// npx playwright show-trace test-results/TEST-FOLDER/trace.zip

When I ask 'a test fails only in CI, what do you do?', the answer I want starts with evidence: open the trace, look at the action log, the DOM snapshot before and after the failing step, and the network tab. Then form a guess, such as a slower API or a different viewport, and test that guess. Retries are a safety net, not a diagnosis.

SECTION 04A self-check before your Playwright interview

Run this worksheet against a small project of your own, ideally a public demo site you automated end to end. If you cannot tick an item, fix it in the project first, then practise explaining the fix out loud.

PLAYWRIGHT CODE AUDIT

[ ] Zero waitForTimeout calls (or each one has a comment explaining why)
[ ] Every assertion on page state uses await expect(locator)...
[ ] Most locators are getByRole / getByLabel / getByTestId
[ ] No test depends on another test running first
[ ] Login handled by a setup project and storageState
[ ] Test data created through API or fixtures, not long UI flows
[ ] trace configured in playwright.config.ts
[ ] Secrets read from environment variables, not hardcoded

SAY EACH ANSWER IN UNDER 60 SECONDS

1. What does Playwright check before it clicks an element?
2. Why is expect(locator).toHaveText() safer than
   expect(await locator.textContent()).toBe()?
3. What is a browser context and why does each test get one?
4. How did you handle login in your suite?
5. A test is flaky in CI. Walk me through your first 3 steps.
6. When would you use getByTestId instead of getByRole?

BUILD THIS IN A WEEKEND

App: any public practice e-commerce or todo site

Tests:
- login (setup project + storageState)
- add item to cart, assert cart count
- remove item, assert empty state message
- form validation: empty email shows an error
- one test that waits on a network response

Extras:
- run in two browsers via projects
- HTML report and trace on retry
- a short README explaining your locator choices

SECTION 05Habits that keep you past the Playwright filters

These habits are small, but each one removes a reason for an interviewer to say no.

• Say 'auto-wait' before they ask — When you write a click, mention that Playwright waits for actionability. It shows you understand the tool, not just the syntax.
• Read locators out loud — Saying 'the button whose accessible name is Save' while typing getByRole makes your intent clear and invites helpful feedback.
• Keep one test, one purpose — A test that logs in, buys, cancels and checks email is four tests. Split them, and say why splitting helps debugging.
• Know your config file — Be ready to explain every line in your playwright.config.ts. Interviewers often open it first when you share a project.
• Debug in front of them — If your live test fails, do not panic. Run it with the inspector or read the error, and narrate what you see. That is often worth more than a passing test.

SECTION 06Interview Q&A — Playwright rounds

SECTION 07Test yourself — Playwright rounds quiz

SECTION 08Frequently asked questions

SECTION 09Related reads