USA
Canada
UK
Europe
Australia
Singapore
Japan
IndiaQ1. What are the different types of waits in Selenium?
Short answer: Implicit, explicit and fluent waits; prefer explicit for reliability.
Strong answer: Implicit wait sets a global polling timeout for element presence. Explicit wait (WebDriverWait + ExpectedConditions) waits for a specific condition on a specific element — the preferred, precise approach. Fluent wait adds custom polling/ignored exceptions. Avoid Thread.sleep and don’t mix implicit and explicit waits (unpredictable timeouts).
Likely follow-up: Why avoid mixing implicit and explicit waits?
What the interviewer is checking: Reliability fundamentals.
Common mistake: Using Thread.sleep instead of explicit waits.
Q2. What locator strategies does Selenium support and which are best?
Short answer: id/name/CSS/XPath/linkText; prefer stable id or CSS selectors.
Strong answer: Selenium locates elements by id, name, className, tagName, linkText, CSS selector and XPath. Prefer stable, unique locators — ideally id or a good CSS selector; use XPath when you need traversal (parent/sibling) or text matching. Avoid brittle absolute XPaths and index-based locators.
Likely follow-up: When is XPath justified over CSS?
What the interviewer is checking: Locator best practice.
Common mistake: Using long absolute XPaths that break on any DOM change.
Q3. What is the Page Object Model in Selenium?
Short answer: A pattern encapsulating page elements and actions in classes.
Strong answer: POM represents each page/component as a class holding its locators and interaction methods, separating test logic from UI details. When the UI changes, you update one page object rather than many tests. It improves readability, reuse and maintainability — the standard Selenium framework pattern.
Likely follow-up: How does POM reduce maintenance cost?
What the interviewer is checking: Framework knowledge.
Common mistake: Scattering locators throughout test methods.
Q4. How do you handle dynamic elements and AJAX in Selenium?
Short answer: Use explicit waits for the specific condition, with robust locators.
Strong answer: For elements that load/change asynchronously, use explicit waits on conditions like visibility, clickability or presence, targeting stable attributes rather than volatile ones. Avoid fixed sleeps. For content loaded via AJAX, wait for the specific element/state you need before interacting.
Likely follow-up: What ExpectedCondition would you wait on before clicking?
What the interviewer is checking: Handling real web apps.
Common mistake: Fixed sleeps that are either too short (flaky) or too long (slow).
Q5. How do you run Selenium tests across browsers and in parallel?
Short answer: Use WebDriver for each browser and a grid/cloud plus a parallel-capable runner.
Strong answer: Selenium supports multiple browsers via their drivers. For cross-browser and parallel execution, use Selenium Grid (or a cloud like BrowserStack) and a test runner/framework that runs threads/instances in parallel (TestNG, pytest-xdist). Ensure tests are independent and thread-safe (no shared driver state).
Likely follow-up: What must be true of tests to run them in parallel safely?
What the interviewer is checking: Scaling test execution.
Common mistake: Sharing a single WebDriver instance across parallel tests.
Q6. What are common reasons Selenium tests are flaky?
Short answer: Timing, unstable locators, test data and environment issues.
Strong answer: Flakiness comes from improper waits (timing), brittle locators, order/data dependencies, and unstable environments. Fix with explicit waits, stable locators, independent tests with controlled data, and reliable environments. Capture screenshots/logs on failure to diagnose. Retries mask but don’t fix the cause.
Likely follow-up: How would you diagnose an intermittently failing test?
What the interviewer is checking: Debugging skill.
Common mistake: Accepting flakiness as normal.