Playwright Interview Questions for 2 Years Experience: 35 Practical Questions and Answers

Leave a Comment / Uncategorized / By

Introduction: What Companies Expect From a 2-Year Playwright Candidate

Candidates with around two years of automation experience are usually expected to do more than explain what Playwright is.

Interviewers want evidence that you can build, maintain, debug, and improve an automation framework.

That means your preparation for Playwright interview questions for 2 years experience should focus on practical decisions.

You should be comfortable explaining:

At the two-year level, interviewers may also ask you to write code while explaining your approach.

A good answer should follow this pattern:

Problem → Investigation → Solution → Why the solution is reliable → Possible trade-off

1. Playwright Fundamentals Candidates Should Know

Q1. What is Playwright, and why did you use it in your project?

Interview-Ready Answer

Playwright is a browser automation and end-to-end testing framework. I use it to automate web applications across Chromium, Firefox, and WebKit.

Its useful features include auto-waiting, web-first assertions, BrowserContext isolation, parallel execution, API testing, network interception, authentication state, tracing, and built-in reporting.

Practical Explanation

At two years of experience, don’t stop at the definition.

Explain why your project used Playwright.

For example:

“Our application had dynamic React components. Playwright’s locator and auto-waiting capabilities helped us reduce synchronization problems compared with our previous approach.”

Interview Tip

Always connect the tool to a real project problem.

Q2. Explain Browser, BrowserContext, and Page.

Interview-Ready Answer

A Browser represents the browser process. A BrowserContext is an isolated browser session, and a Page represents a browser tab.

The relationship is:

Browser → BrowserContext → Page

TypeScript Example

const browser = await chromium.launch();

const context = await browser.newContext();

const page = await context.newPage();

