Real Faced Playwright with TypeScript Interview Questions & Answers for 5 to 7 Yrs Exp

Already Know Playwright + TypeScript? Get Real Project Exposure.

Work alongside experienced QA automation professionals and experience how Playwright + TypeScript projects are actually executed — including real requirements, coding, debugging, framework decisions and project challenges.

Real Project Exposure • Experienced QA Guidance • Playwright + TypeScript • Debugging • Project Execution

1. Can You Explain the Playwright Tool Architecture?

This is one of the most important questions a candidate can face because it provides an opportunity to demonstrate deeper understanding rather than simply describing Playwright as a browser automation tool.

A basic answer would be that Playwright supports Chromium, Firefox and WebKit. While technically correct, that explanation does not describe how Playwright organizes browser automation.

A stronger answer is to explain the relationship between the main Playwright objects.

Playwright Test / TypeScript Test Script
↓
 Playwright API
↓
 Browser
↓
 BrowserContext
        ↓
 ┌──────┴───────────────┐
 ↓                      ↓
 PagePage          Main Tab Popup Tab
 ↓
 Frame
 ↓
Locator
 ↓
 Element Action

Browser

The browser is the browser instance that Playwright launches or connects to. Depending on the automation requirement, Playwright can work with supported browser engines such as Chromium, Firefox and WebKit.

const browser = await chromium.launch();

BrowserContext

A BrowserContext represents an isolated browser session. Multiple contexts can exist within a browser, allowing tests to work with isolated cookies, storage and authentication state.

Browser
 │
 ├── BrowserContext 1
 │├── Page 1
 │└── Page 2
 │
 └── BrowserContext 2
├── Page 1
└── Page 2

This isolation is one of the important concepts behind Playwright test execution because separate tests can operate without necessarily sharing browser state.

Page

A Page represents a browser tab or popup within a browser context. This becomes particularly important when handling multiple windows or tabs using Playwright.

Frame

A page contains a main frame and may also contain additional frames through HTML iframe elements. Elements inside an iframe must be accessed through the appropriate frame context rather than treated as part of the main page DOM.

Locator

A locator represents how Playwright finds elements on a page. Locators are central to Playwright’s auto-waiting and retryability behaviour.

const loginButton = page.getByRole(
'button',
{ name: 'Login' }
);

Element Action

Once Playwright resolves the locator and the required actionability conditions are satisfied, an action such as click, fill, hover or check can be performed.

await loginButton.click();

For an experienced interview answer, the important point is not simply listing these objects. It is explaining how they connect together during real browser automation.

2. How Does Playwright Smart Waiting or Auto-Waiting Work?

Candidates often hear this question using the informal term Playwright smart waiting. However, the official Playwright terminology is generally referred to as auto-waiting.

A weak answer would be that Playwright automatically waits for an element before performing an action. That explanation is incomplete because the important question is what Playwright is actually waiting for.

A stronger answer is that Playwright performs relevant actionability checks before executing many element actions. For example, before a normal locator.click() action, Playwright checks that the locator resolves appropriately and verifies conditions including visibility, stability, whether the element receives events and whether it is enabled.

Test requests click
 ↓
Locator resolves
 ↓
Element visible?
 ↓
Element stable?
 ↓
Receives events?
 ↓
Element enabled?
 ↓
Click performed

This is an important distinction in real QA automation projects. An element can exist in the DOM but still not be ready for interaction. For example, a button may be visible while an animation is still running, or an overlay may temporarily block user interaction.

Button exists in DOM
↓
Button becomes visible
↓
Loading overlay covers button
↓
API processing completes
↓
Overlay disappears
↓
Button can receive events
↓
Playwright performs click

Therefore, instead of saying that Playwright waits until an element exists, an experienced explanation would be that Playwright waits for the element to satisfy the relevant actionability conditions required for the requested operation.

This understanding becomes especially useful when debugging flaky tests or automation failures that behave differently in local execution and CI environments.

Knowing Playwright Is One Thing. Executing a Project Is Another.

If you already know Playwright + TypeScript but haven’t experienced real project execution, work alongside experienced QA automation professionals and see how project work is handled beyond tutorials and practice exercises.

Not Another Course • Project Execution • Experienced QA Guidance • Playwright + TypeScript

3. How Do You Handle Multiple Windows Using Playwright?

This question is particularly important for engineers who previously worked extensively with Selenium. In Selenium, browser window handling commonly involves window handles and switching between them. Playwright uses a different model.

In Playwright, a browser tab or popup is represented by a Page object. Instead of searching for a window handle and switching to it, the automation script captures the newly opened page and interacts with it directly.

const popupPromise = page.waitForEvent('popup');

