Selenium + Java interview questions

Selenium is the long-standing W3C WebDriver standard: language-agnostic, with the largest job pool, the widest browser and Grid maturity, and bindings in Java, C#, Python, Ruby and JavaScript. Playwright is the modern framework built for speed, with auto-waiting, network interception and tracing in the box, but it is JavaScript-and-TypeScript-first. They solve the same problem; Playwright removes much of the flakiness Selenium leaves you to manage with explicit waits. The honest 2026 reality is that Playwright is the default for greenfield JavaScript and TypeScript web suites, while Selenium still owns enterprise QA where Java and a mature Grid already run.

Do not pick a side and rubbish the other — interviewers read tribalism as inexperience. Lead with the fact that they solve the same problem, then split it cleanly: Selenium wins on job volume, cross-language reach and ecosystem, Playwright wins on developer experience and built-in auto-waiting. The senior signal is choosing per team and existing stack rather than by fashion.

How to phrase it

I would not frame this as one being better, because they solve the same problem in different ways. Selenium is the W3C WebDriver standard, so it is language-agnostic, it has the largest job pool, and it drives the real installed browser through a mature Grid — which is exactly why big product companies, banks and service firms still run it on Java. Playwright is the modern choice: it has auto-waiting, network interception and tracing built in, so it removes a lot of the flakiness I have to manage myself in Selenium, but it is really a JavaScript and TypeScript tool first. So my honest take for 2026 is that if I were starting a greenfield end-to-end suite with a JavaScript team, I would reach for Playwright. But if I am interviewing for a Java shop, Selenium is the correct skill, and I would maintain it where it already runs rather than rip it out. I read both, and I match the team's stack instead of pushing my favourite.

Key points to hit

• Same problem, different design — avoid tribalism, that is the junior tell.
• Selenium: W3C standard, language-agnostic, biggest job pool, mature Grid, real browsers.
• Playwright: built-in auto-waiting, tracing and interception remove a class of flakiness.
• Playwright is JavaScript-and-TypeScript-first; Selenium spans Java, C#, Python, Ruby, JS.
• 2026 reality: Playwright is the greenfield JS/TS default; Selenium owns enterprise Java QA.
• Senior move: choose per team and existing stack, not by fashion.

// Selenium 4 (Java): you manage the wait
new WebDriverWait(driver, Duration.ofSeconds(10))
    .until(ExpectedConditions.elementToBeClickable(By.id("pay")))
    .click();

// Playwright: auto-waits for actionability
// await page.getByRole('button', { name: 'Pay' }).click();

An implicit wait is a global setting that tells the driver to poll for an element's presence for up to N seconds on every findElement. An explicit wait (WebDriverWait) waits for a specific condition on a specific element, such as visibility or clickability. A fluent wait is an explicit wait with a custom polling interval and a list of ignored exceptions. The one you reach for in real frameworks is the explicit wait, because waiting for an element to be present in the DOM is not the same as waiting for it to be ready to interact with.

Lead with the rule interviewers most want to hear: never mix implicit and explicit waits. The trap to avoid is reciting three definitions and stopping there. The senior signal is naming that mixing them is a real, common bug, because the two stack unpredictably and inflate your timeouts in ways that are hard to debug.

How to phrase it

An implicit wait is a global setting — you set it once and the driver polls for an element's presence on every single findElement, up to that timeout. An explicit wait, which is WebDriverWait, waits for one specific condition on one specific element, like visibility or being clickable. A fluent wait is really just an explicit wait where I customise the polling interval and tell it which exceptions to ignore while it polls. The most important thing I would say here, because it is the rule senior teams enforce, is that I never mix implicit and explicit waits. When both are set they stack unpredictably — your ten-second explicit wait can quietly become twenty — and it produces flaky, slow tests that are miserable to debug. So in my frameworks I set no implicit wait at all, and I use an explicit WebDriverWait per condition, because waiting for present is genuinely not the same as waiting for clickable.

Key points to hit

• Implicit: global, polls for presence on every findElement up to N seconds.
• Explicit (WebDriverWait): one condition on one element — the one you actually use.
• Fluent: an explicit wait with custom polling interval and ignored exceptions.
• Golden rule: never mix implicit and explicit — they stack and inflate timeouts.
• Present is not the same as clickable — match the condition to the intent.
• Best practice: no implicit wait, explicit WebDriverWait per condition.

WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10));
wait.until(ExpectedConditions.visibilityOfElementLocated(By.id("otp")));
// Do NOT also call:
// driver.manage().timeouts().implicitlyWait(Duration.ofSeconds(10));

Thread.sleep() pauses the executing thread for a fixed time regardless of what the page is actually doing, so it is both slow and flaky. It is slow because you always pay the full duration even when the element was ready in 200 milliseconds, and flaky because if the page is slower than your guess, the element still is not there when the sleep ends. WebDriverWait polls for a real condition and continues the instant that condition is met, up to a timeout — so it is faster on average and far more reliable. Hard sleeps are the single biggest cause of slow, brittle suites.

Call Thread.sleep() what it is — a hard sleep — and frame it as the single biggest cause of slow, flaky suites. The trap is being lukewarm about it. The senior signal is saying you only ever use it as a last-resort debugging hack and never in committed tests, which separates you instantly from candidates who 'just add a sleep'.

How to phrase it

Thread.sleep is a hard sleep — it freezes the thread for a fixed number of milliseconds no matter what the page is doing. That makes it bad in two directions at once. It is slow, because if I sleep for five seconds I always pay the full five seconds even when the element was ready almost immediately, and across a big suite that dead time really adds up. And it is flaky, because if the page happens to be slower than my guess on a bad day, the element still is not there when the sleep finishes and the test fails anyway. WebDriverWait fixes both problems: it polls for an actual condition and carries on the moment that condition is true, so it is faster on average and far more deterministic. My honest position is that the only time I ever type Thread.sleep is when I am poking at something locally to debug it — it never goes into committed tests, because hard sleeps are the number one reason suites become slow and unreliable.

Key points to hit

• Thread.sleep blocks the thread for a fixed time, ignoring page state.
• Slow: you always pay the full duration even if the element was ready early.
• Flaky: if the page is slower than your guess, the element still isn't ready.
• WebDriverWait polls a real condition and continues the instant it's met.
• Hard sleeps are the single biggest cause of slow, brittle suites.
• Use it only as a local debugging hack — never in committed tests.

