Mock Interview Walkthrough

A: Strong answer: "An abstract class can have both abstract and concrete methods, constructors, and instance variables. A class can extend only one abstract class. An interface defines a contract — all methods were abstract before Java 8, now it can have default methods. A class can implement multiple interfaces. In my framework, BasePage is an abstract class with concrete methods like click() and type(), plus an abstract method isPageLoaded() that each page must implement. I use interfaces for contracts like WebDriver — ChromeDriver and FirefoxDriver both implement it, which is why my tests are browser-agnostic."

A: Strong answer: "HashMap stores key-value pairs with O(1) average lookup. I use it for test data — Map<String, String> data with keys like username and password. My ExcelReader returns List<Map<String, String>> where each map is a row with column headers as keys. I also use HashMap in ConfigReader to cache properties and in BrowserFactory internally for mapping browser names to capabilities. Key points: allows one null key, not ordered (use LinkedHashMap for order), not thread-safe (use ConcurrentHashMap for parallel execution)."

A: Strong answer: "Dynamic elements have attributes that change on every page load, like id=user_12345. I handle them with: (1) Partial CSS matching — [id*=user_] matches any id containing user_. (2) XPath contains() — //div[contains(@id, 'user_')]. (3) Stable parent approach — find a stable ancestor and navigate: //div[@class='user-panel']//input. (4) I asked the dev team to add data-testid attributes to key elements, which eliminated 80% of our dynamic locator problems. This is always the best long-term solution. (5) For React apps, I use the component structure rather than generated class names."

A: Strong answer: "Implicit wait is a global timeout for all findElement calls — it only checks if the element exists in the DOM, not if it is visible or clickable. Explicit wait targets a specific element with a specific condition — visibilityOfElementLocated, elementToBeClickable, textToBePresentInElement. I use ONLY explicit waits because: (1) They are more precise — I can wait for the exact condition I need. (2) Mixing implicit and explicit causes unpredictable behavior — Selenium documentation warns against this. (3) My BasePage wraps all waits in methods like waitForVisible() and waitForClickable() so test code stays clean. I never use Thread.sleep."

A: Strong answer: "My framework has 6 layers: (1) Test Layer — TestNG test classes extending BaseTest. (2) Page Object Layer — page classes extending BasePage with private locators, public methods. (3) Utility Layer — ExcelReader, ScreenshotUtil, ConfigReader (Singleton), BrowserFactory (Factory Pattern). (4) Configuration — config.properties for browser, URL, timeouts; testng.xml for suite config. (5) Test Data — Excel files in src/test/resources/testdata, read via DataProvider. (6) Reporting — Allure reports via ITestListener. Design patterns: POM, Singleton, Factory. Tools: Java, Selenium, TestNG, Maven, Jenkins. The framework runs 200+ tests nightly in parallel with ThreadLocal WebDriver." Practice this until it flows in 2 minutes.

A: Strong answer: "Singleton ensures one instance of a class. Private constructor prevents external creation. Static getInstance() creates the instance on first call and returns it on subsequent calls. I use it for ConfigReader because: config.properties should be loaded once, not in every test. Every class calls ConfigReader.getInstance().getBaseUrl() and gets the same values. It also supports system property overrides — CI passes -Dbrowser=firefox which takes priority over the file. For thread safety in parallel execution, I initialize in a static block or use synchronized. I also use Singleton for ExtentReportManager — one report instance for the entire suite."

A: Strong answer: "First, I check the Allure report — screenshot and logs from the CI run. Common causes: (1) Headless mode — I run locally in headless to reproduce. (2) Screen resolution — CI default is small. I set --window-size=1920,1080. (3) Timing — CI servers are slower. I check for TimeoutException and increase the explicit wait. (4) Test data — verify the data exists in the CI environment. (5) Browser version — check if CI has a different Chrome version. (6) Run the test in isolation on CI to rule out test dependency. In my experience, 80% of local-vs-CI issues are timing or resolution. I fixed our pipeline by always setting window size and using longer timeouts in CI config."

A: Strong answer: "public class SearchResultsPage extends BasePage { private By searchInput = By.id('search'); private By searchButton = By.id('search-btn'); private By resultItems = By.cssSelector('.result-item'); private By resultCount = By.cssSelector('.result-count'); private By noResultsMessage = By.cssSelector('.no-results'); public SearchResultsPage(WebDriver driver) { super(driver); } public SearchResultsPage searchFor(String term) { type(searchInput, term); waitForClickable(searchButton); return this; } public int getResultCount() { return driver.findElements(resultItems).size(); } public String getResultCountText() { return getText(resultCount); } public boolean isNoResultsDisplayed() { return isDisplayed(noResultsMessage); } public String getResultTitle(int index) { List<WebElement> results = driver.findElements(resultItems); return results.get(index).findElement(By.cssSelector('.title')).getText(); } }"