await page.getByText('Open New Window').click();

const popup = await popupPromise;

await popup.waitForLoadState();

console.log(await popup.title());

One important detail is that the script starts waiting for the popup event before performing the action that triggers the popup. This helps avoid missing the event.

Once the popup is captured, it behaves as another Playwright Page.

await popup.getByRole(
'button',
{ name: 'Continue' }
).click();

This is a useful answer when interviewers ask about handling multiple windows using Playwright.

4. How Do You Switch to Another Window Using Playwright?

The wording of this question can sometimes lead candidates toward Selenium-style thinking. A strong Playwright answer is that switching is generally handled by working with the correct Page object rather than using a traditional switchTo().window() pattern.

For example, after capturing the newly opened page, the test interacts directly with that page reference.

const popupPromise = page.waitForEvent('popup');

await page.getByRole(
'link',
{ name: 'Open Account Details' }
).click();

const accountPage = await popupPromise;

await accountPage.waitForLoadState();

await accountPage.getByText(
'Account Summary'
).click();

Conceptually, the automation is managing multiple page references.

BrowserContext
│
├── mainPage
│
└── accountPage

The important interview point is that Playwright represents tabs and popup windows through Page objects.

5. How Do You Handle Multiple Tabs Using Playwright?

Multiple tabs are also represented as multiple Page objects within the same browser context.

const context = page.context();

const newPagePromise = context.waitForEvent('page');

await page.getByText('Open New Tab').click();

const newPage = await newPagePromise;

await newPage.waitForLoadState();

console.log(await newPage.title());

The browser context can also provide access to its existing pages.

const pages = context.pages();

console.log(pages.length);

BrowserContext
 │
 ├── Page 1
 │
 ├── Page 2
 │
 └── Page 3

One useful detail is that Playwright pages inside a browser context can be interacted with directly. Automation generally does not require manually bringing a page to the front simply to perform normal interactions.

Therefore, when interviewers ask about switching to tabs using Playwright, the core concept is understanding and managing the correct Page reference.

6. How Do You Handle Frames Using Playwright?

Another practical Playwright interview question involves iframes. An iframe contains another document embedded inside the current page, so elements inside that iframe are not accessed exactly the same way as elements in the main frame.

One modern Playwright approach is to use frameLocator().

const paymentFrame = page.frameLocator(
'#payment-frame'
);

await paymentFrame
.getByLabel('Card Number')
.fill('4111111111111111');

Conceptually:

Main Page
│
└── iframe
│
├── Card Number
├── Expiry Date
└── CVV

Another option is accessing a frame through the page.frame() API.

const frame = page.frame({
name: 'payment-frame'
});

await frame?.fill(
'#card-number',
'4111111111111111'
);

For modern locator-oriented Playwright automation, frameLocator() is often easier to read because it allows the automation flow to continue using locator-style interactions inside the iframe.

7. What Is the Difference Between Switching Tabs and Switching Frames in Playwright?

This is a useful follow-up question because it tests whether the candidate understands the browser structure rather than simply memorizing APIs.

A browser tab or popup is represented by a separate Page. An iframe, however, exists inside a page.

BrowserContext
 │
 ├── Page / Tab 1
 ││
 │├── Main Frame
 ││
 │└── iframe
 │
 └── Page / Tab 2

Therefore, handling a new browser tab means obtaining and working with another Page object. Handling an iframe means targeting the appropriate Frame or using a FrameLocator.

This distinction is useful for experienced Playwright with TypeScript interview questions because it demonstrates understanding of the object hierarchy.

8. How Do You Execute JavaScript Using Playwright?

Playwright provides page.evaluate() for executing JavaScript inside the browser page context.

const pageTitle = await page.evaluate(() => {
return document.title;
});

console.log(pageTitle);

Another example is accessing browser-level information.

const url = await page.evaluate(() => {
return window.location.href;
});

This is useful because Playwright test code runs in the Playwright environment, while code executed through page.evaluate() runs inside the browser page environment.

Playwright Test Environment
│
│ page.evaluate()
▼
Browser Page JavaScript Environment
│
├── window
├── document
└── DOM APIs

An experienced-level answer should also mention that page.evaluate() should not become a replacement for normal Playwright locators and element actions.

For example, directly executing DOM click logic through JavaScript can bypass the normal Playwright interaction behaviour.

await page.evaluate(() => {
document.querySelector('#button')?.click();
});

Therefore, page.evaluate() should be used when browser-context JavaScript execution is genuinely required rather than as the default approach for normal UI automation.

9. How Do You Handle Open Dialogs in Playwright?