// Flaky and slow
Thread.sleep(5000);

// Deterministic — continues the instant the condition is met
new WebDriverWait(driver, Duration.ofSeconds(10))
    .until(ExpectedConditions.visibilityOfElementLocated(By.id("result")));

Both languages drive exactly the same WebDriver, so the browser side is identical — nothing Selenium can do changes with the language. Java is more verbose but strongly typed, fast, and dominant in large enterprise QA teams that already run TestNG, Maven and a JVM stack. Python is shorter, quicker to script, and popular with smaller teams, startups, and data-heavy testing. The choice is about the team, the existing ecosystem and who you will work alongside, not about capability.

Say the language rarely changes what Selenium can do — it changes who you work with. The trap is defending your favourite as objectively superior. The senior signal is matching the team's stack rather than your preference, and showing you can read both.

How to phrase it

Honestly, the language barely matters to Selenium itself, because both Java and Python drive the same WebDriver — the browser side is identical, so neither can do something the other cannot. What changes is who you work with and the ecosystem around you. Java is more verbose, but it is strongly typed and fast, and it dominates large enterprise QA — banks, product companies, service firms — usually with TestNG and Maven and a JVM build already in place. Python is shorter and quicker to script, and you see it more in startups, smaller teams, and data-heavy or API-heavy testing. So when someone asks which is better, I say it depends entirely on the team I am joining. I would match the existing stack rather than push my preference, and I am comfortable reading both. That kind of answer reads as maturity, because a real automation engineer optimises for the team, not for the language they happen to like most.

Key points to hit

• Same WebDriver underneath — the language doesn't change what Selenium can do.
• Java: verbose but typed and fast; dominant in enterprise QA with TestNG/Maven.
• Python: concise, quick to script; popular with startups and data-heavy testing.
• The real decision is team, ecosystem and colleagues — not capability.
• Match the existing stack rather than pushing a personal favourite.
• Being able to read both reads as senior maturity.

// Java — strongly typed, enterprise default
WebElement el = driver.findElement(By.id("user"));
el.sendKeys("sree");

// Python — same WebDriver, terser syntax
// driver.find_element(By.ID, "user").send_keys("sree")

findElement returns the first matching WebElement and throws a NoSuchElementException when nothing matches. findElements returns a List of all matching elements and returns an empty list — never an exception — when nothing matches. That single difference is why findElements is the safe way to check whether something exists: you can ask whether the list is empty without risking an exception. findElement is for the element you expect to be there; findElements is for zero-or-many and for presence checks.

Give the exception behaviour as the headline difference, because that is exactly what trips people up. The trap is stopping at 'one returns one, the other returns many'. The senior signal is the practical absence-check trick: use findElements and test the list is empty, because findElement would throw.

How to phrase it

The headline difference is what happens when nothing matches. findElement returns the first matching element, and if there is no match it throws a NoSuchElementException. findElements, plural, returns a List of every match, and crucially if there is no match it returns an empty list rather than throwing. So I use findElement when I am confident the element exists and I want to act on it. I use findElements in two situations. One, when I genuinely expect zero or many — like rows in a table, where I want to iterate. And two, and this is the part that signals real hands-on experience, when I want to assert that something is absent. I cannot use findElement for that because it would throw, so I call findElements and simply check that the returned list is empty. That empty-list pattern for presence and absence checks is the practical trick worth knowing, and it is the bit interviewers are usually fishing for.

Key points to hit

• findElement returns the first match; throws NoSuchElementException if none.
• findElements returns a List of all matches; returns an empty list if none.
• findElements never throws on no-match — that's the key behavioural difference.
• Use findElement for the element you expect; findElements for zero-or-many.
• Absence check: findElements(...).isEmpty() — findElement would throw.
• The empty-list pattern signals real hands-on experience.

// Safe presence check — never throws
boolean present = !driver.findElements(By.id("banner")).isEmpty();

// Throws NoSuchElementException if the element is missing
WebElement el = driver.findElement(By.id("banner"));

Absolute XPath walks from the document root with single slashes, like slash-html-slash-body and so on, so it encodes the entire ancestor chain. The moment any parent in that chain changes — a wrapping div is added, an order shifts — the locator breaks. Relative XPath starts with a double slash and matches anywhere in the DOM, anchored to a stable attribute or visible text rather than a fixed path. Relative XPath is far more resilient to layout changes, and writing absolute XPath is usually a sign of recording rather than understanding the DOM.

Say you almost never write absolute XPath, and frame it as a sign of recording rather than understanding the page. The trap is treating them as equal options. The senior signal is locating by intent — anchoring to a stable attribute, ideally a test id — and only walking DOM relationships when the page gives you nothing else.

How to phrase it

Absolute XPath starts at the root and spells out the whole path — slash html, slash body, slash div, and on down. Relative XPath starts with a double slash and matches anywhere in the document, anchored to something stable like an attribute or visible text. I almost never write absolute XPath, and honestly when I see it in a codebase it usually means someone recorded the test rather than understood the page, because it breaks the instant any parent in that long chain changes — somebody wraps a div, the order shifts, and the whole locator dies. What I actually do is write relative XPath anchored to a stable attribute, ideally a dedicated test id like data-test, so the locator survives a redesign. I only walk DOM relationships — parent, following-sibling, ancestor — when the page genuinely gives me nothing stable to anchor on. The principle I am demonstrating is that I locate by intent and by stable hooks, not by brittle position.

Key points to hit

• Absolute XPath encodes the full path from root — single slashes from html/body.
• It breaks the moment any ancestor in the chain changes.
• Relative XPath starts with // and matches anywhere, anchored to a stable hook.
• Absolute XPath usually signals recording rather than understanding the DOM.
• Prefer relative XPath anchored to a stable attribute, ideally a test id.
• Walk relationships (sibling/parent) only when nothing stable exists.

// Brittle — breaks if any parent changes
// /html/body/div[2]/form/input[1]

// Resilient — anchored to a stable test id
By username = By.xpath("//input[@data-test='username']");

