Playwright for Java Interview Prep: 12 Core Topics

Questions, Answers, and Practical Patterns for SDET Interviews

Lamhot Siagian

PhD Student • AI Evaluation Engineer • AI Engineer Machine Learning • Data Science & AI/ML

[Link]/in/lamhotsiagian
[Link]
lamhotsiagian2025@[Link]

January 22, 2026

Copyright

Copyright © 2026 Lamhot Siagian. All rights reserved.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any
form or by any means, without prior written permission from the copyright holder.
This material is provided for educational purposes. The code and examples are illustrative and must
be adapted and reviewed for your environment, security requirements, and organizational policies.
Contents

1 Architecture and Core Concepts 1

1.1 Interview Q&A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.1 Core Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.2 Scenario-Based Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.3 Practical Patterns and Code . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.4 Pitfalls and Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Next Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1 What to practice next . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Locators Deep Dive 4

2.1 Interview Q&A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1 Core Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.2 Scenario-Based Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.3 Practical Patterns and Code . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.4 Pitfalls and Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Next Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1 What to practice next . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3 Auto-waiting, Assertions, and Flakiness Control 7

3.1 Interview Q&A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.1 Core Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.2 Scenario-Based Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.3 Practical Patterns and Code . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.4 Pitfalls and Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2 Next Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.1 What to practice next . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4 Frames, iFrames, and Shadow DOM 10

4.1 Interview Q&A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1.1 Core Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1.2 Scenario-Based Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.3 Practical Patterns and Code . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.4 Pitfalls and Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2 Next Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.1 What to practice next . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

5 Network Interception and API Testing 13

ii
Lamhot Siagian Playwright Java Interview Prep

5.1 Interview Q&A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

5.1.1 Core Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1.2 Scenario-Based Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1.3 Practical Patterns and Code . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1.4 Pitfalls and Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2 Next Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.2.1 What to practice next . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

6 Authentication and Session Reuse 16

6.1 Interview Q&A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1.1 Core Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1.2 Scenario-Based Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1.3 Practical Patterns and Code . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1.4 Pitfalls and Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.2 Next Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.2.1 What to practice next . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

7 Test Runner Setup and Design Patterns 19

7.1 Interview Q&A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1.1 Core Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1.2 Scenario-Based Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.1.3 Practical Patterns and Code . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.1.4 Pitfalls and Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.2 Next Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.2.1 What to practice next . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

8 Parallel Execution and Test Isolation 22

8.1 Interview Q&A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.1.1 Core Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.1.2 Scenario-Based Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.1.3 Practical Patterns and Code . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.1.4 Pitfalls and Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.2 Next Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.2.1 What to practice next . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

9 Debugging Tooling 25
9.1 Interview Q&A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
9.1.1 Core Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
9.1.2 Scenario-Based Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
9.1.3 Practical Patterns and Code . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
9.1.4 Pitfalls and Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
9.2 Next Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
9.2.1 What to practice next . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

10 Handling Complex UI Interactions 28

10.1 Interview Q&A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
10.1.1 Core Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
10.1.2 Scenario-Based Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

iii
Lamhot Siagian Playwright Java Interview Prep

10.1.3 Practical Patterns and Code . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

10.1.4 Pitfalls and Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
10.2 Next Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
10.2.1 What to practice next . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

11 Data-Driven Testing and Configuration 31

11.1 Interview Q&A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
11.1.1 Core Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
11.1.2 Scenario-Based Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
11.1.3 Practical Patterns and Code . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
11.1.4 Pitfalls and Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
11.2 Next Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
11.2.1 What to practice next . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

12 CI/CD Integration and Reporting 34

12.1 Interview Q&A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
12.1.1 Core Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
12.1.2 Scenario-Based Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
12.1.3 Practical Patterns and Code . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
12.1.4 Pitfalls and Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
12.2 Next Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
12.2.1 What to practice next . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

iv
Chapter 1

Architecture and Core Concepts

Playwright is built around a small set of primitives that map to the browser’s isolation model.
In Java, you typically create a Playwright instance, launch a Browser, then create one or more
BrowserContext objects. A context is an isolated session, so cookies, local storage, and permissions
do not leak across tests. A Page represents a single tab within a context, and most test code interacts
through Page and Locator objects. Playwright’s execution model is asynchronous under the hood,
but the Java API exposes synchronous calls that include auto-waiting for many actions. This design
reduces the need for explicit sleeps and makes failures more diagnosable when you use assertions
correctly. Interviewers often probe whether you understand where isolation should live and how to
structure tests to keep that isolation. A common recommendation is one context per test and a
shared browser per test worker, which is both fast and reliable. If you share a context across tests,
you must control state carefully and accept higher flakiness risk. You should also be comfortable
explaining how Playwright differs from Selenium in architecture and reliability. Playwright ships
with browser automation that is protocol-driven and includes a first-class test instrumentation stack.
The practical impact is deterministic waiting, stronger selectors, and richer debugging artifacts such
as traces and network logs.

1.1 Interview Q&A

1.1.1 Core Concepts
Q: Explain Browser, BrowserContext, and Page, and how they relate to test isolation.
Answer. Browser is the process-level container for an engine like Chromium, and it is the expensive
object you want to reuse across tests. BrowserContext is an isolated session inside the browser,
similar to an incognito profile, and it should be the boundary for authentication and storage. Page
is a single tab within a context, and pages share storage and cookies with other pages in the same
context.

Q: When should you create a new context versus a new page? Answer. Create a new
context when you need strict separation of cookies, local storage, permissions, geolocation, or user
identity. Create a new page when you want multiple tabs that share the same session, such as a
flow that opens a popup and returns data to the original tab. In practice, one page per test inside a
fresh context is a reliable default and keeps cleanup simple.

1
Lamhot Siagian Playwright Java Interview Prep

Q: How does Playwright’s auto-waiting work at a high level, and what does it not
do for you? Answer. Auto-waiting means Playwright waits for actionable conditions before
performing many actions, such as element visibility and stability before a click. It also retries certain
operations until timeouts when the conditions are not met, which reduces the need for manual waits.
It does not replace application-level readiness checks, like waiting for data to load after a request or
ensuring a background job completed before asserting results.

1.1.2 Scenario-Based Questions

Q: You see intermittent failures only in CI when tests run faster. What architecture-
level checks do you apply first? Answer. First, confirm you are not sharing a context or
page across parallel tests, because shared state is the most common CI-only failure cause. Next,
verify timeouts and the base URL configuration, and ensure test data is deterministic rather than
environment-dependent. Then capture traces and network logs for failures so you can compare the
last successful step against the failing step using the trace viewer.

Q: Your product supports multiple user roles and cross-role workflows. How do you
model this with contexts? Answer. Use one context per user role to keep authentication and
storage isolated, and name those contexts explicitly in code so it is obvious which role is acting.
When a workflow requires two users interacting, run them in parallel pages but separate contexts,
and synchronize on explicit application events such as a specific response or DOM state. Persist each
role’s storage state to disk to speed up setup, but refresh it when sessions expire or roles change.

1.1.3 Practical Patterns and Code

Q: Show a minimal, production-friendly test scaffold that creates a shared Browser but
isolates each test with its own context and page. Answer. A stable scaffold constructs the
Browser once per test class or worker and creates a fresh BrowserContext per test case. In setup,
create the context with consistent options such as viewport size, locale, and base URL, then create
the page and navigate to the starting state. In teardown, close the context to guarantee storage and
network resources are released even when a test fails.
import [Link].*;
import [Link].*;

import static [Link];