Before answering this question, it is useful to identify what type of dialog the interviewer means. JavaScript browser dialogs include alerts, confirm dialogs and prompts.

page.on('dialog', async dialog => {

console.log(dialog.type());

console.log(dialog.message());

await dialog.accept();

});

The application action can then trigger the dialog.

await page.getByRole(
'button',
{ name: 'Delete' }
).click();

A confirmation dialog can be dismissed if the automation scenario requires the negative action.

page.once('dialog', async dialog => {
await dialog.dismiss();
});

A prompt can accept input.

page.once('dialog', async dialog => {
await dialog.accept('Test Input');
});

One important practical detail is that when a dialog listener is registered, the dialog should be explicitly accepted or dismissed. Otherwise, the page can remain blocked waiting for the dialog interaction to complete.

10. How Do You Handle a Save Dialog or File Download Using Playwright?

This question requires clarification because a browser download and a native operating system Save As dialog are not the same thing.

Scenario A: The Application Downloads a File

When a web application triggers a browser download, Playwright provides a download event and a Download object.

const downloadPromise = page.waitForEvent('download');

await page.getByText('Download Report').click();

const download = await downloadPromise;

await download.saveAs(
'./downloads/report.pdf'
);

User clicks Download
		↓
Browser starts download
↓
Playwright receives download event
↓
Download object becomes available
↓
File can be saved using saveAs()

Scenario B: Native Operating System Save As Dialog

A true native operating system dialog is outside the normal browser DOM. Therefore, it should not be described as something Playwright handles in the same way as a web element or JavaScript browser dialog.

A technically accurate interview answer would be that browser downloads should normally be handled using Playwright’s download APIs, while native operating system dialogs belong to a different automation boundary.

11. How Do You Copy and Paste Using Playwright with TypeScript?

Keyboard shortcuts can be simulated using Playwright’s keyboard API.

For Windows and Linux environments:

await page.keyboard.press('Control+A');

await page.keyboard.press('Control+C');

await page.keyboard.press('Control+V');

For macOS environments, the Command key is generally represented using Meta.

await page.keyboard.press('Meta+A');

await page.keyboard.press('Meta+C');

await page.keyboard.press('Meta+V');

However, an experienced engineer should also consider whether keyboard simulation is genuinely required. If the purpose is simply entering text into an input field, a locator-based action such as fill() is usually clearer and more reliable.

await locator.fill('Test Data');

Copy-and-paste automation becomes more relevant when the application behaviour specifically depends on clipboard-related or keyboard-driven user interaction.

12. How Do You Press Multiple Keys Using Playwright?

Playwright supports keyboard combinations using page.keyboard.press().

await page.keyboard.press('Control+A');

await page.keyboard.press('Control+C');

await page.keyboard.press('Control+V');

Other examples include:

await page.keyboard.press('Shift+Tab');

await page.keyboard.press('Control+Shift+P');

await page.keyboard.press('Alt+ArrowLeft');

For scenarios requiring explicit control over key-down and key-up events, Playwright also provides:

await page.keyboard.down('Control');

await page.keyboard.press('A');

await page.keyboard.up('Control');

keyboard.down('Control')
↓
keyboard.press('A')
↓
keyboard.up('Control')

For normal keyboard shortcuts, keyboard.press() is generally easier to read. The lower-level down() and up() approach becomes useful when the application requires more precise keyboard event control.

13. Can You Explain Playwright Locators?

A basic answer would be that locators are used to find elements. While correct, an experienced answer should explain why locators are important in Playwright’s overall design.

Locators are central to Playwright’s auto-waiting and retryability model. A locator describes how Playwright can find an element when an action or assertion needs to interact with it.

Role Locator

page.getByRole(
'button',
{ name: 'Submit' }
);

Text Locator

page.getByText('Welcome');

Label Locator

page.getByLabel('Email Address');

Placeholder Locator

page.getByPlaceholder('Enter email');

Test ID Locator

page.getByTestId('submit-button');

The locator strategy should depend on the application and the stability of the available attributes. User-facing semantic locators can be useful because they align automation with how users interact with the application. Stable test identifiers can also be valuable when a team intentionally provides them as an automation contract.

User-facing semantic element available
↓
 getByRole()
↓
Label available
↓
 getByLabel()
↓
Stable test contract exists
↓
getByTestId()

An experienced engineer should generally avoid unnecessarily fragile selectors that depend heavily on UI styling classes or deeply nested DOM structures that may change frequently.

14. What Element Actions Does Playwright Support?

Playwright provides a range of locator actions depending on the type of interaction required.

Click

await locator.click();

Fill

await locator.fill('John');

Check

await locator.check();

Uncheck

await locator.uncheck();