CSS selectors are native to the browser engine, typically faster, and more readable for id, class and attribute matches. XPath is more powerful: it can traverse upward to parents and ancestors, match on visible text, and walk sibling relationships — all of which CSS cannot do. In practice CSS covers most needs cleanly, and XPath handles the awkward cases like 'the input next to the label that says Email'. On modern browsers the old 'XPath is slow' claim is largely overstated; the gap is small.

Avoid the lazy 'XPath is slow' cliché as an absolute — on modern browsers the gap is small. The trap is picking a side dogmatically. The senior signal is defaulting to CSS for clarity and speed, switching to XPath only for text matching or upward traversal, and preferring a stable test attribute over either.

How to phrase it

CSS selectors are native to the browser, so they tend to be a little faster and they read very cleanly for id, class and attribute matches — that is what I reach for by default. XPath is the more powerful of the two: it can do things CSS simply cannot, like traversing upward to a parent or ancestor, matching on visible text, and walking sibling relationships. I would push back gently on the old line that XPath is slow — on modern browsers that gap is small and rarely the thing that matters. So my rule is: default to CSS for readability and speed, and switch to XPath only when I genuinely need text matching or upward traversal, like finding the input that sits next to the label reading Email. And the answer I really want to land is that, better than either, I prefer a stable data-test attribute, because then the locator survives a redesign regardless of which selector engine I use.

Key points to hit

• CSS: native, fast, readable for id/class/attribute matches — the default.
• XPath: can traverse upward, match visible text, and walk siblings — CSS can't.
• The 'XPath is slow' line is overstated on modern browsers.
• Default to CSS; switch to XPath for text matching or upward traversal.
• Best of all: anchor on a stable data-test attribute so it survives redesigns.
• Locate by intent and stable hooks, not by selector tribalism.

// CSS — clean attribute match (default)
By css = By.cssSelector("input[data-test='username']");

// XPath — text match + sibling traversal (CSS can't)
By xpath = By.xpath("//label[text()='Email']/following-sibling::input");

Both load a URL and block until the page's load strategy is satisfied, so for a plain page load they are functionally almost identical. The difference is that navigate() exposes the browser history API — back(), forward() and refresh() — whereas driver.get() does not. In fact driver.get() is effectively a shortcut for navigate().to() without that history surface. There is no meaningful performance difference between the two.

Keep this one tight — interviewers ask it to check whether you actually read the API. The trap is inventing a performance difference; there isn't a meaningful one. The senior signal is knowing navigate() exists for back, forward and refresh, and that get() is just the shortcut without history.

How to phrase it

For a plain page load these two behave the same — both load the URL and both wait according to the page load strategy, so functionally there is no real difference there. The reason both exist is that navigate gives you the browser history API on top: back, forward and refresh. driver.get is essentially a convenience shortcut for navigate-dot-to without exposing that history surface. So in practice I use driver.get for a straightforward load, and I switch to navigate when the test actually needs to go back, go forward, or refresh the page — for example testing that a form repopulates after a back navigation. The one thing I would be careful not to claim is a performance gap, because there genuinely isn't a meaningful one. This question is really just checking that I have read the API rather than copied it, so I keep the answer short and precise.

Key points to hit

• Both load a URL and wait per the page load strategy — identical for a plain load.
• navigate() adds the history API: back(), forward(), refresh().
• driver.get() is effectively navigate().to() without history control.
• No meaningful performance difference — don't invent one.
• Use navigate() when the test needs back/forward/refresh.
• It's an API-knowledge check — keep the answer tight.

driver.get("https://example.com");          // plain load
driver.navigate().to("https://example.com");  // same load + history API
driver.navigate().back();
driver.navigate().refresh();

Plain By locators are simple fields you declare once and pass to findElement when you need them. The at-FindBy annotation with PageFactory wraps elements in lazy proxies that are initialised via initElements, so the element is located only when first used. PageFactory is older syntactic sugar; its lazy proxies can interact awkwardly with explicit waits and can hide StaleElementReferenceException. Modern Selenium guidance leans towards plain By locators with WebDriverWait because the behaviour is explicit and easier to debug.

Show you know both and have a current opinion, not just the mechanics. The trap is presenting PageFactory as the modern best practice — it is older sugar. The senior signal is naming that its lazy proxies hide StaleElementReferenceException and don't play well with explicit waits, then stating the modern lean towards plain By.

How to phrase it

Both are ways to declare the elements on a page. With plain By locators I just declare a By field once and pass it to findElement when I need it. With PageFactory I annotate a WebElement field with at-FindBy and call initElements, which wraps each element in a lazy proxy that is only located the first time I use it. PageFactory reads cleanly, and a lot of older frameworks use it, so I am comfortable with it. But my honest, current view is that I prefer plain By locators with WebDriverWait. The reason is that PageFactory's lazy proxies can interact badly with explicit waits, and they can quietly produce StaleElementReferenceException when the DOM re-renders, because the proxy is caching a reference under the hood. With plain By I keep the locator as a recipe and resolve it fresh each time, which is explicit and much easier to debug. So I would say PageFactory is fine but legacy, and modern Selenium guidance leans towards plain By — that is the up-to-date, senior take.

Key points to hit

• Plain By: a locator field you resolve with findElement when needed.
• @FindBy + PageFactory: lazy proxies initialised via initElements.
• PageFactory is older syntactic sugar, not the modern best practice.
• Its proxies can hide StaleElementReferenceException and fight explicit waits.
• Modern guidance leans to plain By + WebDriverWait — explicit and debuggable.
• Know both, but state the current preference clearly.

// PageFactory — lazy proxy
@FindBy(id = "user") WebElement user;
PageFactory.initElements(driver, this);

// Plain By — often preferred, resolve fresh each time
private final By user = By.id("user");
driver.findElement(user).sendKeys("sree");

A hard assert, like Assert.assertEquals, throws the instant it fails, which stops the test method immediately so any later checks never run. A soft assert, using TestNG's SoftAssert, records each failure and continues, then reports all collected failures together only when you call assertAll. Soft assert lets one test method verify several independent things in a single pass — but if you forget to call assertAll, every failure is silently swallowed and the test passes green.

Explain the trade-off, not just the mechanics. The trap is forgetting to mention assertAll. The senior signal is naming the classic bug — a soft assert without assertAll passes silently — and tying each style to when a failure should or should not abort the test.

How to phrase it

