// Interview Prep/Mock Interviews/Selenium + Java mock interview

☕ Selenium + Java mock interview

Set a timer, work through each round out loud, then score your answers against the rubric. No one is listening — the goal is honest self-assessment, not a perfect performance.

Mid⏱ 45 min·Automation QA, SDET

// ROUND STRUCTURE

  1. 1
    Warm-up— 5 min

    Intro, current Selenium version and stack, project overview.

  2. 2
    Java fundamentals for testing— 12 min

    OOP pillars, collections, exceptions, generics as they apply to test code.

  3. 3
    Selenium WebDriver in depth— 15 min

    Driver architecture, locators, synchronisation, Actions class, JS executor.

  4. 4
    Framework design— 8 min

    TestNG annotations, Maven lifecycle, reporting, CI integration.

  5. 5
    Wrap-up— 5 min

    Candidate questions and interviewer summary.

// INTERVIEW QUESTIONS

  1. 01

    What are the four pillars of OOP? Give a concrete testing-relevant example for each.

  2. 02

    Explain how Selenium WebDriver communicates with the browser under the hood.

  3. 03

    What is the difference between findElement() and findElements()? What happens when findElement() cannot find an element?

  4. 04

    How do you handle a dropdown that is NOT a native HTML <select> element?

  5. 05

    What synchronisation strategies do you use in Selenium? When do you choose each?

  6. 06

    How do you implement the Page Object Model in Java? Walk me through the class structure.

  7. 07

    Walk me through how you'd handle a file upload dialog in an automated test.

  8. 08

    What is TestNG's @DataProvider annotation? How have you used it?

  9. 09

    A test passes locally but fails consistently in CI. What are the first three things you investigate?

// EXPECTED ANSWER POINTS

Compare your answers to these points — one per question, in order.

  1. Encapsulation: BasePage hides WebDriver instance; tests call methods, not driver directly. Inheritance: LoginPage extends BasePage, reusing driver and wait utilities. Polymorphism: different page implementations share a common interface (e.g., Clickable). Abstraction: Page Object hides element interaction details — tests call login(user, pass), not findElement(By.id('user')).sendKeys(user).

  2. WebDriver sends HTTP commands to a browser-specific driver executable (ChromeDriver, GeckoDriver) via the W3C WebDriver protocol (REST-like JSON wire protocol over localhost). The driver translates these into native browser commands. This is why driver version must match browser version.

  3. findElement(By) returns the first matching WebElement; throws NoSuchElementException if not found — test fails immediately. findElements(By) returns a List<WebElement>; returns an empty list if nothing is found — no exception. Use findElements when you need to handle zero-match gracefully (e.g., checking if an element is absent).

  4. Custom dropdown: (1) click the trigger element to open the options list, (2) wait for options to be visible (explicit wait), (3) find the desired option by text or data attribute, (4) click it. May need Actions.moveToElement() for hover-triggered dropdowns, or scrollIntoView via JS executor for long lists.

  5. Implicit wait: set once on driver, applies globally to every findElement call, poor for explicit absence checks. Explicit wait (WebDriverWait + ExpectedConditions): preferred — targets a specific element with a specific condition. Fluent wait: like explicit but configures polling interval and ignores specific exceptions. Thread.sleep: never use — introduces arbitrary delays and hides real issues.

  6. BasePage: constructor takes WebDriver, instantiates PageFactory.initElements(), has protected helper methods (waitForClickable, waitForVisible). Child pages (LoginPage, HomePage): extend BasePage, declare @FindBy fields, expose action methods that return Page Objects for fluent chaining. Tests only interact with page methods — never with WebDriver directly.

  7. For <input type='file'>: use element.sendKeys('/absolute/path/to/file.pdf') — no dialog appears, Selenium types the path directly. For native OS dialogs (non-HTML): use Robot class for keyboard interaction, or AutoIt/Sikuli for OS-level dialog handling. Verify upload by checking the file name appears in the UI after upload.

  8. @DataProvider returns Object[][] — each row is a set of test method parameters. Enables parameterised tests without duplicating test methods. Used for: boundary values on numeric inputs, multiple credential combinations for login, multiple browsers via a data-driven browser factory. Annotate the method with @DataProvider(name='data') and reference it in @Test(dataProvider='data').

  9. (1) Headless vs headed mode — some elements behave differently without a visible window; check if the test runs headless in CI. (2) Screen resolution / window size — elements may be off-screen or overlapping at different resolutions; set explicit window size in driver setup. (3) Timing — CI machines are slower; check if explicit waits are too short or if there's a missing wait for a CI-specific latency.

// SCORING RUBRIC

Strong (4–5)

Explains all four OOP pillars with test-specific examples. Knows the WebDriver W3C protocol. Correctly describes findElement vs findElements exception behaviour. Has implemented POM from scratch and can walk through class structure. Knows TestNG lifecycle annotations and Maven phases.

Acceptable (3)

Knows WebDriver basics and POM concepts. Can write a page class but is fuzzy on BasePage design. Prefers explicit over implicit waits but cannot explain Fluent wait. TestNG knowledge is surface level.

Weak (1–2)

Confuses findElement and findElements return behaviour. Uses Thread.sleep as primary wait. Cannot walk through OOP pillars with examples. No knowledge of TestNG annotations beyond @Test.

// RED FLAGS

Answers or behaviours that signal a weak candidate to the interviewer.

  • Confuses findElement (throws on miss) with findElements (returns empty list).

  • Cannot explain how WebDriver communicates with the browser.

  • Uses Thread.sleep as the primary synchronisation strategy.

  • Cannot write a Page Object class from scratch — only used generated code.

  • Cannot explain what @DataProvider does or why you'd use it.

  • Has no strategy for handling custom (non-native) dropdowns.

// FOLLOW-UP QUESTIONS

Questions a strong interviewer adds if you answered the main round well.

  1. 01

    How would you implement a base test class to avoid driver setup and teardown duplication across tests?

  2. 02

    How do you capture a screenshot on test failure and attach it to a TestNG report?

  3. 03

    What is the difference between soft assertions (SoftAssert) and hard assertions in TestNG?

// SELF-ASSESSMENT CHECKLIST

Tick these off mentally after the mock. Be honest — this is for you, not for the interviewer.

  • I gave a testing-relevant example for all four OOP pillars — not just definitions.
  • I correctly described what findElement does when the element is not found (throws NoSuchElementException).
  • I explained Implicit vs Explicit waits with a clear preference and reasoning.
  • I described POM in Java with a concrete class/method structure including BasePage.
  • I gave a real approach to handling non-native dropdowns.
  • I listed three specific CI failure investigation steps beyond 'it works locally.'

// RECOMMENDED NEXT MOCK

🤖 Automation QA mock interview

Mid · 45 min

// STUDY THESE NEXT

Automation QA role track →SDET role track →Automation QA prep plan →All question banks →