1. What is the difference between implicit and explicit waits in Selenium?
Answer
Implicit applies a global polling timeout to element lookups; explicit waits for a specific condition at a specific place
Correct. An implicit wait makes every findElement retry up to N seconds. An explicit wait (driver.wait + until) targets one condition, like visibility or a URL change.
Professional answer: prefer explicit waits for specific conditions; avoid mixing them with implicit waits; never use fixed sleeps for synchronization.
Why the other answers are wrong
- They are two names for the same feature. They behave differently and mixing them can produce unpredictable total wait times.
- Explicit waits are always exactly 10 seconds. You choose the timeout for every explicit wait.
- Implicit waits pause the whole test script unconditionally. That describes a sleep. Implicit waits only apply while an element is not yet found.
2. What is the difference between driver.close() and driver.quit()?
Answer
close() closes the current window; quit() ends the whole session and all windows
Correct. Forgetting quit() leaves browser sessions running. A classic interview detail.
close() = one window. quit() = the entire WebDriver session. Always quit() in test teardown.
Why the other answers are wrong
- They are identical. With multiple windows the difference is very visible: close() leaves the session alive.
- quit() only works in headless mode. quit() works in every mode.
- close() deletes cookies, quit() does not. Cookie handling is separate (driver.manage().deleteAllCookies()).
3. How do you correctly wait for a success message that appears ~1 second after clicking Save?
Answer
driver.wait(until.elementLocated(By.css('.toast')), 5000)
Correct. An explicit wait continues the moment the toast appears and fails clearly if it never does.
Selenium requires you to express waiting explicitly. until.elementLocated / elementIsVisible with a sensible timeout is the professional pattern.
Why the other answers are wrong
- driver.sleep(1000) right after the click. On a slow run 1 second is not enough; on a fast run it wastes time. Sleeps are the top source of flaky Selenium suites.
- A while(true) loop calling findElement with no timeout. A loop with no timeout can hang forever, and it sends constant requests to the driver.
- Assert immediately, Selenium waits automatically like Playwright. Classic Selenium does not auto-wait for conditions; that is exactly why explicit waits exist.
4. What is the difference between driver.sleep(2000) and driver.wait(until.elementLocated(...), 2000)?
Answer
sleep always waits the full time; wait polls the condition and continues the moment it holds
Correct. The explicit wait is faster when the app is fast and only fails when the condition truly never holds.
Wait for what you expect, never for an amount of time. In Selenium that means driver.wait with an until condition.
Why the other answers are wrong
- They are interchangeable. One waits on a clock, the other on a condition. That difference decides whether a suite is stable.
- sleep is more reliable because it always waits. On a slow run the fixed time is still too short. Waiting for the condition cannot be too short or too long.
- wait blocks other tests from running. It blocks only the current test while polling, the same as sleep does.
5. A test throws NoSuchElementException. What does it mean?
Answer
findElement found no match at that moment. The selector is wrong, or the element was not there yet
Correct. Check the selector first; if it is right, the lookup ran too early and needs an explicit wait.
Two causes, in order of likelihood: wrong selector, or right selector too early. Verify the selector before adding waits.
Why the other answers are wrong
- The browser crashed. A crash ends the session with a different error. This is a failed lookup.
- The element exists but is disabled. A disabled element is still found. This exception means nothing matched at all.
- Selenium is not installed correctly. Installation problems fail before any lookup runs.
6. Where do assertions come from in a Selenium test?
Answer
From a separate library like Node's assert or Chai, Selenium only drives the browser
Correct. Selenium reads and acts on the page; proving values is your assertion library's job.
Pattern: read with getText()/findElements, then assert with your library. Selenium drives; assert proves.
Why the other answers are wrong
- Selenium has driver.assert built in. There is no built-in assertion API in WebDriver.
- Assertions are not needed in Selenium tests. Without assertions the test proves nothing. You always assert on what you read from the page.
- The browser asserts automatically on errors. Browser errors are not test assertions. You must state what should be true.
7. What is the difference between until.elementLocated and until.elementIsVisible?
Answer
Located means it exists in the DOM; visible means it is also displayed to the user
Correct. An element can exist while hidden. Wait for visibility when the user is supposed to see it.
Choose the condition that matches the claim: 'it is in the DOM' vs 'the user can see it'.
Why the other answers are wrong
- They are the same check. Existence and visibility differ, hidden elements are located but not visible.
- elementIsVisible also clicks the element. Wait conditions never act. They only wait.
- elementLocated only works with XPath. Both accept any locator strategy.
8. A search should narrow a table to exactly one row, after a short delay. How do you wait for that?
Answer
driver.wait with a custom condition that returns the rows only when rows.length === 1
Correct. driver.wait accepts any function; returning null/false keeps polling until the count is right.
driver.wait(async () => { const rows = await driver.findElements(...); return rows.length === 1 ? rows : null; }, 5000), wait for the exact state you will assert.
Why the other answers are wrong
- driver.sleep(1000) then count the rows. A fixed sleep is a guess, too short on a slow run, wasted time on a fast one.
- Count the rows immediately after typing. The filter needs a moment. Counting immediately races the app.
- Refresh the page until the count changes. Refreshing resets the filter. Wait for the condition on the current page.