A hard assert throws the moment it fails, so it stops the test method dead and nothing after it runs. That is exactly what I want when a failure makes the rest of the test meaningless — if the page did not even load, there is no point checking its contents. A soft assert is different: it records each failure and keeps going, and it only reports everything together when I call assertAll at the end. I use soft asserts when I want to verify several independent things on one page in a single run — say five fields on a profile — so a tester sees all the failures at once instead of fixing one, rerunning, and finding the next. The gotcha I always call out, because it is a genuinely common bug, is that if you forget to call assertAll, the soft assert collects the failures and then never throws them, so the test passes green even though things failed. Naming that trap is usually what shows the interviewer I have actually used SoftAssert in anger rather than just read about it.

Key points to hit

• Hard assert throws immediately and stops the method — later checks don't run.
• Soft assert records failures and continues, reporting on assertAll().
• Soft assert verifies several independent things in one pass.
• Hard assert: use when a failure makes the rest of the test meaningless.
• Classic bug: SoftAssert without assertAll() passes silently.
• Naming that gotcha signals real hands-on usage.

SoftAssert sa = new SoftAssert();
sa.assertEquals(title, "Cart");
sa.assertTrue(total > 0);
sa.assertAll(); // forget this and every failure is swallowed

Both are Java test runners. TestNG was designed with end-to-end and integration testing in mind — flexible suite XML, built-in data providers, groups, dependsOnMethods and native parallel execution. JUnit 5 has closed much of that gap with extensions, parameterised tests and parallel execution, but stays leaner and remains the default for developer unit tests. For large Selenium suites TestNG's suite XML, grouping and parallelism are the practical draw; for unit testing JUnit 5 is the standard.

Don't say one is simply better. The trap is a vague 'TestNG has more features'. The senior signal is naming concrete features you have used — DataProvider, groups, the parallel attribute, suite XML — and matching each runner to its real home: TestNG for big Selenium suites, JUnit 5 for unit tests.

How to phrase it

Both are Java test runners, so I would not say one is just better — they have different homes. TestNG was built with end-to-end and integration testing in mind, and the features I actually lean on are its suite XML for organising runs, built-in DataProviders for data-driven tests, groups like smoke and regression, dependsOnMethods for ordering, and native parallel execution through the parallel attribute. That is why TestNG fits large Selenium suites so well. JUnit 5 has genuinely caught up a lot — it has extensions, parameterised tests with MethodSource, and parallel execution — but it stays leaner and it is still the default for developer unit tests. So my answer is that I default to TestNG for a big Selenium automation suite because of the suite XML, grouping and parallelism, and I would happily use JUnit 5 for unit-level testing or a smaller suite. Naming the specific features I have used lands much better than just saying TestNG has more of them.

Key points to hit

• Both are Java runners — neither is simply better; they have different homes.
• TestNG: suite XML, DataProvider, groups, dependsOnMethods, native parallelism.
• JUnit 5: extensions, @ParameterizedTest, parallel — leaner, the unit-test default.
• TestNG fits large Selenium suites; JUnit 5 fits unit tests and smaller suites.
• Cite concrete features you've used (DataProvider, groups, parallel).
• Specifics beat 'TestNG has more features'.

// TestNG: data-driven, grouped
@Test(dataProvider = "users", groups = "smoke")
public void login(String u, String p) { /* ... */ }

// JUnit 5 equivalent: @ParameterizedTest + @MethodSource("users")

Page Object Model is a design pattern: one class per page that holds that page's locators and the actions on it, keeping tests free of raw selectors. Page Factory is just one Selenium mechanism for implementing POM, using at-FindBy annotations and initElements to wire up the elements. So they are not rivals at all — Page Factory is an implementation detail of POM, and you can build a perfectly good POM with plain By locators and no Page Factory at all.

Correct the framing politely, because the question is often a deliberate trap — they are not alternatives. The trap is comparing them as peers. The senior signal is saying POM is the pattern and Page Factory is one way to wire it, plus the discipline that page classes do actions and tests do verification.

How to phrase it

I would gently reframe this one, because it is usually a trap — they are not really alternatives. Page Object Model is a design pattern: one class per page that owns that page's locators and the actions you can perform on it, so the tests stay clean and never touch raw selectors. Page Factory is just one Selenium mechanism for implementing that pattern — it uses at-FindBy annotations and initElements to populate the element fields. So Page Factory is an implementation detail of POM, not a competitor to it. In fact I can build a perfectly good Page Object Model with plain By locators and never use Page Factory at all, and given Page Factory's quirks with stale elements, that is often what I do. The other discipline I would add, because it is the real senior signal, is that I keep assertions out of my page classes — pages perform actions and return state or other pages, and the tests do the verification. That separation keeps the page objects reusable and the tests readable.

Key points to hit

• POM is a design pattern — one class per page, locators plus actions.
• Page Factory is one mechanism to implement POM (@FindBy + initElements).
• They're not rivals — Page Factory is an implementation detail of POM.
• You can build POM with plain By locators and no Page Factory.
• Reframe the trap politely instead of comparing them as peers.
• Discipline: pages do actions, tests do verification — no asserts in page classes.

class LoginPage {
  private final By user = By.id("user");
  // action returns state/next page — no assertions here
  LoginPage type(String u) { driver.findElement(user).sendKeys(u); return this; }
}

close() shuts the current browser window or tab and leaves the WebDriver session alive, so the driver process and any other windows stay open. quit() ends the entire WebDriver session, closes every window the session opened, and frees the underlying driver process. The practical consequence is that forgetting quit() leaks browser and driver processes, which pile up on CI agents and eventually exhaust the machine's memory.

State the one-line rule clearly, then add the consequence interviewers want to hear. The trap is stopping at 'close closes one, quit closes all'. The senior signal is the operational awareness: forgetting quit leaks processes on CI, so you call quit in teardown.

How to phrase it

The simple rule is that close shuts only the current window or tab and leaves the WebDriver session alive, whereas quit ends the whole session — it closes every window the session opened and, importantly, it frees the underlying driver process. So I use close when I have opened an extra window or tab and just want to drop that one and carry on, and I use quit at the very end to tear everything down. The part I would make sure to mention, because it is the operational reality interviewers are checking, is what happens if you forget quit. The browser and the chromedriver or geckodriver process keep running, and on a CI agent that runs hundreds of tests those zombie processes pile up and eventually exhaust the machine's memory, which makes the whole pipeline flaky. So I always call quit in an AfterMethod or AfterClass — wherever the lifecycle dictates — so every run cleans up after itself.