await page.goto(‘https://example.com’);

Practical Explanation

Contexts are particularly useful when testing different users.

const adminContext = await browser.newContext();

const customerContext = await browser.newContext();

const adminPage = await adminContext.newPage();

const customerPage = await customerContext.newPage();

Each context has its own cookies and storage.

Interview Tip

Expect a follow-up question: “Why not create a separate browser for every user?”

2. Locators, Assertions, and Auto-Waiting

Q3. Which locator strategy do you use in your project?

Interview-Ready Answer

I prefer stable, user-facing locators such as getByRole() and getByLabel(). I use getByTestId() when the application provides a stable test contract. CSS or XPath is used when it provides a suitable stable selector.

Example

await page.getByRole(‘button’, {

  name: ‘Submit’

}).click();

await page.getByLabel(‘Email’)

  .fill(‘qa@example.com’);

Practical Explanation

I avoid selectors based on generated CSS classes or deep DOM structures because they can break when developers change the UI implementation.

Interview Tip

Don’t say “XPath should never be used.” Explain the difference between a stable selector and a brittle selector.

Q4. What happens when a locator matches multiple elements?

Interview-Ready Answer

If an action expects a single element but the locator matches multiple elements, Playwright can raise a strict-mode violation.

I first make the locator unique instead of immediately selecting an element by position.

Example

const order = page

  .getByRole(‘row’)

  .filter({

    hasText: ‘ORD-1001’

  });

await order.getByRole(‘button’, {

  name: ‘Delete’

}).click();

Interview Tip

Explain filter() and locator chaining before mentioning nth().

Q5. How do you handle dynamic elements?

Interview-Ready Answer

I identify a stable property or relationship rather than depending on dynamic IDs or changing positions.

For example:

const product = page

  .getByRole(‘article’)

  .filter({

    hasText: ‘Laptop Pro’

  });

await product.getByRole(‘button’, {

  name: ‘Add to Cart’

}).click();

Practical Explanation

If the product ID changes on every test run, I would locate the product using stable business text, a test ID, or a relationship between elements.

Interview Tip

Mention that the locator should describe what the user cares about, not how the DOM happens to be implemented.

Q6. What is auto-waiting in Playwright?

Interview-Ready Answer

Playwright automatically waits for relevant actionability conditions before performing actions and retries web-first assertions until the expected condition is satisfied or the timeout is reached.

Example

await page.getByRole(‘button’, {

  name: ‘Checkout’

}).click();

await expect(

  page.getByRole(‘heading’, {

    name: ‘Order Confirmation’

  })

).toBeVisible();

Interview Tip

Auto-waiting does not mean every application condition is automatically understood. You still need appropriate assertions for business state.

Q7. Why should you avoid waitForTimeout()?

Interview-Ready Answer

Fixed waits introduce unnecessary delays and don’t guarantee that the application is actually ready.

Avoid:

await page.waitForTimeout(5000);

Prefer:

await expect(

  page.getByText(‘Payment successful’)

).toBeVisible();

Interview Tip

A strong answer is:

“I synchronize with application state instead of time.”

3. Browser, Context, Page, and Configuration

Q8. How do you configure a base URL?

Interview-Ready Answer

I configure it centrally so tests can use relative URLs.

import { defineConfig } from ‘@playwright/test’;

export default defineConfig({

  use: {

    baseURL: ‘https://qa.example.com’

  }

});

Then:

await page.goto(‘/login’);

Practical Explanation

For multiple environments, the value can come from environment variables.

baseURL:

  process.env.BASE_URL ??

  ‘https://qa.example.com’

Interview Tip

Do not hardcode environment-specific URLs throughout the test suite.

Q9. How do you customize browser or context settings?

Interview-Ready Answer

I use Playwright configuration or browser.newContext() depending on whether the setting is global/project-level or test-specific.

const context = await browser.newContext({

  viewport: {

    width: 1440,

    height: 900

  },

  locale: ‘en-US’

});

Interview Tip

Be prepared to discuss viewport, locale, timezone, permissions, storage state, and device projects.

4. Page Object Model, Fixtures, Hooks, and Framework Questions

Q10. How do you implement Page Object Model in Playwright?

Interview-Ready Answer

I encapsulate page locators and business actions inside classes while keeping test cases focused on scenarios.

import { Page } from ‘@playwright/test’;

export class LoginPage {

  constructor(private page: Page) {}

  private username =

    this.page.getByLabel(‘Username’);

  private password =

    this.page.getByLabel(‘Password’);

  private loginButton =

    this.page.getByRole(‘button’, {

      name: ‘Login’

    });

  async login(

    username: string,

    password: string

  ) {

    await this.username.fill(username);

    await this.password.fill(password);

    await this.loginButton.click();

  }

}

Test

const loginPage = new LoginPage(page);

await loginPage.login(

  ‘john’,

  ‘secret’

);

Interview Tip

Don’t create a giant POM containing every application operation. Keep classes cohesive.

Q11. What is the difference between POM and fixtures?

Interview-Ready Answer

POM organizes page behavior and locators. Fixtures provide reusable dependencies and setup/teardown.

For example, a LoginPage is a Page Object, while a fixture can automatically create a LoginPage instance for every test.

Interview Tip

At two years, you should understand not only how to use fixtures but also why they reduce duplicate setup.

Q12. Which hooks do you use?

Interview-Ready Answer

Common hooks include beforeEach, afterEach, beforeAll, and afterAll.

test.beforeEach(async ({ page }) => {

  await page.goto(‘/dashboard’);

});

test.afterEach(async ({ page }) => {

  // cleanup if required

});

Practical Explanation

I avoid putting excessive setup into beforeAll when it creates shared state that can make tests dependent on each other.

Interview Tip

Mention test isolation.

5. Authentication and storageState

Q13. How do you reuse login authentication?

Interview-Ready Answer

I can authenticate once and save the browser context’s storage state, then reuse it in tests.

await page.context().storageState({

  path: ‘playwright/.auth/user.json’

});

Configuration:

use: {

  storageState:

    ‘playwright/.auth/user.json’

}

Practical Explanation

This avoids repeating the UI login flow in every test.

However, the login test itself should still verify the actual authentication functionality.

Interview Tip

Never commit authentication state containing sensitive cookies or tokens.

Q14. How would you test different user roles?

Interview-Ready Answer

I would maintain separate authentication states or contexts.

const adminContext =

  await browser.newContext({

    storageState: ‘admin.json’

  });

const userContext =

  await browser.newContext({

    storageState: ‘user.json’

  });

Interview Tip

If users modify shared server-side data, use separate accounts or carefully isolated test data.

6. API Testing and Network Mocking

Q15. How do you perform API testing in Playwright?

Interview-Ready Answer

Playwright provides an API request fixture for sending HTTP requests.

test(‘create customer’, async ({

  request

}) => {

  const response =

    await request.post(‘/api/customers’, {

      data: {

        name: ‘John’,

        email: ‘john@example.com’

      }

    });

  expect(response.ok()).toBeTruthy();

  const body = await response.json();

  expect(body.name).toBe(‘John’);

});

Interview Tip

Explain how API testing fits into your overall framework rather than treating it as a separate tool.

Q16. Why would you create test data using an API?

Interview-Ready Answer

API-based setup is often faster and less fragile than navigating through multiple UI screens.

For example, before testing an order page:

const response =

  await request.post(‘/api/orders’, {

    data: {

      productId: 101,

      quantity: 2

    }

  });

const order = await response.json();

await page.goto(`/orders/${order.id}`);

Practical Explanation

This lets the test focus on validating the UI rather than spending most of its time creating prerequisite data.

Interview Tip

Use API setup carefully. The API should be stable and the test should still validate the appropriate application layer.

Q17. How do you mock an API response?

Interview-Ready Answer

Use request interception.

await page.route(

  ‘**/api/products’,

  async route => {

    await route.fulfill({

      status: 200,

      contentType: ‘application/json’,

      body: JSON.stringify({

        products: [

          {

            id: 1,

            name: ‘Laptop’

          }

        ]

      })

    });

  }

);

Interview Tip

Mock external or unpredictable dependencies when deterministic behavior is important, but don’t mock everything.

7. Test Data and Parameterization

Q18. How do you create data-driven tests?

Interview-Ready Answer

I separate test data from test logic and iterate over a controlled dataset.

const users = [

  {

    username: ‘admin’,

    role: ‘Admin’

  },

  {

    username: ‘customer’,

    role: ‘Customer’

  }

];

for (const user of users) {

  test(`login as ${user.role}`, async ({

    page

  }) => {

    await page.goto(‘/login’);

    await page.getByLabel(‘Username’)

      .fill(user.username);

  });

}

Interview Tip

For larger frameworks, consider typed test-data factories rather than huge hardcoded arrays.

Q19. How do you prevent test-data conflicts?

Interview-Ready Answer

I generate unique data or isolate data by test or worker.

const uniqueEmail =

  `qa-${Date.now()}-${testInfo.workerIndex}@example.com`;

Practical Explanation

Parallel tests should not accidentally modify the same account, order, file, or database record.

Interview Tip

Talk about both data creation and cleanup.

8. Parallel Execution, Retries, and Flaky Tests

Q20. How do you execute tests in parallel?

Interview-Ready Answer

Playwright Test supports workers.

npx playwright test –workers=4

Practical Explanation

Parallel execution reduces total time, but too many workers can overload the application, database, or CI machine.

Interview Tip

More workers do not automatically mean better performance.

Q21. What is test sharding?

Interview-Ready Answer

Sharding divides the test suite across multiple CI jobs.

npx playwright test –shard=1/4

If four CI jobs run shards 1 through 4, the suite can be distributed across those jobs.

Interview Tip

Workers provide concurrency inside a job. Sharding distributes work across jobs.

Q22. How do you handle flaky tests?

Interview-Ready Answer

I first identify the root cause.

Typical causes include:

  • Unstable locators
  • Race conditions
  • Poor synchronization
  • Shared test data
  • External services
  • Application defects
  • Resource limitations
  • Parallel execution conflicts

Retries can help with transient failures, but they should not replace root-cause analysis.

Interview Tip

Give one example from your project when answering this question.

9. Debugging and Real-World Failure Scenarios

Q23. A test passes locally but fails in CI. What do you check?

Interview-Ready Answer

I compare:

  1. Node version
  2. Browser version
  3. Operating system
  4. Environment variables
  5. Authentication
  6. Test data
  7. Network access
  8. Worker count
  9. CPU and memory
  10. Time zone and locale

Then I inspect the CI trace, screenshot, video, and logs.

Interview Tip

Never say “increase timeout” as your first solution.

Q24. A locator works locally but fails in CI. What could cause it?

Interview-Ready Answer

The UI may render differently because of viewport size, timing, feature flags, environment data, localization, or browser differences.

I would inspect the trace and confirm what DOM state existed at failure time.

Interview Tip

Separate locator problems from environment problems.

Q25. A test becomes flaky after parallelization. What do you investigate?

Interview-Ready Answer

I check for shared state.

Examples:

  • Same test account
  • Same order ID
  • Same database record
  • Same file
  • Shared global variable
  • Shared application session

Then I isolate the data or change the fixture scope.

Interview Tip

This is a common practical question for two-year candidates.

Q26. What is your debugging workflow for a timeout?

Interview-Ready Answer

I determine what timed out first.

Then I check:

  • Was the locator correct?
  • Was the page correct?
  • Was the element inside an iframe?
  • Was the element rendered?
  • Was it enabled?
  • Was an overlay blocking it?
  • Was backend data available?
  • Did the test navigate to the expected URL?

I then inspect the Trace Viewer.

Interview Tip

Show a structured investigation rather than guessing.

10. Screenshots, Traces, Videos, and Reporting

Q27. How do you configure debugging artifacts?

Interview-Ready Answer

I typically configure diagnostics to be retained for failures.

use: {

  screenshot: ‘only-on-failure’,

  video: ‘retain-on-failure’,

  trace: ‘retain-on-failure’

}

Explanation

These artifacts help determine what happened without rerunning the test repeatedly.

Interview Tip

Trace Viewer is particularly valuable for CI failures because it captures the execution flow.

Q28. How do you analyze a CI trace?

Interview-Ready Answer

I look at the failed action, locator resolution, page state, screenshots, network activity, and timing around the failure.

The goal is to determine whether the root cause is:

Test code → Locator → Application → Data → Environment → Infrastructure

11. CI/CD, GitHub Actions, and Docker

Q29. What does a basic Playwright CI pipeline contain?

Interview-Ready Answer

A basic pipeline should:

  1. Checkout the repository.
  2. Install the correct Node version.
  3. Run npm ci.
  4. Install Playwright browsers and dependencies.
  5. Set environment variables/secrets.
  6. Run tests.
  7. Upload reports and diagnostics.

Example

steps:

  – uses: actions/checkout@v4

  – uses: actions/setup-node@v4

    with:

      node-version: 20

      cache: npm

  – run: npm ci

  – run: npx playwright install –with-deps

  – run: npx playwright test

  – uses: actions/upload-artifact@v4

    if: always()

    with:

      name: playwright-report

      path: playwright-report/

Interview Tip

Explain why artifact upload should run even after test failure.

Q30. How do you manage environment-specific configuration?

Interview-Ready Answer

I use environment variables or configuration files rather than embedding URLs and credentials in tests.

const baseURL =

  process.env.BASE_URL ??

  ‘https://qa.example.com’;

Interview Tip

Credentials belong in secret management systems, not source code.

Q31. How do you run Playwright in Docker?

Interview-Ready Answer

I use a Playwright-compatible container image or a custom image containing Node, browser binaries, and required system dependencies.

The important point is that the container must have compatible browser dependencies and the project dependencies installed.

Interview Tip

If Docker tests fail, check browser dependencies, permissions, memory, fonts, file paths, and environment variables.

12. Playwright vs Selenium Practical Questions

Q32. Why might your team choose Playwright over Selenium?

Interview-Ready Answer

Playwright provides built-in auto-waiting, BrowserContext isolation, modern locator APIs, network interception, tracing, API testing, and a tightly integrated test runner.

However, the choice depends on project requirements, existing infrastructure, language preferences, browser support, and team expertise.

Interview Tip

Never claim Playwright is universally better.

Q33. How is synchronization different?

Interview-Ready Answer

Selenium commonly requires explicit or implicit wait strategies to synchronize with dynamic applications.

Playwright automatically waits for many actionability conditions and provides retrying assertions.

Interview Tip

Explain that good Playwright tests still require deliberate synchronization with business state.

Q34. How would you migrate a Selenium test to Playwright?

Interview-Ready Answer

I would not translate commands one-to-one.

I would:

  • Identify business scenarios
  • Replace brittle selectors
  • Introduce Playwright locators
  • Remove unnecessary explicit waits
  • Create POMs
  • Add fixtures
  • Rework authentication
  • Integrate API setup
  • Configure CI
  • Compare stability and execution time

Interview Tip

Migration is an opportunity to improve framework design, not just replace APIs.

13. Real-World Project-Based Questions

Q35. Explain a Playwright framework you have worked on.

Interview-Ready Answer

A strong answer should describe:

Tests

  ↓

Page Objects / Components

  ↓

Fixtures

  ↓

Utilities / API Clients

  ↓

Application

Then explain:

  • How authentication works
  • How test data is created
  • How environments are configured
  • How tests run in CI
  • How failures are diagnosed
  • How parallel execution is controlled

Interview Tip

Don’t just list folders. Explain responsibilities.

Q36. How would you reduce a regression suite that takes three hours?

Interview-Ready Answer

I would first measure where the time is spent.

Then I would evaluate:

  • Parallel workers
  • Sharding
  • Duplicate tests
  • Repeated UI setup
  • API-based data creation
  • Authentication reuse
  • Unnecessary browser launches
  • Slow external dependencies

Interview Tip

Never blindly increase workers. The application or database may become the bottleneck.

Q37. A login test works manually but fails in automation. How do you debug it?

Interview-Ready Answer

I would check:

  • Correct URL
  • Locator accuracy
  • Input values
  • Authentication redirects
  • Cookies
  • Network requests
  • CAPTCHA or MFA
  • Environment configuration
  • Browser permissions
  • Timing

I would use a trace and inspect the actual page state.

Interview Tip

Mention security controls such as CAPTCHA and MFA rather than assuming the locator is wrong.

Q38. Your team asks you to automate every test case. What would you say?

Interview-Ready Answer

I would prioritize automation based on risk, repeatability, business value, stability, and execution frequency.

Not every test provides equal automation value.

Interview Tip

This answer demonstrates engineering maturity.

14. Common Mistakes Candidates With 2 Years Experience Make

1. Giving textbook answers

Instead of:

“Playwright supports auto-waiting.”

Say:

“We used locator-based actions and web-first assertions to remove fixed waits from our checkout tests.”

2. Using waitForTimeout() everywhere

Explain the actual synchronization condition.

3. Overusing nth()

Make the locator unique using business context.

4. Creating huge Page Objects

Keep POMs modular and focused.

5. Treating retries as a flaky-test solution

Retries are not root-cause analysis.

6. Ignoring test-data isolation

Parallel tests need independent data.

7. Hardcoding credentials

Use environment variables and CI secret stores.

8. Saying Playwright is always better than Selenium

Discuss trade-offs objectively.

9. Not knowing CI

At two years of experience, you should understand how your tests run outside your laptop.

10. Memorizing syntax without understanding failures

Interviewers frequently ask:

“What would you do if this test failed?”

Be ready to answer.

15. Playwright Interview Preparation Checklist for 2 Years Experience

Core

Locators

  • getByRole()
  • getByLabel()
  • getByText()
  • getByPlaceholder()
  • getByTestId()
  • locator()
  • CSS
  • XPath
  • filter()
  • Chaining
  • Strict mode

Synchronization

  • Auto-waiting
  • Actionability
  • Web-first assertions
  • Timeouts
  • Dynamic elements

Framework

Authentication

  • Login
  • storageState
  • Multiple roles
  • Session isolation

API

Execution

  • Workers
  • Retries
  • Sharding
  • Test-data isolation
  • Cross-browser projects

CI/CD

  • GitHub Actions
  • Docker
  • Browser installation
  • Secrets
  • Environment variables
  • Artifacts
  • Reports

Debugging

  • Screenshots
  • Videos
  • Trace Viewer
  • Logs
  • CI troubleshooting
  • Flaky-test analysis

FAQs: Playwright Interview Questions for 2 Years Experience

What are the most important Playwright interview questions for 2 years experience?

Focus on locators, auto-waiting, BrowserContext, POM, fixtures, authentication, API testing, test-data management, parallel execution, debugging, and CI/CD.

Do two-year Playwright candidates need to know API testing?

Yes. At this experience level, knowing how to use APIs for validation and test-data setup can significantly strengthen your interview profile.

Should I know Page Object Model for a Playwright interview?

Yes. You should understand how to create maintainable Page Objects and when to use fixtures instead of putting everything into POM classes.

What coding questions can be asked?

You may be asked to write login automation, dynamic locators, table validation, API requests, authentication setup, file uploads, popup handling, or reusable Page Objects.

What scenario questions should I prepare?

Prepare for CI-only failures, strict-mode violations, dynamic elements, authentication expiration, parallel data conflicts, flaky tests, slow suites, API failures, and trace analysis.

Is Selenium experience useful for Playwright interviews?

Absolutely. Selenium experience gives you a strong foundation in browser automation. However, you should understand Playwright-specific concepts such as BrowserContext, locators, auto-waiting, fixtures, storage state, tracing, and Playwright Test.

Leave a Comment

Your email address will not be published. Required fields are marked *