Select Option

await locator.selectOption('India');

Hover

await locator.hover();

Double Click

await locator.dblclick();

Focus

await locator.focus();

Press a Keyboard Key

await locator.press('Enter');

Drag and Drop

await source.dragTo(target);

Upload a File

await page
.locator('input[type="file"]')
.setInputFiles('./document.pdf');

The important point for an experienced interview is not simply listing actions. Different actions can require different actionability checks. For example, clicking an element and filling an editable input do not require exactly the same conditions.

Therefore, understanding Playwright element actions also requires understanding the relationship between locators, auto-waiting and actionability.

The Pattern Behind These Playwright Interview Questions

When these questions are viewed individually, they can appear to be unrelated. One question is about tabs, another is about frames, another is about dialogs and another is about locators.

However, there is a larger pattern behind them.

 Playwright
 ↓
 
BrowserContext
 │
 ┌───────────┴───────────┐
 ↓                      ↓
 Pages             Isolation
 │
 ┌─────┴─────┐
 ↓           ↓
Tabs       Popups
 ↓
Frames
 ↓
Locators
 ↓
Auto-Waiting
 ↓
Element Actions

Outside the normal DOM interaction model, Playwright also interacts with browser events and browser execution contexts.

Playwright Test
 │
 ├── Browser Pages
 │
 ├── Frames
 │
 ├── Dialog Events
 │
 ├── Download Events
 │
 ├── Keyboard Events
 │
 └── JavaScript Evaluation

This is why preparing for experienced Playwright interviews by memorizing isolated APIs can be difficult. A stronger approach is to understand where each concept fits inside the Playwright automation model.

How Candidates Can Prepare for Real Playwright with TypeScript Interview Questions

Candidates preparing for 5–7 years experienced roles on Playwright with TypeScript interview questions and answers  should not limit preparation to definitions. It is more useful to practice explaining realistic scenarios.

Scenario: A Button Is Visible but Playwright Cannot Click It

Be prepared to discuss actionability, overlays, element stability, whether the element receives events and how you would investigate the failure instead of immediately adding arbitrary waits.

Scenario: Clicking a Link Opens Another Browser Page

Understand the relationship between Page, popup events and browser context page events.

Scenario: The Required Element Exists Inside an iframe

Understand frames, frameLocator() and frame-based interactions.

Scenario: A Browser Dialog Blocks the Page

Understand dialog events and the difference between accepting, dismissing and providing prompt input.

Scenario: A Report Needs to Be Downloaded

Understand the download event, the Download object and saving the downloaded file.

Scenario: The Application Requires a Keyboard Shortcut

Understand keyboard.press() and, where necessary, keyboard.down() and keyboard.up().

The Bigger Learning for Experienced QA Automation Candidates

The biggest learning from these types of interview questions is that experienced Playwright interviews are not always focused on writing a large automation framework during the interview.

Sometimes the interviewer is checking whether the candidate understands browser automation deeply enough to reason through unexpected situations.

A candidate may know:

click()

fill()

expect()

But the interviewer may ask:

What happens when another browser tab opens?

What if the element is inside an iframe?

What happens when a JavaScript dialog blocks the page?

How would you handle a browser download?

When would you execute JavaScript using page.evaluate()?

What exactly does Playwright wait for before clicking an element?

These questions become much easier to answer when candidates understand the architecture and interaction model instead of only practicing standard login-page automation examples.

Playwright Architecture
↓
Browser Context
↓
Pages
↓
Frames
↓
Locators
↓
Auto-Waiting
↓
Element Actions
↓
Browser Events

Final Thoughts: Real Interview Questions Are Often About How You Think

There is no single fixed list of Playwright interview questions that guarantees success in every QA Automation interview.

Different companies may focus on framework architecture, fixtures, API testing, CI/CD, authentication, parallel execution, network mocking, test isolation or flaky test debugging.

However, questions around Playwright architecture, auto-waiting, browser pages, multiple windows, tabs, frames, dialogs, downloads, keyboard interactions, locators and element actions provide an important foundation for candidates preparing for experienced QA Automation roles.

The most useful interview preparation is not necessarily memorizing one hundred Playwright questions and answers.

A stronger approach is understanding how Playwright behaves, why specific APIs exist and how those concepts apply when something unexpected happens in a real automation project.

For candidates preparing for Playwright with TypeScript interview questions and answers, especially those targeting 5–7 years experienced QA Automation roles, the goal should be to move beyond syntax memorization and develop the ability to explain the reasoning behind the automation approach.

That is often where the difference appears between someone who has practiced Playwright commands and someone who can confidently discuss how a Playwright automation project behaves in real-world scenarios.