Key points to hit

• close(): shuts the current window/tab; session stays alive.
• quit(): ends the whole session, closes all windows, frees the driver process.
• Use close() to drop one window; quit() to tear everything down.
• Forgetting quit() leaks browser and driver processes.
• On CI those zombie processes pile up and exhaust the machine.
• Call quit() in @AfterMethod or @AfterClass so every run cleans up.

driver.close(); // current window only — session still alive
driver.quit();  // whole session + every window + driver process

@AfterMethod
public void tearDown() { if (driver != null) driver.quit(); }

getWindowHandle, singular, returns a single String — the id of the window currently in focus. getWindowHandles, plural, returns a Set of Strings, the ids of every window the session has open. You use the singular to remember where you started, and the plural to iterate and switch to a newly opened tab or popup. The robust workflow waits for the handle count to grow before switching, because a new window may not appear instantly.

Describe the real workflow rather than reciting two definitions. The trap is forgetting the timing. The senior signal is storing the parent handle, waiting for the handle count to grow, switching to the non-parent, and switching back — and knowing the new window isn't there instantly.

How to phrase it

getWindowHandle, the singular, returns one String — the id of the window I am currently focused on. getWindowHandles, the plural, returns a Set containing the ids of every open window. The way I actually use them is as a workflow rather than as two isolated methods. First I store the current handle in a parent variable so I remember where I started. Then I click the thing that opens a new tab or popup. Here is the bit candidates miss: the new window may not be there instantly, so I wait until the number of handles becomes two — using a wait like numberOfWindowsToBe — rather than switching immediately. Once it is there, I iterate the handles set, find the one that is not my parent, and switch to it with switchTo-dot-window. I do my work in the new window, and then I switch back to the parent handle. That store-parent, wait-for-count, switch-to-new, switch-back pattern is what shows I have handled multi-window flows for real.

Key points to hit

• getWindowHandle (singular): the id of the focused window, as a String.
• getWindowHandles (plural): a Set of all open window ids.
• Workflow: store the parent handle before opening the new window.
• Wait for the handle count to grow (numberOfWindowsToBe) before switching.
• Iterate the set, switch to the non-parent, do the work, switch back.
• The new window isn't there instantly — that timing trips people up.

String parent = driver.getWindowHandle();
new WebDriverWait(driver, Duration.ofSeconds(10))
    .until(ExpectedConditions.numberOfWindowsToBe(2));
for (String h : driver.getWindowHandles())
    if (!h.equals(parent)) driver.switchTo().window(h);
// ... work ...
driver.switchTo().window(parent);

By is a locator strategy — a description of how to find something, such as By.id of user. WebElement is the actual element object you get back once the driver resolves a By against the live DOM. By is the recipe; WebElement is the cooked result you can click or type into. The crucial behavioural difference is that a By can be declared once and reused safely, while a cached WebElement can go stale if the DOM re-renders after you resolved it.

Make the lazy-versus-resolved point, because that is what the question is really probing. The trap is just saying 'By finds it, WebElement is it'. The senior signal is explaining that you keep By locators as fields and resolve them fresh to sidestep StaleElementReferenceException.

How to phrase it

By is a locator strategy — it is just a description of how to find something, like By-dot-id of user. WebElement is what I actually get back after the driver takes that By and resolves it against the live page; it is the concrete element I can click or type into. So the mental model I use is that By is the recipe and WebElement is the cooked dish. The reason this distinction matters in practice is staleness. A By is inert — it is just instructions — so I can declare it once as a field and reuse it as many times as I like, completely safely. A WebElement, on the other hand, points at a specific node in the DOM as it was when I resolved it, so if the page re-renders that reference can go stale and throw StaleElementReferenceException. That is exactly why I tend to keep By locators as my fields and resolve them fresh right before I act, rather than caching WebElements across actions — it sidesteps a whole class of stale-element bugs.

Key points to hit

• By is a locator strategy — how to find something, e.g. By.id("user").
• WebElement is the resolved element object you can click or type into.
• By is the recipe; WebElement is the cooked result.
• A By is inert and reusable; a cached WebElement can go stale.
• Keep By locators as fields and resolve them fresh before acting.
• Doing so sidesteps a whole class of StaleElementReferenceException bugs.

By user = By.id("user");                   // strategy — reusable, never stale
WebElement el = driver.findElement(user);  // resolved — can go stale on re-render

A local WebDriver runs the browser on the same machine as the test. RemoteWebDriver sends the same commands over HTTP to a Selenium Grid (or a cloud provider like BrowserStack), where the browser actually runs. Grid lets you run many browser and OS combinations in parallel, far beyond a single laptop. Critically, the test code barely changes — you swap the driver construction to RemoteWebDriver with a URL and capabilities, so a well-built framework moves to Grid with almost no edits.

Frame it as scale and coverage, not a different way of writing tests. The trap is implying the test code changes a lot. The senior signal is portability: only the driver creation changes, so a clean framework moves to Grid with almost no edits.

How to phrase it

A local WebDriver just runs the browser on the same machine as my test, which is exactly right while I am writing and debugging. RemoteWebDriver sends the identical WebDriver commands over HTTP to a Selenium Grid, or to a cloud lab like BrowserStack, where the browser actually runs. The reason to do that is scale and coverage — Grid lets me run lots of browser and operating-system combinations in parallel, far more than one laptop could ever handle, which is how cross-browser suites run on CI. The point I really want to make, because it is what interviewers are checking, is portability. The test logic does not change at all — the only thing that changes is how I construct the driver. Instead of new ChromeDriver, I create a RemoteWebDriver pointing at the Grid URL with the capabilities I want. So if my framework is built cleanly, with driver creation behind a factory, moving the whole suite from local to Grid is almost a no-op. That ease of moving to Grid is the senior signal here.

Key points to hit

• Local WebDriver: browser runs on the same machine — good for writing/debugging.
• RemoteWebDriver: same commands over HTTP to a Grid or cloud lab.
• Grid enables many browser/OS combinations running in parallel.
• Only the driver construction changes — the test logic stays the same.
• A clean factory means moving local-to-Grid is almost a no-op.
• Portability is what the question is really checking.

