Q1 of 37 · Selenium

What are the different types of waits in Selenium?

SeleniumJuniorseleniumwaitsfundamentals

Short answer

Short answer: Implicit waits set a global polling timeout for findElement; explicit waits poll for a specific condition; fluent waits add custom polling and ignored exceptions. Use explicit waits — implicit waits compound silently and are widely considered an anti-pattern.

Detail

Selenium ships three waiting mechanisms with very different ergonomics.

Implicit waitdriver.manage().timeouts().implicitlyWait(...). A global setting that tells the driver "if you can't find an element, keep polling for up to N seconds." It feels convenient but it's a trap: it interacts badly with explicit waits (timeouts can stack), it makes "element not found" failures take much longer, and it doesn't help with conditions that aren't "is the element present?". Most teams set it to zero and never use it.

Explicit waitnew WebDriverWait(driver, Duration.ofSeconds(10)).until(ExpectedConditions.elementToBeClickable(...)). You pick the condition (visible, clickable, text matches, custom function), and Selenium polls until it's met or times out. This is the right tool for almost every case.

Fluent wait — a configurable Wait<T> where you set polling interval, timeout, and which exceptions to ignore (NoSuchElementException, StaleElementReferenceException). It's an explicit wait with finer-grained control — useful when you need to retry through transient stale-element errors.

The interview-worthy point: never use Thread.sleep in tests, and never combine implicit and explicit waits. Both lead to slow, flaky suites that nobody trusts.

// EXAMPLE

ExplicitWait.java

import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.support.ui.ExpectedConditions;
import org.openqa.selenium.support.ui.WebDriverWait;

import java.time.Duration;

public class CheckoutTest {
    public void clickPayWhenReady(WebDriver driver) {
        WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10));

        // Wait for the button to be clickable, not just present
        WebElement payButton = wait.until(
            ExpectedConditions.elementToBeClickable(By.cssSelector("[data-test=pay]"))
        );

        payButton.click();

        // Wait for the success heading
        wait.until(ExpectedConditions.textToBePresentInElementLocated(
            By.tagName("h1"), "Order confirmed"
        ));
    }
}

// MODEL ANSWER

Selenium gives you three waiting mechanisms. Implicit wait is a global driver setting that tells the driver to keep polling for an element for up to N seconds before throwing. It looks convenient but it is a trap: it interacts badly with explicit waits, creates effective timeouts nobody intended, and only helps with element presence — not more nuanced conditions. Explicit wait is the right tool for almost everything. You create a WebDriverWait with a timeout and specify the condition — elementToBeClickable, textToBePresentInElement, invisibilityOf, or a custom lambda — and the driver polls until it is met or times out. Fluent wait is explicit wait with finer control: you set the polling interval and declare which exceptions to ignore, which is useful when you are fighting intermittent StaleElementReferenceException on a dynamic page. My recommendation: set implicit wait to zero and leave it there, use explicit wait everywhere, reach for fluent wait only for stale-element scenarios, and never Thread.sleep — that is a fixed delay that makes tests slow on fast machines and still flaky on slow ones.

// WHAT INTERVIEWERS LOOK FOR

Knowing all three types and articulating why explicit waits should be the default. Strong candidates explicitly warn against mixing implicit and explicit waits.

// COMMON PITFALL

Using Thread.sleep, or combining a 10-second implicit wait with a 10-second explicit wait and ending up with an effective 20-second timeout that nobody understands.