Selenium interview questions — the ones that separate "wrote a script" from "maintained a suite"

Selenium interviews have a tell: ask "how do you locate an element" and almost everyone answers correctly. Ask "your test passed locally and failed in CI, why" and the room splits in two. The first question checks whether you've used Selenium. The second checks whether you've maintained a suite someone else depends on.

Explicit vs implicit waits — the question with a real production cost

What gets recited: implicit wait sets a default timeout for the whole driver; explicit wait waits for a specific condition on a specific element.

What actually gets tested: "Why do most teams avoid implicit waits entirely?" The honest answer is that mixing implicit and explicit waits in the same test produces unpredictable total wait times — WebDriver's behaviour when both are set is not what most people expect, and debugging a test that intermittently waits far longer than either timeout suggests is a real, documented pain point. The stronger answer isn't "implicit waits are slower," it's "mixing them creates a specific, hard-to-diagnose bug class, so most style guides say pick one strategy — usually explicit — and stay consistent."

Locator strategy — not "which one," but "which one breaks first"

Candidates list ID, class name, CSS selector, XPath as if they're interchangeable. The interviewer is listening for whether you know their failure modes. An ID is fastest and most stable, but frontend teams don't always guarantee IDs stay constant. XPath can select almost anything, including by visible text, but is the most brittle against layout changes and the slowest to evaluate. The answer that shows real experience: "I default to CSS selectors with data attributes the dev team adds specifically for testing — data-testid — because they're stable across redesigns and don't couple the test to styling classes that change for unrelated reasons."

Flaky tests — the question every QA automation interview eventually asks

"How do you handle a flaky test" separates people who patch symptoms from people who diagnose causes. The weak answer is "add a retry" or "add a sleep." The strong answer identifies the actual categories: a race condition against an async page load (fix: proper explicit waits on the right condition, not a fixed sleep), test interdependence (fix: tests that don't rely on execution order or shared state), or environment instability (fix: isolate what you can, and separate "flaky because of our test" from "flaky because of infrastructure" before deciding what to fix).

Page Object Model — the "why" behind a pattern everyone name-drops

Everyone says "I use Page Object Model" in an interview. Few can explain the actual problem it solves without being asked. If ten tests all click the same "submit" button using its raw selector, one frontend change breaks ten tests in ten places. A Page Object centralises the selector in one class, so a UI change means updating one method, not hunting through the suite. The interviewer isn't checking whether you've heard of the pattern — everyone has — they're checking whether you can explain the maintenance cost it eliminates.

Why "it worked on my machine" is the actual final question

Local-vs-CI failures are the most common real-world Selenium problem, and interviewers know it. Common causes worth having ready: a different browser version or headless mode behaving differently than a visible browser, timing differences under CI's typically slower and more loaded environment, and window size or screen resolution differences affecting whether an element is considered "visible" and therefore clickable. Naming these specifically, rather than saying "it's an environment issue," is what shows you've actually chased this bug before.

---

If you want to practice QA automation questions with real follow-ups instead of a static list, try role-specific mock interviews for QA Automation — free to start.