// Local
// WebDriver driver = new ChromeDriver(new ChromeOptions());

// Remote — only the construction changes
WebDriver driver = new RemoteWebDriver(
    new URL("http://grid:4444/wd/hub"),
    new ChromeOptions());

Selenium 4 dropped the legacy JSON Wire Protocol and went fully W3C WebDriver, so commands talk to browsers in one standard way with less translation and less flakiness. It also added relative locators (above, below, near, toLeftOf, toRightOf), native Chrome DevTools Protocol access and BiDi for things like network and console interception, a rewritten Grid with a cleaner UI and Docker support, and a WebDriverWait that takes a Duration instead of a raw integer. The W3C standardisation is the substantive change; the rest are the headline additions.

Lead with W3C standardisation as the headline — that is the substantive change. The trap is listing only surface features. The senior signal is naming two or three concrete additions you have used (relative locators, CDP/BiDi) plus the Duration-based wait, which everyone hits on upgrade.

How to phrase it

The substantive change in Selenium 4 is that it dropped the old JSON Wire Protocol and became fully W3C WebDriver compliant. That sounds like plumbing, but it matters — commands now talk to the browser in one standardised way with less translation, which means less protocol-level flakiness. On top of that, the concrete additions I have actually used are, first, relative locators — above, below, near, toLeftOf, toRightOf — which let me locate an element by its position relative to another, handy when the DOM gives me nothing stable. Second, native Chrome DevTools Protocol and BiDi access, which I use for network interception and reading console logs. Third, a rewritten Grid with a much cleaner UI and proper Docker support. And the visible one everyone hits the moment they upgrade is that WebDriverWait now takes a Duration, like Duration-dot-ofSeconds of ten, instead of a raw integer. Mentioning that Duration change usually signals to the interviewer that I have done a real upgrade, not just read the release notes.

Key points to hit

• Headline: dropped JSON Wire Protocol, fully W3C WebDriver — less flakiness.
• Relative locators: above, below, near, toLeftOf, toRightOf.
• Native CDP and BiDi for network interception and console logs.
• Rewritten Grid with a cleaner UI and Docker support.
• WebDriverWait now takes a Duration, not a raw int — the visible upgrade hit.
• Cite features you've used to read as a doer, not a reader.

// Selenium 4: relative locator + Duration-based wait
By pwd = RelativeLocator.with(By.tagName("input")).below(By.id("user"));
new WebDriverWait(driver, Duration.ofSeconds(10))
    .until(ExpectedConditions.visibilityOfElementLocated(pwd));

Both are Java build and dependency tools. Maven uses a fixed, XML-based pom.xml with a strict, predictable lifecycle, and it is everywhere in enterprise QA. Gradle uses a Groovy or Kotlin build script, is more flexible, and is usually faster thanks to its build cache and incremental builds. For Selenium-Java work the practical detail is the test plugins: Maven runs TestNG and JUnit through the Surefire plugin (and Failsafe for integration tests), which you configure in the pom.

Say Maven's appeal is convention and ubiquity, Gradle's is speed and flexibility. The trap is being vague about how tests actually run. The senior signal is naming Surefire for running TestNG/JUnit and showing you can read both, which proves you've wired a build, not just inherited one.

How to phrase it

Both are Java build and dependency tools, so the comparison is really about style and ecosystem. Maven uses an XML pom file with a strict, predictable lifecycle, and its big appeal is convention and ubiquity — most Selenium-Java jobs you will see use Maven, so I make sure I know its lifecycle and, specifically, that tests run through the Surefire plugin, with Failsafe for integration tests. That detail matters because that is where you wire TestNG or JUnit and pass the suite XML. Gradle uses a Groovy or Kotlin script instead, it is more flexible, and it is usually faster because of its build cache and incremental compilation, so it tends to win on larger or polyglot builds. My honest position is that I default to whatever the team uses, and in practice that is usually Maven for Selenium suites. But I can read and write both, and being able to name Surefire and the Maven lifecycle tends to signal that I have actually configured a build rather than just inherited one someone else set up.

Key points to hit

• Both are Java build/dependency tools — the difference is style and ecosystem.
• Maven: XML pom, strict lifecycle, convention, ubiquitous in enterprise QA.
• Gradle: Groovy/Kotlin script, more flexible, faster via build cache.
• Maven runs TestNG/JUnit via the Surefire plugin (Failsafe for integration).
• Name Surefire and the lifecycle to show you've wired a build.
• Default to the team's tool; be able to read both.

<!-- Maven: run TestNG suite via Surefire -->
<plugin>
  <artifactId>maven-surefire-plugin</artifactId>
  <configuration>
    <suiteXmlFiles><suiteXmlFile>testng.xml</suiteXmlFile></suiteXmlFiles>
  </configuration>
</plugin>

Data-driven keeps the test logic fixed and feeds it many input sets from Excel, CSV, or a TestNG DataProvider. Keyword-driven externalises the steps themselves as keywords that non-coders can sequence in a spreadsheet, with an engine that maps each keyword to code. Hybrid combines both — reusable keyword-style actions driven by external data — which is what most real frameworks actually settle on, usually layered on top of a Page Object Model.

Position hybrid as the pragmatic answer and explain why, rather than reciting three definitions. The trap is treating keyword-driven as obviously superior. The senior signal is being honest that pure keyword-driven adds an abstraction most teams don't maintain, and stating your default design: POM, data-driven via DataProviders, with reusable utilities.

How to phrase it

Data-driven means the test logic stays fixed and I feed it many sets of inputs — from a spreadsheet, a CSV, or most often a TestNG DataProvider — so one login test runs across twenty credential combinations. Keyword-driven goes further: it externalises the steps themselves as keywords, so a non-coder can sequence actions like enterText and click in a spreadsheet, and an engine maps each keyword to code. Hybrid combines the two. Now, I would not just recite these — I would give an opinion, because that is what a senior question like this is testing. My honest view is that pure keyword-driven sounds wonderful in a proposal but adds a layer of abstraction that most teams never properly maintain, and data-driven on its own cannot express genuinely varied flows. So what I actually build, and what most strong frameworks settle on, is a Page Object Model that is data-driven through DataProviders, with a library of reusable utility actions. That is effectively hybrid, and it is my default design because it stays maintainable while still scaling across data.