public class BasePlaywrightTest {

private static Playwright playwright;
private static Browser browser;

protected BrowserContext context;

protected Page page;

@BeforeAll
static void launchBrowser() {
playwright = [Link]();
browser = [Link]().launch(new [Link]().setHeadless(
true));
}

2
Lamhot Siagian Playwright Java Interview Prep

@AfterAll
static void closeBrowser() {
if (browser != null) [Link]();
if (playwright != null) [Link]();
}

@BeforeEach
void createContextAndPage() {
context = [Link](new [Link]()
.setViewportSize(1365, 768)
.setLocale("en-US"));
page = [Link]();
}

@AfterEach
void cleanup() {
if (context != null) [Link]();
}

@Test
void smoke() {
[Link]("[Link]
assertThat(page).hasTitle("Example Domain");
}
}

1.1.4 Pitfalls and Troubleshooting

Q: What are two common ways engineers accidentally break isolation in Playwright
Java? Answer. One common issue is storing Page or BrowserContext in a static field and
reusing it across tests, which leaks cookies and can race under parallel execution. Another issue is
sharing test data such as user accounts or tenant identifiers without coordination, which creates
write conflicts at the application layer. Fix these by enforcing per-test context creation and by
provisioning unique test data per test or per worker.

1.2 Next Actions

1.2.1 What to practice next
Q: If you had 60 minutes, what would you do to build confidence in the core model?
Answer. Start by writing a two-test suite where each test logs in as a different user role and verify
storage does not leak between them. Then add a third test that opens a popup and asserts values
flow back to the main tab, using waitForPopup and an explicit assertion. Finally, turn on tracing
and practice reading a trace zip so you can explain failures from artifacts rather than guesses.

3
Chapter 2

Locators Deep Dive

Locators are Playwright’s central abstraction for resilient element targeting. A Locator represents a
query that is re-evaluated against the page over time, which aligns with dynamic web apps where
DOM nodes are replaced frequently. In interviews, the goal is to show you can build selectors
that survive UI refactors and A/B changes. In Java, you can use CSS selectors, text selectors,
and accessibility-first selectors such as getByRole. Accessibility selectors are often the most stable
because they tie to user-visible semantics rather than layout. Playwright also enforces strictness by
default for locators, which helps detect ambiguous selectors early. Strong locator strategy balances
stability, readability, and diagnosability. A stable selector is usually tied to intent, like a button
name or an explicit data-testid, rather than incidental structure such as div nesting. Diagnosability
matters because when a selector fails, you want the error message to point to a clear UI concept.
A good answer also covers how to refactor locator usage at scale. This usually means using page
objects or component objects that expose semantic actions and returning Locator instances for reuse.
If you hide locators behind methods that always click, you lose composition and make negative
testing harder.

2.1 Interview Q&A

2.1.1 Core Concepts
Q: Why are Playwright Locators more reliable than one-time element handles in
dynamic UIs? Answer. Locators are re-resolved when you perform an action or assertion, so
they remain valid even if the underlying DOM node was replaced. In contrast, element handles
can become stale when frameworks re-render components, which leads to failures that look random.
Locator re-resolution combined with auto-waiting reduces these timing races and produces clearer
diagnostics when elements do not meet expected states.

Q: Explain strict mode for locators and why it helps in interviews and in CI. Answer.
Strict mode means a locator that matches more than one element triggers an error rather than
silently choosing the first match. This catches ambiguous selectors early and prevents tests from
passing against the wrong element in some environments. In CI, strictness is a guardrail that turns
a flaky misclick into a deterministic failure with an actionable message.

4
Lamhot Siagian Playwright Java Interview Prep

2.1.2 Scenario-Based Questions

Q: A button label changes slightly across locales or experiments. How do you keep the
locator stable without using brittle CSS? Answer. Prefer semantic selectors that are stable
across locale when possible, such as a data-testid or a role selector that targets a stable accessible
name pattern. If localization is required, parameterize the expected label per locale and keep it in
a single mapping rather than duplicating selectors across tests. For experiments, target a stable
attribute or component identifier and assert the user-visible text separately so the test still verifies
correct UI.

Q: You have a list with repeated rows, and you need to click the action in the row
that contains a specific text. What is the locator pattern? Answer. Start with a locator
that targets the collection of rows, then filter by hasText or by a nested locator that matches the
cell value, and finally locate the action within that filtered row. This pattern makes the intent
explicit and avoids indexing that breaks when sorting changes. It also provides better error messages
because the failure points to the row selection condition rather than an out-of-range index.

2.1.3 Practical Patterns and Code

Q: Show a readable locator strategy using roles and chaining for a login form, including
a negative assertion for an error state. Answer. Use role-based selectors for buttons and
textboxes, then chain by label or name to express intent. After an action, use assertions on locators
rather than manual waits, so failures include the expected state and the actual state. For negative
paths, assert error messages are visible and verify the URL or authenticated element did not change.
import [Link].*;
import [Link];

import static [Link];

public class LoginExample {

public static void login(Page page, String email, String password) {
[Link]([Link], new [Link]().setName("Email")).fill
(email);
[Link]([Link], new [Link]().setName("Password")).
fill(password);
[Link]([Link], new [Link]().setName("Sign in")).
click();
}

public static void invalidLoginShowsError(Page page) {

login(page, "bad@[Link]", "wrong");
Locator error = [Link]([Link]);
assertThat(error).isVisible();
assertThat(error).containsText("Invalid");
}
}

5
Lamhot Siagian Playwright Java Interview Prep

2.1.4 Pitfalls and Troubleshooting

Q: What is a practical selector rubric you can describe during an interview? Answer.
First, prefer accessibility selectors like getByRole with a stable name because they align with what
users perceive and are usually stable. Second, use data-testid for elements without semantic roles or
when the accessible name is unstable, and keep the test IDs owned by the team. Third, use CSS or
XPath only as a last resort and keep them short, because they tend to encode layout and break
with refactors.

2.2 Next Actions

2.2.1 What to practice next
Q: How do you quickly improve selector quality in an existing flaky suite? Answer.
Pick the top five flaky tests and replace index-based selectors with filtered locators that express row
intent and action intent. Add one helper that centralizes data-testid conventions and update the
UI code where needed to support stable IDs. Then enable strictness, remove sleeps, and rely on
expect-based assertions so failures point to a clear missing state rather than a timing guess.

6
Chapter 3

Auto-waiting, Assertions, and

Flakiness Control

Waiting is where many automation suites lose reliability, and Playwright’s model is designed to
minimize manual waiting. In interviews, you want to show you understand what Playwright waits
for implicitly and what you must still wait for explicitly. You also want to show that you can
replace sleeps with deterministic application signals. Assertions are a form of waiting when you use
Playwright’s expect-style checks. An assertion like isVisible retries until the condition is met or the
timeout expires, which makes tests both stable and readable. The key is to assert the state that
truly indicates readiness, such as a specific response, a DOM state, or a business confirmation. A
practical approach is to treat each test as a sequence of state transitions. After you act, you wait
for a state that proves the app processed that action, and then you assert business outcomes. If you
wait only for cosmetic changes, you may miss backend failures or race conditions. You should also
explain timeouts and how to tune them responsibly. Global timeouts should stay moderate, and
local waits should be used when a step is known to be slow. When failures happen, you capture
artifacts, and you adjust the waiting condition rather than simply increasing timeouts.

3.1 Interview Q&A

3.1.1 Core Concepts
Q: What does Playwright auto-wait for when calling click or fill, and what are examples
it does not cover? Answer. For actions like click, Playwright waits for the element to be
attached, visible, stable, enabled, and not obscured, so the action is meaningful. It also synchronizes
with the browser event loop so that microtasks and rendering can settle around the action. It does
not automatically wait for your business data to be loaded, so you still need to wait for a response,
a specific UI state, or a completion toast after the action triggers a network call.

Q: How do Playwright assertions reduce flakiness compared to custom polling loops?

Answer. Playwright assertions integrate with locator resolution and the same internal waiting logic,
so they retry based on browser signals rather than arbitrary sleep intervals. They also produce error
messages that include expected conditions and actual state, which makes debugging faster. Custom
polling loops often miss edge cases like element detachment and can hide real timing problems
because they do not capture artifacts consistently.

7
Lamhot Siagian Playwright Java Interview Prep

3.1.2 Scenario-Based Questions

Q: After clicking Save, the UI shows a toast but the backend sometimes rejects the
update. What is the correct waiting and assertion strategy? Answer. First, wait for the
specific network response that represents the save request and assert the status and response body
if available. Then assert the UI toast is visible and contains the correct message, because the toast
is the user-facing confirmation. Finally, validate persistence by reloading the page or fetching the
data again through the UI so you assert business state rather than only transient notifications.

Q: A spinner disappears, but the page still updates content for another second. How
do you pick a better readiness signal? Answer. Treat the spinner as a weak signal and
instead wait for the stable content that indicates data has arrived, such as a table row count or a
specific cell value. If you control the app, add a test-friendly marker like an aria-busy attribute
on the region and wait for it to flip to false. If you cannot change the app, wait for the relevant
response and then assert a target locator contains the expected value.

3.1.3 Practical Patterns and Code

Q: Show an example that waits for a specific response while performing an action, and
then asserts the UI and the business state. Answer. Use [Link] with a
predicate that matches URL and status, and wrap the user action inside the runnable so the wait
is causally linked to the action. After the response, assert the UI indicator that the user expects,
such as a toast, and then assert the state that should persist after refresh. This pattern removes
guesswork and is easy to explain in interviews because it ties each wait to a concrete signal.
import [Link].*;
import [Link];

import static [Link];

public class SaveWithResponseWait {

public static void saveAndVerify(Page page) {
Locator save = [Link]([Link], new [Link]().setName(
"Save"));

Response resp = [Link](r ->

[Link]().contains("/api/profile") && [Link]().method().equals("PUT") && r.
status() == 200,
save::click
);

assertThat([Link]([Link])).containsText("Saved");
[Link]();
assertThat([Link]("[data-testid=’profile-name’]")).hasText("Updated Name");
}
}

3.1.4 Pitfalls and Troubleshooting

Q: What are three anti-patterns for waiting, and what do you replace them with?
Answer. First, avoid [Link] because it adds time without proving readiness, and replace it

8
Lamhot Siagian Playwright Java Interview Prep

with expect-based assertions or response waits. Second, avoid waiting for generic selectors like body
visible because that is almost always true, and replace it with a business-ready locator. Third, avoid
global timeout inflation as a default fix, and replace it with tighter, step-specific waiting conditions
that match the app’s behavior.

3.2 Next Actions

3.2.1 What to practice next
Q: How do you build a habit of writing deterministic waits? Answer. For each action
that triggers a request, identify the request and response pair, and add a response wait predicate
that matches the endpoint and method. For each page transition, assert a page-specific landmark
element such as a heading or a unique data-testid, and avoid relying on spinners alone. After writing
the waits, run the suite with throttled CPU or network and confirm the waits still pass without
sleeps.

9
Chapter 4

Frames, iFrames, and Shadow DOM

Frames and Shadow DOM are common sources of automation failures because they introduce
boundaries that typical selectors do not cross. In Playwright, the recommended approach is to
use frameLocator for iframes and to keep interactions scoped to the correct document. This keeps
selectors readable and prevents accidental cross-frame matches. An iframe is a separate document
with its own DOM and execution context. When a page uses nested iframes, you must identify
the correct frame and then locate elements inside that frame. In interviews, it is important to
explain how you will detect the frame and how you keep the code stable when the frame loads slowly.
Shadow DOM encapsulates component internals, which is common in design systems and Web
Components. Playwright can pierce shadow DOM in many cases, but best practice is still to rely
on stable, user-facing selectors or explicit test IDs. When shadow boundaries shift, component-level
wrappers are often the most maintainable solution. A strong answer also covers test strategy. If a
critical workflow is inside a third-party iframe, you often need contract tests at the API level plus
minimal UI checks, because UI selectors can change outside your control. For first-party frames,
you can invest in stable selectors and component objects to reduce churn.

4.1 Interview Q&A

4.1.1 Core Concepts
Q: How do you interact with elements inside an iframe in Playwright Java, and why is
frameLocator preferred? Answer. Use frameLocator to scope locator resolution to the frame
document, which keeps selectors concise and avoids manual frame switching logic. frameLocator
also composes well with auto-waiting, because it waits for the frame to be attached and for the
target inside the frame to be actionable. This is preferred over brittle approaches that query frames
by index, because frame order changes frequently with ad slots and layout refactors.

Q: What is the practical difference between waiting for a frame to appear and waiting
for a frame’s content to be ready? Answer. Waiting for a frame to appear only means
the iframe element exists in the parent DOM, which does not guarantee the inner document has
loaded. Waiting for frame content readiness means the inner document has navigated and rendered
the elements you need. The stable approach is to scope to the frame and assert a frame-specific
landmark element is visible, or wait for the relevant response inside the frame if you can observe it.

10
Lamhot Siagian Playwright Java Interview Prep

4.1.2 Scenario-Based Questions

Q: An embedded payments provider loads inside an iframe and sometimes fails due to
third-party latency. How do you test this reliably? Answer. Split responsibility by testing
your integration points, such as request payloads and redirect URLs, through API or contract tests,
and keep UI verification minimal. In UI tests, mock the provider when feasible using routing, or
use a sandbox environment with deterministic data. When mocking is not allowed, build a retry
strategy at the scenario level and capture traces so you can distinguish app failures from provider
outages.

Q: Your app uses a Web Component with Shadow DOM, and designers frequently
change internal markup. How do you keep tests stable? Answer. Target user-facing
semantics such as roles, labels, and visible names that remain stable even when internal markup
changes. If semantics are not enough, add data-testid attributes at the component boundary and
expose component-level actions through a component object. Avoid selectors that reach into deep
shadow internals unless you own the component and can enforce selector stability as part of the
component contract.

4.1.3 Practical Patterns and Code

Q: Show an iframe interaction that waits for an input inside the frame and submits a
form. Answer. Use frameLocator with a stable iframe selector, then locate by role or test ID
inside the frame. Assert visibility before filling to get clear errors when the frame content is not
ready. After submission, wait for a response or a confirmation element outside the frame so you can
verify the end-to-end state transition.
import [Link].*;
import [Link];

import static [Link];

public class IframeExample {

public static void pay(Page page) {
FrameLocator payFrame = [Link]("iframe[data-testid=’payments-iframe’]");
Locator card = [Link]([Link], new FrameLocator.
GetByRoleOptions().setName("Card number"));
assertThat(card).isVisible();
[Link]("4242 4242 4242 4242");

[Link]([Link], new [Link]().setName("

Submit")).click();
assertThat([Link]([Link])).containsText("Payment successful");
}
}

4.1.4 Pitfalls and Troubleshooting

Q: What are two debugging steps you take when iframe locators fail intermittently?
Answer. First, capture a trace and inspect the frame tree at the failing moment to confirm the
iframe selector points to the correct instance. Second, log frame URLs and names at runtime so you

11
Lamhot Siagian Playwright Java Interview Prep

can detect unexpected navigations, such as redirects to an error page in the iframe. If the iframe
content is slow, replace implicit assumptions with an explicit assertion on a landmark element inside
the frame before interacting.

4.2 Next Actions

4.2.1 What to practice next
Q: What is a small exercise that proves you understand frames and shadow DOM?
Answer. Create a demo page with an iframe that loads a simple form and write a test that submits
the form and asserts a confirmation in the parent page. Add an artificial delay in the iframe response
and verify your test remains stable without sleeps. Then add a Web Component with shadow DOM
and implement a component object that exposes actions without relying on deep internal selectors.

12
Chapter 5

Network Interception and API Testing

Modern web apps are network-driven, so reliable tests often combine UI actions with network-level
signals. Playwright provides first-class request routing, response waiting, and event hooks for console
and page errors. In interviews, showing you can validate both UI and network behavior is a strong
differentiator. Routing lets you mock or modify requests deterministically, which is essential for
testing error paths and edge cases. You can also block third-party noise to speed up suites and
reduce flakiness. The key is to use routing strategically so tests remain meaningful rather than
becoming pure mocks. Response waits and request inspection allow you to assert that a UI action
produced the correct backend call. This is especially useful when UI feedback is delayed, or when the
UI can show a success toast even if the backend rejected the request. When you can assert backend
status and UI state together, failures are easier to localize. A strong architecture also separates
concerns. Use API tests for pure contract coverage and use UI tests for critical user journeys and
integration checks. When you mix UI and network assertions, do it to reduce flakiness and improve
diagnostics, not to increase test complexity.

5.1 Interview Q&A

5.1.1 Core Concepts
Q: What is request routing in Playwright, and when is it appropriate in interview-
quality tests? Answer. Request routing intercepts outgoing network requests and allows you to
fulfill, abort, or continue them with modifications. It is appropriate when you need deterministic
test data, when you must test error handling that is hard to reproduce, or when third-party calls
are unstable. In interview-quality tests, you should explain that you still verify meaningful behavior
by asserting UI outcomes and by limiting mocks to well-defined boundaries.

Q: How do you validate that a UI click triggered the correct API call without relying
on fragile DOM timing? Answer. Wrap the click in waitForRequest or waitForResponse with
a predicate that matches URL, method, and key headers or payload fields. This creates a causal link
between the user action and the observed network event. After the response, assert a stable UI state,
and optionally assert the request body contains the expected business fields to prove correctness.

13
Lamhot Siagian Playwright Java Interview Prep

5.1.2 Scenario-Based Questions

Q: Your suite is slow because pages load many analytics and ad requests. What is a
safe optimization strategy? Answer. Block or abort known third-party domains that do not
affect core user flows, such as analytics beacons, and confirm the app still renders correctly. Keep
a small allowlist for dependencies that do affect rendering, such as feature flag services or critical
CDNs. Measure before and after using test timing reports so you can justify the optimization with
data.

Q: A test needs to validate retry logic when the first API call fails with 500. How do
you implement this deterministically? Answer. Use routing to fulfill the first matching
request with a 500 response and then allow the subsequent request to continue or fulfill with success.
Assert that the UI shows a retry indicator and eventually reaches the success state. Capture the
number of attempts by counting matching requests so you can assert the retry policy behavior
explicitly.

5.1.3 Practical Patterns and Code

Q: Show a routing example that stubs an API response and then verifies the UI renders
the stubbed data. Answer. Route the specific endpoint with a tight URL pattern, fulfill it
with a realistic JSON payload, and set content type correctly. Navigate or trigger the UI action
that fetches the data, then assert the rendered elements display the expected values. Keep the stub
payload representative of production so you catch parsing and rendering issues.
import [Link].*;
import static [Link];

public class NetworkStubExample {

public static void stubProducts(Page page) {
[Link]("**/api/products", route -> {
String body = "{\"items\":[{\"id\":1,\"name\":\"Widget\",\"price\":12.50}]}";
[Link](new [Link]()
.setStatus(200)
.setContentType("application/json")
.setBody(body));
});

[Link]("[Link]
assertThat([Link]("[data-testid=’product-row’]")).hasCount(1);
assertThat([Link]("[data-testid=’product-name’]")).hasText("Widget");
}
}

5.1.4 Pitfalls and Troubleshooting

Q: What are two mistakes teams make when mocking network calls, and how do you
avoid them? Answer. One mistake is over-mocking so tests never exercise real integrations,
which hides contract drift and breaks production unexpectedly. Avoid this by limiting mocks to
unstable dependencies and keeping a smaller set of true end-to-end tests that hit real services.
Another mistake is using overly broad URL patterns, which can intercept more calls than intended,

14
Lamhot Siagian Playwright Java Interview Prep

so always match on path and method and add assertions to confirm the intercept triggered.

5.2 Next Actions

5.2.1 What to practice next
Q: What is a targeted exercise to prepare for network questions in interviews? Answer.
Pick a UI flow that creates or updates an entity and add a response wait that asserts status and
key fields in the JSON response. Then implement a routing stub for the same endpoint to simulate
a 500 error and verify the UI error handling path. Finally, record a trace and practice explaining
how network evidence confirms or disproves a suspected UI timing issue.

15
Chapter 6

Authentication and Session Reuse

Authentication is a high-cost step in UI automation, and it is also a frequent source of flakiness.

Playwright supports storage state so you can persist cookies and local storage after a login and
reuse them across tests. In interviews, you want to show you can balance speed with security and
correctness. A reliable approach is to have a single login setup that runs once per environment or
per test worker, saves storage state, and then creates contexts that load that state. This reduces
repeated MFA prompts, rate limiting, and login-related UI churn. You still need a refresh strategy
when sessions expire or when permissions change. Session reuse must not hide real defects. You
should maintain a small number of tests that validate the login flow end-to-end, including error
handling and access control. The rest of the suite can reuse storage state, which keeps the suite fast
and focused on feature behavior rather than authentication. Role-based testing is often required.
Use separate storage states per role and avoid sharing them across parallel workers unless you
control server-side session invalidation rules. If roles share the same user account, tests can become
non-deterministic when server sessions are invalidated on new login.

6.1 Interview Q&A

6.1.1 Core Concepts
Q: What is storage state in Playwright, and what does it typically include? Answer.
Storage state is a serialized representation of a browser context’s session data, including cookies and
local storage values. It can also include other origin storage depending on browser behavior, but the
practical focus is authentication state. By saving and reloading storage state, you can start tests
already authenticated without repeating UI login steps.

Q: How do you decide between authenticating via UI login versus setting tokens directly
in storage? Answer. UI login is best for validating the real authentication journey and for
environments where tokens are short-lived or complex. Setting tokens directly can be appropriate
in controlled test environments when UI login is slow or unstable, but you must ensure the token
injection matches production semantics. In interviews, explain that you keep at least one UI login
test as a guardrail and use storage state reuse for the bulk of the suite.

16
Lamhot Siagian Playwright Java Interview Prep

6.1.2 Scenario-Based Questions

Q: Your tests start failing because sessions expire in the middle of a suite. What is a
robust fix? Answer. First, detect expiration explicitly by asserting an authenticated landmark
element before critical actions and handling redirect-to-login as a failure with good artifacts. Then
implement a storage-state refresh job that logs in again and regenerates state when it is older than
a threshold or when a test detects expiration. Finally, isolate sessions per worker so refreshing in
one worker does not invalidate others unexpectedly.

Q: You need to test access control: an admin can see a page, a viewer cannot. How do
you structure this cleanly? Answer. Create separate storage states for admin and viewer,
and build helper functions that create a context for each role. Write two tests that navigate to the
page and assert on role-appropriate outcomes, such as 403 messaging or missing navigation links. If
a single test must cover both roles, run them in separate contexts and avoid switching roles within
one context to prevent state contamination.

6.1.3 Practical Patterns and Code

Q: Show code to generate a storage state once and then reuse it in new contexts for
later tests. Answer. The setup step logs in, verifies a stable post-login landmark element, and
saves storage state to a file. Later, tests create a new context that loads the storage state path,
which restores cookies and local storage at context creation time. This approach is fast and keeps
test code focused on the feature under test rather than authentication mechanics.
import [Link].*;
import [Link];
import [Link];

import static [Link];

public class StorageStateUtil {

public static Path createAuthState(Browser browser) {

BrowserContext ctx = [Link]();
Page page = [Link]();

[Link]("[Link]
[Link]("[name=’email’]", "user@[Link]");
[Link]("[name=’password’]", "secret");
[Link]("button[type=’submit’]");

assertThat([Link]("[data-testid=’nav-dashboard’]")).isVisible();

Path statePath = [Link]("build/[Link]");

[Link](new [Link]().setPath(statePath));
[Link]();
return statePath;
}

public static BrowserContext newAuthedContext(Browser browser, Path statePath) {

return [Link](new [Link]().setStorageStatePath(
statePath));

17
Lamhot Siagian Playwright Java Interview Prep

}
}

6.1.4 Pitfalls and Troubleshooting

Q: What are two security and correctness considerations when storing auth state in a
repo or CI artifacts? Answer. Treat storage state as a credential because cookies and tokens
can grant access, so never commit it to source control and store it as a protected CI secret artifact
when needed. Scope the state to non-production accounts and rotate credentials regularly to reduce
blast radius. Also ensure the storage state is generated against the correct environment, because
reusing a state across different base URLs can produce confusing failures and false confidence.

6.2 Next Actions

6.2.1 What to practice next
Q: What is a realistic role-based exercise that demonstrates session reuse without
hiding login coverage? Answer. Create one dedicated test that performs UI login and asserts
the correct user identity and permissions are present. Then generate two storage states for two roles
and write three feature tests that reuse each role’s state to validate role-specific UI. Finally, add a
guard that fails fast when a context is redirected to the login page, and verify the failure includes
trace and screenshot artifacts.

18
Chapter 7

Test Runner Setup and Design

Patterns

In Java organizations, Playwright is typically paired with JUnit 5 or TestNG, plus a build tool like
Maven or Gradle. Interviewers often focus on how you structure fixtures, parallel execution, and
reusable page models. The goal is to build a suite that scales in both speed and maintainability. A
fixture is more than setup and teardown; it is a contract for how tests acquire resources. You want
predictable browser lifetime, context lifetime, and artifact capture on failures. When your fixture is
clean, individual tests can stay short and focus on intent. Design patterns matter because UI tests
live for a long time and change with product evolution. Page objects and component objects can
reduce duplication, but over-abstraction can hide important test steps and make debugging harder.
The best approach is to keep page objects thin and expose semantic operations and stable locators.
You should also make the next action obvious by showing how you would add a new test. That
means clear naming, consistent folder structure, and a single place to configure timeouts, base URL,
and tracing. If you can explain these decisions concisely, you demonstrate senior-level ownership.

7.1 Interview Q&A

7.1.1 Core Concepts
Q: Compare Page Object Model and component objects for Playwright tests in Java.
Answer. Page objects model whole pages and provide high-level operations, which reduces
duplication across tests that navigate the same pages. Component objects model reusable UI regions
like navbars and tables, which is often a better fit for modern single-page apps where pages are
composed of components. A practical approach combines both: pages compose components, and
tests call page-level workflows that internally use component actions.

Q: What should a base test fixture own, and what should it avoid owning? Answer.
A base fixture should own browser lifecycle, per-test context creation, page creation, and artifact
capture such as traces and screenshots on failure. It should also centralize configuration for timeouts,
base URL, and environment variables. It should avoid owning business workflows, because that
couples every test to a shared abstraction and makes changes risky when only one product area
evolves.

19
Lamhot Siagian Playwright Java Interview Prep

7.1.2 Scenario-Based Questions

Q: A new engineer adds waits and sleeps in every test. How do you enforce better
patterns through design? Answer. Provide helper methods that expose deterministic waits
such as waitForResponse wrappers and landmark assertions, and make them the default examples
in the repo. Enforce code review rules that reject [Link] and require an explicit readiness
signal for asynchronous actions. Also provide test templates and documentation that show the
preferred pattern so the path of least resistance is the correct approach.

Q: Your suite has duplicated login steps across many tests. How do you refactor
without breaking everything? Answer. Introduce a dedicated login helper that returns a
storage state and update one or two tests to use it as a pilot. Then gradually migrate tests by
replacing UI login steps with context creation using the stored state, while keeping a small number
of UI login tests as coverage. Use a feature flag in the fixture to switch between modes during
rollout so you can rollback quickly if environment differences surface.

7.1.3 Practical Patterns and Code

Q: Show a thin page object that exposes stable locators and one semantic workflow
without hiding important assertions. Answer. A thin page object should return locators
for critical elements and provide a small number of workflows that represent user intent. Keep
assertions in the test unless the assertion is part of the workflow contract, such as verifying navigation
completed. This balance keeps tests readable and makes debugging easier because the test still
shows the key expectations.
import [Link].*;
import [Link];

public class SettingsPage {

private final Page page;

public SettingsPage(Page page) {

[Link] = page;
}

public Locator heading() {

return [Link]([Link], new [Link]().setName("
Settings"));
}

public Locator saveButton() {

return [Link]([Link], new [Link]().setName("Save"))
;
}

public void updateDisplayName(String name) {

[Link]("[data-testid=’display-name’]").fill(name);
saveButton().click();
}
}

20
Lamhot Siagian Playwright Java Interview Prep

7.1.4 Pitfalls and Troubleshooting

Q: What is a sign that your page objects are over-abstracted, and what is the correction?
Answer. If a failure requires stepping through many layers to find which UI action occurred, the
page objects are likely hiding too much detail. Over-abstracted page objects often combine multiple
business steps, which makes small UI changes cause wide test churn. The correction is to keep page
objects as composition-friendly building blocks and keep scenario-specific orchestration in the test
or in narrowly-scoped workflow helpers.

7.2 Next Actions

7.2.1 What to practice next
Q: What is a small refactor exercise that demonstrates senior-level test architecture?
Answer. Take an existing test file with duplicated setup and extract a fixture that creates a context
per test and captures a trace on failure. Then introduce one page object and one component object
and refactor two tests to use them without changing behavior. Finally, run the suite in parallel and
confirm no shared-state failures occur, documenting the rules that make parallelism safe.

21
Chapter 8

Parallel Execution and Test Isolation

Parallel execution is essential for keeping UI suites fast, but it amplifies hidden shared-state issues.
In Playwright Java, the browser can be shared safely, while contexts and pages should generally be
per test. Interviewers evaluate whether you understand thread safety, resource lifetimes, and how to
avoid cross-test interference. Parallelism must be designed deliberately. Shared accounts, shared
tenants, and shared datasets can create write conflicts even if browser state is isolated. A reliable
strategy includes unique test data per test, per worker, or per run, plus idempotent cleanup. In
Java, concurrency pitfalls often come from static fields and global singletons. If you store a Page
in a static field or reuse a Locator across tests, parallel execution becomes unsafe. The fix is to
confine mutable state to the test instance and to use dependency injection patterns that are per-test
or per-thread. A senior answer also addresses observability. When tests run in parallel, you need
artifact naming that includes test IDs and worker IDs. You also need structured logging so you can
reconstruct what happened when failures are interleaved across threads.

8.1 Interview Q&A

8.1.1 Core Concepts
Q: What resources are safe to share across parallel tests, and what resources are not?
Answer. Sharing the Browser process is typically safe because Playwright isolates sessions at
the context level and the browser is designed to handle multiple contexts. BrowserContext and
Page should be per test to avoid session leakage and event-handler interference. Test data like user
accounts and database entities should be treated as shared unless you provision them uniquely,
because conflicts happen at the application layer.

Q: What is the difference between test isolation and data isolation, and why do both
matter? Answer. Test isolation is about browser session separation, such as cookies and storage,
which contexts provide. Data isolation is about backend state, such as the entities your tests create
and modify, which contexts do not control. Both matter because you can have perfect browser
isolation but still fail due to shared backend records, especially when tests update the same entity
concurrently.

22
Lamhot Siagian Playwright Java Interview Prep

8.1.2 Scenario-Based Questions

Q: Parallel tests sometimes fail with ’element not found’ even though they pass serially.
What are the likely causes? Answer. A common cause is that tests share a user session, so
one test logs out or changes permissions while another test is still running. Another cause is shared
test data, where one test deletes or renames an entity that another test expects to exist. Use traces
and logs to confirm navigation paths and implement per-test context creation plus unique data
provisioning to remove those cross-test dependencies.

Q: How do you design unique test data when your system has limited ability to create
users or tenants? Answer. Use a pool of pre-provisioned accounts and allocate them per worker
with a lease mechanism so workers do not collide. For entities created within a test, include a run
ID and timestamp in names so you can identify and clean them deterministically. If creation is
expensive, seed data once per run and ensure tests only read shared entities while writes use unique
names or unique IDs.

8.1.3 Practical Patterns and Code

Q: Show a thread-safe pattern for running JUnit 5 tests in parallel while keeping
Playwright resources isolated. Answer. The goal is to share only the Browser and create a
new BrowserContext per test. Avoid static Page fields and keep page creation inside @BeforeEach,
which is per test instance. If you must use ThreadLocal, use it only for immutable configuration
and not for long-lived pages that can leak across tests when runners reuse threads.
import [Link].*;
import [Link].*;
import [Link].*;

@Execution([Link])
public class ParallelSafeTest {
private static Playwright playwright;
private static Browser browser;

private BrowserContext context;

private Page page;

@BeforeAll
static void beforeAll() {
playwright = [Link]();
browser = [Link]().launch(new [Link]().setHeadless(
true));
}

@AfterAll
static void afterAll() {
[Link]();
[Link]();
}

@BeforeEach
void beforeEach() {
context = [Link]();

23
Lamhot Siagian Playwright Java Interview Prep

page = [Link]();
}

@AfterEach
void afterEach() {
[Link]();
}

@Test
void isolatedTest() {
[Link]("[Link]
}
}

8.1.4 Pitfalls and Troubleshooting

Q: What is a quick checklist you apply before enabling parallelism in a mature suite?
Answer. Confirm every test creates and closes its own BrowserContext and that no Page or Locator
is stored in static state. Validate that test accounts and entities are not shared by default, and
implement unique naming or leasing. Add artifact naming that includes test identifiers so you can
debug parallel failures without confusion.

8.2 Next Actions

8.2.1 What to practice next
Q: What is a minimal parallelism experiment you can do on your own machine?
Answer. Take three independent tests and enable concurrent execution, then run them repeatedly
to search for hidden shared-state issues. Add one test that creates an entity and another test that
reads a shared entity, and verify only the read test touches shared data. Finally, introduce trace
capture on failure and confirm that parallel logs remain readable by including the test name and
thread in each log line.

24
Chapter 9

Debugging Tooling

Debugging skill separates senior automation engineers from those who only write scripts. Playwright
provides trace viewer, screenshots, video capture, console logs, and network logs as first-class
artifacts. In interviews, the strongest answers are artifact-driven and show a repeatable process for
isolating failures. Traces are especially valuable because they capture a timeline of actions, DOM
snapshots, and network events. With a trace zip, you can usually determine whether a failure is
due to selector ambiguity, missing data, slow responses, or unexpected navigation. The key is to
enable tracing selectively so you get value without slowing every test. You should also understand
runtime debugging. Running headed mode, slowing down operations, and pausing on failure help
you reproduce locally. However, you should not rely on manual reproduction alone, because CI
failures require artifacts and logs to debug without interactive access. A senior approach also
includes improving observability over time. When a failure happens, you add a targeted assertion or
log that would have made the failure obvious earlier. Over time, this shrinks the time-to-diagnosis
and reduces repeat failures.

9.1 Interview Q&A

9.1.1 Core Concepts
Q: What is captured in a Playwright trace, and how does it help root-cause analysis?
Answer. A trace includes a timeline of actions, DOM snapshots, network activity, console logs, and
metadata about waits and navigation. It helps because you can replay the test steps and inspect
what the page looked like at each point in time. This makes it easier to distinguish a real product
bug from a test design issue like a weak readiness signal.

Q: How do you decide when to capture video versus trace versus screenshots? Answer.
Use traces for most CI debugging because they include the richest context, including DOM and
network details. Use screenshots for lightweight evidence on failure, especially for visual confirmations
and quick triage. Use video when timing and animations matter or when you need a simple replay
for non-technical stakeholders, but prefer traces for technical root cause.

25
Lamhot Siagian Playwright Java Interview Prep

9.1.2 Scenario-Based Questions

Q: A test fails with ’element is not visible’ in CI but passes locally. What is your
debugging sequence? Answer. First, open the trace zip from CI and inspect the failing step
to see whether the element exists, is covered, or never rendered. Next, check viewport size, locale,
and permissions, because local defaults often differ from CI. Then validate the readiness signal by
checking network timing and DOM snapshots, and replace the action with an assertion-driven wait
that targets the actual business-ready state.

Q: You suspect a memory leak because tests slow down after 200 cases. What
Playwright-specific checks do you apply? Answer. Confirm contexts are always closed in
teardown, even when tests fail, because unclosed contexts accumulate pages and event listeners.
Monitor browser process count and context count during the run, and capture heap and CPU signals
from the CI worker if available. If slowdown correlates with tracing or video, disable those globally
and enable them only on retries to reduce overhead.

9.1.3 Practical Patterns and Code

Q: Show a pattern that starts tracing per test and saves a trace only on failure to keep
runs fast. Answer. Start tracing in setup so you capture the full test sequence, but only stop
and persist the trace when a test fails. This keeps successful runs lightweight while ensuring failures
are debuggable. Name artifacts with the test name and timestamp so parallel runs do not overwrite
files.
import [Link].*;
import [Link].*;
import [Link].*;
import [Link].*;

public class TraceOnFailureExample {

private BrowserContext context;

@BeforeEach
void startTracing() {
// context = ... create context
[Link]().start(new [Link]()
.setScreenshots(true)
.setSnapshots(true)
.setSources(true));
}

@AfterEach
void stopTracing(TestInfo info) throws Exception {
boolean failed = [Link]().contains("FAILED"); // placeholder pattern for
illustration
if (failed) {
String safeName = [Link]().replaceAll("[^a-zA-Z0-9-_]", "_");
Path out = [Link]("build/traces/" + safeName + "-" + [Link]().
toEpochMilli() + ".zip");
[Link]([Link]());
[Link]().stop(new [Link]().setPath(out));
} else {

26
Lamhot Siagian Playwright Java Interview Prep

[Link]().stop();
}
[Link]();
}
}

9.1.4 Pitfalls and Troubleshooting

Q: What is a common mistake when adding debug logs, and what is a better approach?
Answer. A common mistake is printing large volumes of unstructured logs that hide the signal and
make parallel output unreadable. A better approach is to log structured, step-level events with test
name, URL, and key state, and to rely on trace artifacts for deep context. When you add logs, tie
them to a hypothesis, such as logging the response status for a suspected failing endpoint.

9.2 Next Actions

9.2.1 What to practice next
Q: What is a practical artifact workflow you can demonstrate in an interview? Answer.
Enable trace and screenshot capture for a small suite and intentionally introduce a failure, then
practice explaining the failure using only the artifacts. Show how you identify the last successful
state, the failing action, and the missing readiness signal. Then propose a concrete test change
that would prevent the same class of failure, such as waiting for a response or asserting a landmark
element.

27
Chapter 10

Handling Complex UI Interactions

Complex UI interactions are common interview topics because they reveal whether you know how
to synchronize with browser events. File uploads, downloads, dialogs, and multi-tab flows all require
event-driven waits rather than fixed sleeps. Playwright provides explicit APIs for these cases, and
the best answers show how to compose them cleanly. Downloads and popups must be handled with
waitForDownload and waitForPopup so the test captures the event at the moment it happens. If
you click and then try to find the popup later, you may miss the event and create intermittent
failures. Similarly, dialogs must be handled by registering a dialog listener before the action triggers
it. For interactions like drag-and-drop, hover, or complex keyboard shortcuts, reliability depends on
interacting with the right element at the right time. The practical approach is to assert visibility
and stability and to use locator-based actions rather than low-level coordinates whenever possible.
When coordinates are unavoidable, capture screenshots and keep the sequence short. A senior-level
approach also includes using these interactions sparingly. If an interaction is not part of a critical
user journey, cover it at a lower layer with API or component tests. For critical paths, build focused
tests and keep them deterministic with stable test data and explicit waits.

10.1 Interview Q&A

10.1.1 Core Concepts
Q: Why do downloads and popups require event waits, and what are the correct
Playwright patterns? Answer. Downloads and popups are asynchronous browser events that
can occur immediately after a click, so you need to register the wait before you trigger the action.
The correct pattern is [Link] or [Link] with the triggering action
inside the callback. This creates a causal relationship and prevents missing the event due to timing
differences across environments.

Q: How do you handle JavaScript dialogs reliably in Playwright tests? Answer. Register
a [Link] handler before triggering the action that opens the dialog. In the handler, assert the
dialog message if it matters and then accept or dismiss depending on the scenario. This approach
avoids hanging tests and makes dialog handling explicit and repeatable across runs.

28
Lamhot Siagian Playwright Java Interview Prep

10.1.2 Scenario-Based Questions

Q: A workflow opens a new tab for OAuth login and then redirects back. How do
you test this without leaking sessions? Answer. Use waitForPopup to capture the new
Page, perform the minimal steps needed in the popup, and then assert the main page reaches the
authenticated state. Keep both pages in the same BrowserContext if the workflow requires shared
cookies, because OAuth is usually session-based. After completion, assert the popup closed or
navigate back to a stable landmark, and keep the rest of the suite using storage state reuse for
speed.

Q: Your test downloads a CSV and must validate its contents. What is the correct
approach in CI? Answer. Use waitForDownload to capture the Download object, then save
it to a known path under the build directory. Parse the file using a stable library and assert key
columns and row counts rather than full file equality, because exports can include timestamps or
ordering changes. Attach the file to CI artifacts when the test fails so debugging includes the exact
export that was produced.

10.1.3 Practical Patterns and Code

Q: Show code that captures a download event, saves the file, and asserts a key header
exists. Answer. Capture the Download event using waitForDownload and call saveAs to persist
the file to a deterministic location. Verify file existence and then parse the first line to confirm
expected headers. This approach keeps the test deterministic and produces useful artifacts for
debugging when exports fail.
import [Link].*;
import [Link].*;
import [Link].*;

import static [Link].*;

public class DownloadCsvExample {

public static void downloadAndValidate(Page page) throws Exception {
Download download = [Link](() -> [Link]("text=Export CSV"));
Path out = [Link]("build/downloads/[Link]");
[Link]([Link]());
[Link](out);

List<String> lines = [Link](out);

assertFalse([Link](), "CSV should not be empty");
String header = [Link](0);
assertTrue([Link]("id"), "CSV header should contain ’id’");
assertTrue([Link]("name"), "CSV header should contain ’name’");
}
}

10.1.4 Pitfalls and Troubleshooting

Q: What are two common sources of flakiness in multi-tab tests, and how do you
prevent them? Answer. One source is missing the popup event because the wait is registered
after the click, so always use waitForPopup with the trigger inside the callback. Another source is

29
Lamhot Siagian Playwright Java Interview Prep

switching between pages without asserting which page is active or which URL is loaded, so add
URL and landmark assertions after each navigation. Keep event listeners scoped to the correct page
to avoid handling dialogs or downloads on the wrong tab.

10.2 Next Actions

10.2.1 What to practice next
Q: What is a compact exercise that covers popups, dialogs, and downloads in one
session? Answer. Build a demo flow where clicking a button opens a popup, the popup triggers
a confirm dialog, and completing the dialog triggers a CSV download. Write a test that registers
the dialog handler, captures the popup, and captures the download using event waits. Then parse
the CSV and assert a small set of invariants, and verify the test stays stable across repeated runs
without sleeps.

30
Chapter 11

Data-Driven Testing and Configuration

Data-driven testing is critical for covering permutations without duplicating test logic. In Java,
this often means parameterized tests plus externalized test data in JSON, YAML, or CSV. The
interview focus is usually on how you keep test data reliable, readable, and safe for CI. Configuration
is equally important. You need a single place to define base URL, timeouts, headless mode, and
environment-specific credentials. If configuration is scattered across tests, teams struggle to run
suites consistently in local, staging, and CI environments. A good approach also addresses secrets.
Credentials should come from environment variables or a secrets manager, and test logs must not
leak sensitive values. When you store storage state, treat it as a credential and manage it with the
same discipline. Finally, data management includes cleanup and idempotency. Tests should either
create unique entities and clean up, or reuse seeded data in a read-only way. In interviews, being
explicit about these policies signals you have operated large suites at scale.

11.1 Interview Q&A

11.1.1 Core Concepts
Q: What is a practical strategy for parameterized UI tests in Java without making
failures hard to interpret? Answer. Keep the test logic stable and parameterize only the
meaningful inputs, such as user role, feature flag, or form values. Ensure each parameter set has a
descriptive name so CI reports identify which case failed without opening logs. Limit parameters to
a small number per test and prefer multiple focused tests over one giant parameter matrix that is
hard to debug.

Q: How do you manage environment configuration cleanly for Playwright tests? An-
swer. Centralize configuration in a single class that reads from environment variables and supports
reasonable defaults for local runs. Expose explicit fields like baseUrl, headless, and timeout so test
code does not parse environment variables directly. Keep the configuration immutable once loaded
so parallel tests do not observe inconsistent values.

11.1.2 Scenario-Based Questions

Q: A new environment has slightly different seed data, and tests fail because hardcoded
IDs are missing. What do you change? Answer. Stop relying on hardcoded IDs and instead

31
Lamhot Siagian Playwright Java Interview Prep

locate entities by stable business keys, such as a unique name or an external reference. If the entities
truly must be present, add a setup step that provisions them via API so the test can create its
own prerequisites. Document the data contract for environments so failures are about real contract
violations rather than implicit assumptions.

Q: Your team wants to run the same suite against staging and against a developer’s local
environment. What config and data rules make this safe? Answer. Use environment-
specific base URLs and credentials loaded from environment variables, and ensure tests do not
assume shared persistent data across runs. For local runs, use isolated tenants or namespaces so
developers do not interfere with each other. For staging, use dedicated test accounts and unique
run IDs so parallel CI jobs do not collide.

11.1.3 Practical Patterns and Code

Q: Show a small configuration class and how it would be used to set base URL and
timeouts consistently. Answer. Load configuration once at process start, validate required
values, and expose typed getters. Use the configuration to create BrowserContext options consistently,
including base URL and per-action timeouts. This makes test behavior predictable and reduces
time spent debugging environment drift.
public final class TestConfig {
private final String baseUrl;
private final boolean headless;
private final double timeoutMs;

public TestConfig() {
[Link] = envOrDefault("BASE_URL", "[Link]
[Link] = [Link](envOrDefault("HEADLESS", "true"));
[Link] = [Link](envOrDefault("PW_TIMEOUT_MS", "30000"));
}

private static String envOrDefault(String key, String def) {

String v = [Link](key);
return (v == null || [Link]()) ? def : v;
}

public String baseUrl() { return baseUrl; }

public boolean headless() { return headless; }
public double timeoutMs() { return timeoutMs; }
}

11.1.4 Pitfalls and Troubleshooting

Q: What is a common failure mode with data-driven tests, and how do you keep them
maintainable? Answer. A common failure mode is a growing set of input files where nobody
knows which test uses which data, and failures become hard to trace. Keep test data co-located
with the tests that use it and name files and cases clearly, then validate data at load time with
schema checks. When a test fails, the failure output should include the dataset name and key fields
so the next engineer can reproduce quickly.

32
Lamhot Siagian Playwright Java Interview Prep

11.2 Next Actions

11.2.1 What to practice next
Q: What is a compact exercise to demonstrate data and config discipline? Answer.
Write one parameterized test that creates a unique entity using a run ID, verifies it appears in
the UI, and then deletes it in teardown. Implement a config class that reads BASE_URL and
HEADLESS and confirm the test behaves identically in local and CI runs. Finally, add a data file
for two parameter sets and confirm each case is labeled clearly in reports.

33
Chapter 12

CI/CD Integration and Reporting

CI/CD integration is where interviewers test whether you have shipped automation to real pipelines.
The goal is a suite that runs reliably, produces actionable reports, and fails with useful artifacts
rather than vague timeouts. Playwright provides strong artifact support, and Java ecosystems
provide reporting options through JUnit XML, Allure, and CI-native dashboards. A stable CI
configuration sets consistent browser dependencies, headless settings, and resource limits. It also
separates smoke suites from full regression suites so teams get fast signal on pull requests and
deeper coverage on scheduled runs. When failures happen, CI should upload traces, screenshots, and
logs automatically. Reporting is not just about pretty HTML. The best reports help a developer
reproduce the failure and identify whether the cause is test design, environment instability, or a
product regression. That means including the base URL, browser engine, commit SHA, and artifact
links per failing test. Finally, you should be prepared to discuss flaky test management. Mature
teams track flakiness rates, quarantine unstable tests temporarily, and require root-cause fixes rather
than ignoring failures. The interview-ready answer emphasizes feedback loops, not hiding problems.

12.1 Interview Q&A

12.1.1 Core Concepts
Q: What are the minimum artifacts you want from CI for failed Playwright tests,
and why? Answer. At minimum, capture a screenshot at the failure point, a trace zip for full
replay, and structured logs that include the current URL and last action. These artifacts let you
determine whether the failure was due to missing data, navigation issues, or selector instability
without rerunning locally. Add network logs or HAR capture when failures are often backend-related,
because response timing and status codes can explain many UI symptoms.

Q: How do you design a pipeline that provides fast feedback but still preserves
confidence? Answer. Run a small smoke suite on every pull request to validate critical navigation
and authentication, and run a larger regression suite on a schedule or on demand. Gate merges
on the smoke suite and on stable unit and API tests, and treat UI regression as a higher-latency
confidence check. Use consistent test tagging so suites can be selected without maintaining separate
code branches.

34
Lamhot Siagian Playwright Java Interview Prep

12.1.2 Scenario-Based Questions

Q: A test fails only on Linux runners, and developers use macOS locally. What are
common differences to check? Answer. Verify font rendering, viewport size, and system locale,
because these can affect layout and text-based selectors. Confirm headless behavior differences and
ensure the same browser channel and version are used across environments. Check resource limits
and CPU contention on Linux runners, because time-sensitive animations and network retries can
behave differently under constrained resources.

Q: Your suite has increasing flakiness. How do you implement a sustainable flake
management process? Answer. Start by measuring flakiness rate per test and per feature area,
and prioritize the worst offenders based on impact. Add automatic retries for transient failures,
but require that every flaky test has a tracked root-cause ticket and an owner. Quarantine tests
only with a clear plan and expiration, and invest in better waits, better data isolation, and better
observability rather than increasing timeouts globally.

12.1.3 Practical Patterns and Code

Q: Show a CI-friendly pattern for attaching artifacts to a test report, and explain
how you keep artifact naming collision-free under parallelism. Answer. Use a naming
convention that includes suite name, test name, timestamp, and worker identifier so parallel jobs do
not overwrite files. Save artifacts to a build folder and configure the CI pipeline to upload that folder
as an artifact. Ensure the test framework prints artifact paths in the failure output so developers
can click directly from CI logs to the evidence.
// Pseudocode pattern: keep file names unique per test.
String runId = [Link]().getOrDefault("CI_RUN_ID", [Link](System.
currentTimeMillis()));
String workerId = [Link]().getOrDefault("CI_NODE_INDEX", "0");
String safeTest = [Link]("[^a-zA-Z0-9-_]", "_");

Path screenshot = [Link]("build/artifacts/" + runId + "/" + workerId + "/" +

safeTest + ".png");
[Link]([Link]());
[Link](new [Link]().setPath(screenshot));

12.1.4 Pitfalls and Troubleshooting

Q: What is a common anti-pattern in CI reporting, and what is the correction? Answer.
A common anti-pattern is reporting only that a test failed without including steps, URLs, and
artifacts, which forces developers to rerun locally and wastes time. The correction is to make
artifacts automatic on failure and to ensure reports link to them, including trace zips for replay.
Add a short failure summary that names the readiness signal that was not met, such as a missing
response or missing landmark element.

35
Lamhot Siagian Playwright Java Interview Prep

12.2 Next Actions

12.2.1 What to practice next
Q: What is a practical CI exercise you can do to prepare for senior interviews? Answer.
Set up a GitHub Actions or Azure DevOps pipeline that runs a smoke suite on push and uploads
trace and screenshot artifacts on failures. Add test tagging to separate smoke from regression and
demonstrate selective execution. Then intentionally break a test, use artifacts to diagnose, and
document the fix so you can discuss the full feedback loop in an interview.

36