Selenium interviews test two things: whether you can write stable UI tests (waits, locators, page objects) and whether you can design a framework a team can live with (structure, data, reporting, running in CI). Flaky tests are the topic that comes up most, because everyone who has used Selenium has fought them.
Below are 24 questions with answers. Examples use Java and Python syntax where code helps, and the ideas apply in any language.
Basics
1. What is Selenium, and what are its components?
Selenium is an open source suite for automating web browsers. Selenium WebDriver controls browsers through their drivers and is the part most people mean. Selenium Grid runs tests in parallel on many machines and browsers. Selenium IDE is a record and playback extension. Selenium doesn't handle desktop apps or built-in test reporting, so you combine it with a test framework.
2. How does WebDriver work?
Your test sends commands using the W3C WebDriver protocol over HTTP to a browser driver such as ChromeDriver or GeckoDriver, which controls the browser and returns results. Recent Selenium versions include Selenium Manager, which finds and downloads the right driver.
3. What locators does Selenium support, and which do you prefer?
ID, name, class name, tag name, link text, partial link text, CSS selector, and XPath. Prefer a stable ID or a dedicated test attribute such as data-testid, then CSS. Use XPath when you must move up the tree or match text. Avoid long, position-based paths like /html/body/div[3]/div[2], which break when the layout changes.
4. What's the difference between findElement and findElements?
findElement returns the first match and throws NoSuchElementException if there is none. findElements returns a list, which is empty if nothing matches, so it's useful for checking that something is not present.
5. What's the difference between driver.close() and driver.quit()?
close() closes the current window. quit() closes all windows and ends the session. Use quit() in teardown so no browser processes are left behind.
Waits and flaky tests
6. What are the types of waits?
| Wait | How it works |
|---|---|
| Implicit | A global timeout for finding elements |
| Explicit | Waits for a specific condition on a specific element |
| Fluent | An explicit wait with custom polling interval and ignored exceptions |
WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10));
WebElement button = wait.until(ExpectedConditions.elementToBeClickable(By.id("submit")));
Prefer explicit waits. Mixing implicit and explicit waits can cause unpredictable delays.
7. Why shouldn't you use Thread.sleep?
It always waits the full time, slowing the suite, and it's still too short on a slow day. A condition-based wait continues as soon as the condition is met and fails with a clear message otherwise.
8. What causes flaky tests, and how do you fix them?
Common causes and fixes:
- Timing: use explicit waits for the exact condition, not sleeps.
- Shared or leftover data: create test data per test and clean it up.
- Dependence between tests: make each test independent and runnable alone.
- Unstable locators: add test IDs and avoid position-based paths.
- Animations and overlays: wait for the overlay to disappear or disable animations in the test environment.
- Environment problems: stabilize the test environment, and check network and third-party calls.
- Parallel interference: isolate state per thread.
Quarantine a flaky test so it doesn't block everyone, then fix it properly. Don't just add retries everywhere, since that hides real bugs.
9. What is StaleElementReferenceException?
The element you found is no longer attached to the page, usually because the page re-rendered. Fix it by locating the element again just before use, or by waiting for the new element, rather than holding references for a long time.
10. How do you handle elements that aren't clickable (ElementClickInterceptedException)?
Something covers the element, such as a banner or a loading overlay. Wait for the overlay to go, scroll the element into view, or close the banner. Using a JavaScript click should be a last resort, because a real user couldn't click it and the test would hide a real bug.
Handling page features
11. How do you handle dropdowns, alerts, frames, and windows?
- Dropdowns: the Select class for standard select elements, and click-based steps for custom dropdowns.
- Alerts: driver.switchTo().alert() to accept, dismiss, or read.
- Frames: switchTo().frame(...) and back to defaultContent().
- Windows and tabs: get window handles, switch to the new one, and switch back.
12. How do you handle file uploads and downloads?
For uploads, send the file path to the input type="file" element with sendKeys. For downloads, set the browser's download directory in the options and wait for the file to appear, then check its name and contents.
13. How do you run JavaScript in Selenium?
Through JavascriptExecutor.executeScript, for example to scroll or read a value the API can't reach. Use it sparingly.
14. What is headless mode?
The browser runs without a visible window, which is faster and works on servers and CI. Verify with a visible run when debugging, and check the viewport size, because layouts can differ.
Framework design
15. What is the Page Object Model?
Each page or component is a class that holds its locators and the actions on it. Tests call methods such as loginPage.loginAs(user) and don't touch locators directly. When the UI changes, you fix one class instead of many tests.
class LoginPage:
def __init__(self, driver):
self.driver = driver
def login_as(self, user, password):
self.driver.find_element(By.ID, "user").send_keys(user)
self.driver.find_element(By.ID, "pass").send_keys(password)
self.driver.find_element(By.ID, "submit").click()
16. What does a good test framework contain?
A test runner (TestNG, JUnit, pytest), page objects, a driver factory for different browsers, configuration per environment, test data management, helpers for waits, reporting, logging, screenshots on failure, and CI integration.
17. How do you manage test data?
Create the data a test needs through an API or database setup at the start, not through the UI, and remove it afterward. Keep data in files or builders, not hard-coded in tests, and avoid tests that rely on data left by another test.
18. How do you run tests in parallel?
Use the runner's parallel feature, give each thread its own driver (for example with ThreadLocal), keep tests independent, and run on Selenium Grid or a cloud browser service to scale across browsers.
19. What is Selenium Grid?
A system with a hub and nodes (or a distributed setup in Grid 4) that runs tests on different browsers and operating systems in parallel. It reduces total run time and lets you cover more browsers.
Strategy and scenarios
20. What should you automate with Selenium, and what shouldn't you?
Automate stable, high-value, repeatable flows such as login, checkout, and critical regression paths. Don't automate one-off checks, frequently changing UI, or things better tested lower down. A healthy suite has many unit and API tests, fewer UI tests, and a small set of end-to-end flows.
21. How do you test an application that has a captcha or two-factor login?
Don't try to defeat them in the test. Use a test environment where they're disabled, a test account with a fixed code or a bypass flag, or a test API to create a session.
22. A test passes locally but fails in CI. What do you check?
Browser and driver versions, screen size and headless differences, timing on slower machines, environment data, network access, time zones and locale, and parallel runs sharing data. Capture screenshots, page source, and logs on failure to compare.
23. How do you decide between Selenium, Playwright, and Cypress?
Selenium supports many languages and browsers and has a huge ecosystem. Playwright and Cypress offer built-in waiting, easier setup, and good debugging tools, and may suit new projects better. The right choice depends on language, browser needs, and team skills. Give your reasons, not a brand preference.
24. Walk me through automating a checkout flow.
"I'd create a user and a product through the API, then log in through the UI or reuse a session. A page object for each step: search, product, cart, and payment. I'd use a test payment method, wait for the confirmation element, verify the order through the UI and the API, and take a screenshot on failure. The test would clean up its order, run in parallel, and run in the pipeline on every merge."
How to prepare
Write a small suite for a demo site with page objects, explicit waits, screenshots on failure, and a CI run. Practice explaining how you fixed a flaky test, with the cause and the change. Be ready to code a locator and a wait live. See our coding interview assistant guide for practice routines and the behavioral interview guide for the soft-skills round.
Say your answers aloud, and read a transcript for vague parts such as "just add a wait." Follow the employer's rules on AI tools in any live interview.
Practice Selenium interview answers with YesToTheOffer
Run a mock technical interview, explain your framework out loud, and review your transcript afterward. 30 free minutes, no subscription.