Key points to hit

• Data-driven: fixed logic, many input sets (Excel/CSV/DataProvider).
• Keyword-driven: steps externalised as keywords non-coders can sequence.
• Hybrid: reusable keyword-style actions driven by external data.
• Honest take: pure keyword-driven adds abstraction teams rarely maintain.
• Most real frameworks land on hybrid, layered over a POM.
• Default design: POM + DataProviders + reusable utilities.

@DataProvider(name = "logins")
public Object[][] logins() {
  return new Object[][] {{"a", "p1"}, {"b", "p2"}};
}
@Test(dataProvider = "logins")
public void login(String u, String p) { /* fixed logic, many inputs */ }

Headed runs a visible browser window; headless runs the same browser engine with no UI rendered to a screen. Headless is faster and is the default on CI servers, which usually have no display attached at all. Headed is what you use locally to watch and debug a test. The common gotcha is that headless can behave slightly differently — particularly window size and some responsive rendering — so you set an explicit window size to avoid layout surprises.

Say you write and debug headed, then run headless on CI for speed. The trap is treating them as identical. The senior signal is flagging the real gotcha — headless can render differently, so set an explicit window size — which shows you have actually hit it.

How to phrase it

Headed execution runs a visible browser window that I can watch; headless runs the very same browser engine but without rendering any UI to a screen. My workflow is to write and debug in headed mode, because I want to see what the test is doing, and then run headless on CI. Headless is the right choice there for two reasons: it is faster, and CI build agents usually have no display attached at all, so a headed run would have nothing to render to. The gotcha I always mention, because it has actually bitten me, is that headless can behave a little differently from headed — most often around window size and some responsive layout decisions, so a test that passes locally can fail on CI when the page collapses to a mobile breakpoint. The fix is simple: I set an explicit window size, like nineteen-twenty by ten-eighty, when I launch headless, so the viewport is deterministic. Mentioning that caveat tends to show I have run real suites on CI rather than only locally.

Key points to hit

• Headed: visible window. Headless: same engine, no UI rendered.
• Headless is faster and the default on display-less CI agents.
• Headed is for local watching and debugging.
• Gotcha: headless can render differently — especially window size.
• Set an explicit window size for a deterministic viewport.
• Naming the caveat shows real CI experience.

ChromeOptions options = new ChromeOptions();
options.addArguments("--headless=new", "--window-size=1920,1080");
WebDriver driver = new ChromeDriver(options);

The page load strategy decides when driver.get and navigation calls return control to your test. Normal, the default, waits for the full load event including images and sub-resources. Eager returns once the DOM is ready — the DOMContentLoaded event — without waiting for all assets. None returns almost immediately, after the initial HTML response, leaving all synchronisation to your explicit waits. Most candidates never touch this setting, so knowing it at all is a mid-level signal.

Say you usually leave it on normal but switch to eager on heavy pages. The trap is recommending none casually. The senior signal is stressing that none puts the entire synchronisation burden on your explicit waits, so it's a deliberate choice, plus the awareness that most candidates never touch this at all.

How to phrase it

The page load strategy controls when driver.get hands control back to my test. Normal, which is the default, waits for the full load event — the DOM plus images and all the sub-resources. Eager returns earlier, as soon as the DOM is ready, on DOMContentLoaded, without waiting for every image and asset to finish. None returns almost immediately, right after the initial HTML comes back, and leaves everything else to me. In practice I leave it on normal most of the time, but on a heavy page where I do not actually need the images loaded to do my testing, switching to eager can shave real time off the suite. I would be cautious about none, though — it puts the entire synchronisation burden onto my explicit waits, so I would only use it very deliberately, knowing I have solid WebDriverWaits everywhere. Honestly, just knowing this setting exists is a bit of a differentiator, because most candidates never touch it and rely on the default without realising it can be tuned.

Key points to hit

• Strategy decides when driver.get returns control to the test.
• normal (default): waits for full load — DOM plus images and sub-resources.
• eager: returns on DOMContentLoaded, skipping remaining assets.
• none: returns after initial HTML — all sync is on your explicit waits.
• Use eager on heavy pages to save time; use none only deliberately.
• Knowing this setting exists at all is a mid-level signal.

ChromeOptions options = new ChromeOptions();
options.setPageLoadStrategy(PageLoadStrategy.EAGER);
WebDriver driver = new ChromeDriver(options);

The Actions class drives the real input devices — mouse and keyboard — for hovers, drag-and-drop, right-clicks and key chords, the way a genuine user would. JavascriptExecutor runs JavaScript directly in the page to click, scroll or set values, bypassing the UI entirely. Actions simulates a user; JavaScript reaches under the interface. The risk with a JavaScript click is that it can succeed even when a real user could not interact with the element, which hides genuine defects.

Say Actions is your default because it mirrors real interaction. The trap is reaching for JavascriptExecutor as a convenient hammer. The senior signal is naming the honest risk — a JS click can succeed where a user couldn't, masking real bugs — so you use JS only as a deliberate fallback.

How to phrase it

The Actions class drives the real input devices — it moves the mouse, does hovers, drag-and-drop, right-clicks, and keyboard chords like control-A, exactly the way a user would. JavascriptExecutor is different: it runs JavaScript straight in the page to click, scroll, or set a value, which bypasses the UI layer entirely. So my default is Actions, because it mirrors genuine user interaction, and that means my test actually exercises what a user would experience. I reach for JavascriptExecutor only as a fallback — the two honest uses are scrolling an element into view, and occasionally clicking something a normal click genuinely cannot reach. But I always call out the risk, because it is the senior point: a JavaScript click can succeed even when a real user would not be able to click the element — say it is covered by an overlay — and that means the test passes while a real defect is sitting right there, hidden. So I treat JavaScriptExecutor as a deliberate, last-resort tool, not a convenient way around a flaky click.

Key points to hit

• Actions drives real mouse/keyboard: hover, drag-drop, right-click, key chords.
• JavascriptExecutor runs JS in the page, bypassing the UI.
• Actions simulates a user; JS reaches under the interface.
• Default to Actions because it exercises real interaction.
• Use JS only as a fallback: scroll into view, or unreachable clicks.
• Risk: a JS click can succeed where a user couldn't — hiding real defects.

// Actions — real user interaction (default)
new Actions(driver).moveToElement(menu).click(item).perform();

// JS fallback — scroll into view
((JavascriptExecutor) driver).executeScript(
    "arguments[0].scrollIntoView(true);", el);

The exception means you are holding a WebElement reference that no longer points to a live node in the DOM. It happens because the page re-rendered, navigated, or removed and re-added the element after you found it — so the reference is stale even though an element that looks identical may now be on screen. The element you cached and the element now rendered are different nodes. The fix is to stop caching WebElements across DOM changes and re-locate from a By right before you use them.

Name the cause first — a cached WebElement used after a DOM change. The trap is jumping straight to a retry loop without explaining why. The senior signal is the root-cause-then-fix structure: re-locate from By, wrap in a refreshed/clickable wait, and avoid caching WebElements as a habit.

How to phrase it

StaleElementReferenceException means I am holding a WebElement reference that no longer points to a live node in the DOM. The cause is almost always that I found the element, then the page changed underneath me — it re-rendered, or navigated, or removed and re-added that element — and now my cached reference is pointing at a node that no longer exists. What is sneaky is that an element that looks identical may be on screen, but it is a brand-new node, not the one I am holding. So I lead with that root cause. The fix follows directly: do not cache WebElements across a DOM change. I keep my locators as By, which are inert, and I re-locate the element fresh right before I act on it. For extra safety I wrap the action in a wait — ExpectedConditions-dot-refreshed around elementToBeClickable — which re-finds the element if it goes stale mid-wait. And as a habit, I just avoid holding WebElement references across actions, which makes this whole class of bug largely disappear.

Key points to hit

• Cause: a cached WebElement used after the DOM re-rendered or navigated.
• The on-screen element may look identical but is a new node.
• Fix one: keep By locators and re-locate fresh right before use.
• Fix two: wrap in ExpectedConditions.refreshed(elementToBeClickable(...)).
• Habit: don't cache WebElements across actions.
• Root-cause-then-fix structure is what the interviewer wants.

wait.until(ExpectedConditions.refreshed(
    ExpectedConditions.elementToBeClickable(By.id("save"))))
    .click();

presenceOfElementLocated only checks the element exists in the DOM — it may still be hidden, zero-sized, or disabled. visibilityOfElementLocated requires it to be present and displayed, with a non-zero size and not hidden by CSS. elementToBeClickable requires it to be both visible and enabled, so it is genuinely ready to receive a click. Picking the wrong condition is a frequent flaky-test cause — for example waiting only for presence and then clicking, when the element exists but is not yet interactable.

Match the condition to the intent — that is the whole answer. The trap is using presence for everything because it succeeds first. The senior signal is naming that presence-then-click is a frequent flaky-test cause, because the element exists but is not interactable yet.

How to phrase it

These three ExpectedConditions look similar but they check progressively stronger states, and matching the right one to my intent is the whole point. presenceOfElementLocated only checks that the element exists in the DOM — it might still be invisible, zero-sized, or disabled. visibilityOfElementLocated is stronger: it needs the element to be present and actually displayed, with a non-zero size and not hidden by CSS. elementToBeClickable is stronger still — it needs the element to be visible and enabled, so it is genuinely ready to be clicked. So I use presence when I just want to confirm something rendered into the DOM, visibility before I read its text, and clickable before I click it. The mistake I specifically avoid, and the one that causes a lot of flaky tests, is waiting only for presence and then immediately clicking — the element exists, so the wait passes, but it is not interactable yet, so the click flakes. Choosing the precise condition for what I am about to do is exactly what makes the difference between a stable suite and a flaky one.

Key points to hit

• presence: exists in the DOM — may be hidden, zero-sized, or disabled.
• visibility: present and displayed, non-zero size, not CSS-hidden.
• elementToBeClickable: visible and enabled — ready for a click.
• Use presence to confirm render, visibility before reading text, clickable before clicking.
• Common flaky cause: wait for presence, then click before it's interactable.
• Matching condition to intent is what marks you out.

wait.until(ExpectedConditions.presenceOfElementLocated(By.id("x")));   // exists
wait.until(ExpectedConditions.visibilityOfElementLocated(By.id("x"))); // displayed
wait.until(ExpectedConditions.elementToBeClickable(By.id("x")));       // ready to click

Calling findElement on the driver searches the whole document. Calling findElement on an existing WebElement scopes the search to that element's subtree, so your locator only needs to be unique inside that container, not across the entire page. Nested search lets you reuse a simple relative locator across repeated components — rows in a table, cards in a list. The subtle trap is that a leading double slash in a nested XPath still searches the whole document; you need dot-double-slash to stay inside the element.

Frame nested search as how you handle repeated components — rows, cards — instead of one giant brittle XPath. The trap is the XPath scoping gotcha. The senior signal is the dot-slash-slash detail: a leading double slash in a nested XPath escapes back to the whole document.

How to phrase it

When I call findElement on the driver, it searches the entire document. When I call findElement on an existing WebElement instead, it scopes the search to that element's subtree — so my locator only has to be unique inside that container, not across the whole page. That is incredibly useful for repeated components. The classic example is a table: I find the row I want first, then I search inside that row for a particular cell, instead of writing one enormous brittle XPath that tries to express the row and the cell in a single expression. Same idea for cards in a list. The subtle trap I always flag, because it catches people out and shows real DOM experience, is XPath scoping. If I do a nested findElement but my XPath starts with a plain double slash, it actually jumps back out and searches the whole document again, ignoring the scoping. To stay inside the element I have to start the XPath with dot-double-slash. That dot is what keeps the search relative to the container, and getting that right is the difference between a clean nested locator and a confusing bug.

Key points to hit

• findElement on driver searches the whole document.
• findElement on a WebElement scopes to that element's subtree.
• Locator only needs to be unique inside the container, not page-wide.
• Use it for repeated components — table rows, list cards.
• Trap: a leading // in a nested XPath still searches the whole document.
• Use .// to stay scoped inside the element.

WebElement row = driver.findElement(By.id("row-7"));
// .// stays inside the row; // would escape to the whole document
WebElement price = row.findElement(By.xpath(".//td[@class='price']"));