50 Selenium interview questions with model answers

What they are assessing

Whether you know Selenium is a suite rather than a single tool.

Model answer

Selenium is an open-source suite for automating browsers. The components are WebDriver, which drives a browser through its native automation support; Selenium IDE, a record-and-playback browser extension useful for quick exploration but not for maintainable suites; and Selenium Grid, which distributes tests across machines and browsers for parallel execution. Selenium RC was the original remote-control component and has been removed since Selenium 3. What Selenium is not is a test framework: it drives the browser, and you pair it with TestNG, JUnit or pytest for structure, assertions and reporting.

Likely follow-up

So what does Selenium not give you that you have to add yourself?

Trap to avoid

Calling Selenium a testing framework. It is a browser automation library, and interviewers use this to check whether you understand the boundary.

What they are assessing

Whether you understand the layer you are working on top of.

Model answer

Your test code calls the WebDriver language binding, which serialises each command into an HTTP request following the W3C WebDriver protocol. That request goes to a driver executable such as ChromeDriver or GeckoDriver, which is a server that translates the request into the browser vendor native automation commands and drives the real browser. The response travels back the same path. The important consequence is that every action is a round trip over HTTP, which is why chatty tests are slow and why the driver version has to be compatible with the browser version.

Likely follow-up

Why does that architecture make Selenium slower than an in-browser tool like Cypress?

What they are assessing

Whether you keep current. Selenium 4 has been stable for years, so vagueness here is telling.

Model answer

The headline change is that the W3C WebDriver protocol became the standard, so the JSON Wire Protocol and its translation layer were dropped, which makes communication more consistent across browsers. Selenium 4 also added relative locators, native Chrome DevTools Protocol access for things like network interception and console log capture, a rewritten Grid supporting standalone, hub-and-node and fully distributed modes with Docker support, and improved window and tab handling with newWindow. On the API side, several older methods were deprecated: driver.close on the last window behaviour tightened, and Actions class methods were reworked.

Likely follow-up

Give an example of something CDP access lets you do that Selenium 3 could not.

Trap to avoid

Saying Selenium 4 is "just faster". The protocol standardisation and CDP access are the substantive changes, and an interviewer wants the specifics.

What they are assessing

A small question that reveals whether you have debugged leaked browser processes.

Model answer

close terminates the current browser window or tab that WebDriver is focused on, leaving the session alive if other windows remain. quit ends the entire WebDriver session, closes every window it owns and shuts down the driver process. In practice you almost always want quit in teardown, because using close leaves orphaned driver processes that accumulate over a long run and eventually exhaust memory on the CI agent.

What they are assessing

Whether you have configured browsers beyond the defaults.

Model answer

Capabilities are the key and value settings describing the session you want: browser name, version, platform, and behaviours such as accepting insecure certificates or the page load strategy. Selenium 4 deprecated the generic DesiredCapabilities object in favour of browser-specific Options classes such as ChromeOptions and FirefoxOptions, which are type-safe and make browser-only settings explicit. In practice you use Options to add arguments like headless or a custom window size, set preferences, and pass cloud vendor configuration when running remotely.

What they are assessing

Honesty about what Selenium cannot do, which candidates often overstate.

Model answer

Officially supported browsers are Chrome, Firefox, Edge and Safari, with Internet Explorer support retired. Language bindings cover Java, Python, C#, JavaScript, Ruby and Kotlin. The limits matter as much as the coverage: Selenium drives browsers only, so it cannot test desktop or native mobile applications, which is where Appium comes in. It also has no built-in reporting, no assertion library, no image comparison and no support for captcha or one-time passwords, all of which have to be solved around it.

What they are assessing

Whether you have a defensible locator strategy rather than using whatever the recorder produced.

Model answer

The strategies are id, name, className, tagName, linkText, partialLinkText, cssSelector and xpath. My preference order starts with a dedicated test attribute such as data-testid, because it is stable against styling and copy changes and signals intent to developers. Then id if it is genuinely unique and stable, then a scoped CSS selector, and XPath only when I need something CSS cannot express, such as selecting by visible text or walking to a parent. I avoid anything positional or generated, because those break on the next layout change.

Likely follow-up

What do you do when the application has no stable attributes at all?

What they are assessing

Technical judgement rather than dogma in either direction.

Model answer

CSS is my default because it is more readable and marginally faster in most browsers. I reach for XPath when I need something CSS genuinely cannot do: matching on visible text with normalize-space and contains, traversing upward to a parent or ancestor, or using axes such as following-sibling to find an element defined only by its relationship to another. A common real case is locating a table cell relative to a row identified by its label text. What I avoid is long absolute XPath copied from devtools, because it encodes the entire DOM path and breaks constantly.

Trap to avoid

Claiming XPath is always slower or always better. Both are situational, and absolutism reads as inexperience.

What they are assessing

Awareness of newer API plus judgement about where it fits.

Model answer

Relative locators let you find an element by its visual position relative to another: above, below, toLeftOf, toRightOf and near. They are useful when the DOM gives you nothing stable but the layout relationship is meaningful, for example a price field that always sits to the right of a product label, or an input directly below a heading. The caveat is that they depend on rendered geometry, so they are fragile under responsive layout changes and should be a fallback rather than a default. I would not build a suite on them.

What they are assessing

A very common real problem, and whether you solve it properly or with hacks.

Model answer

First, ask the developers for a stable test attribute, because that is the correct fix and it is usually a small change. Failing that, anchor on the stable part of the value using CSS prefix, suffix or substring matching, or XPath contains and starts-with. Where the element itself has nothing stable, locate a stable ancestor or a nearby label and scope down from there, which also makes the intent readable. What I avoid is index-based selection or matching on generated hashes, because those pass today and fail silently on the next build.

Likely follow-up

How would you make the case to developers for adding test attributes?

What they are assessing

Whether you have owned a suite long enough to feel locator rot.

Model answer

Locators live in one place per page or component, never inline in tests, so a UI change is a single edit. I name them by intent rather than implementation, so loginSubmitButton rather than blueButton2. Shared components get a shared object rather than duplicated locators in every page class. I audit for duplication periodically, because the same element defined five ways is five things to fix. And I treat locator churn as a signal worth raising: if one screen breaks the suite every sprint, the real fix is test attributes in that component, not more resilient XPath.

What they are assessing

The single most important Selenium topic, since almost all flakiness is a synchronisation problem.

Model answer

An implicit wait is a global setting telling the driver to poll for a set time when an element is not immediately found, applied to every element lookup for the life of the session. An explicit wait is targeted: WebDriverWait combined with an ExpectedCondition waits for a specific condition on a specific element, such as elementToBeClickable or visibilityOf. A fluent wait is an explicit wait with configurable polling interval and ignored exception types. Explicit waits are what you should use, because they express the actual condition you are waiting for rather than blanket-delaying every lookup.

Likely follow-up

Why is mixing implicit and explicit waits a problem?

What they are assessing

Whether you understand the cost of fixed delays. Almost guaranteed to be asked.

Model answer

Thread.sleep pauses for a fixed duration regardless of whether the application is ready, so it is simultaneously too slow when the app responds quickly and too short when the environment is loaded, which is how sleep-based suites become both slow and flaky. The alternative is an explicit wait on the actual condition: the element is clickable, the spinner has disappeared, the network request has settled, the text has changed to the expected value. The honest exception is a rare unobservable state change with no detectable signal, where a short bounded sleep with a comment explaining why can be pragmatic, but it should be exceptional rather than a habit.

Trap to avoid

Saying you never use sleep under any circumstances and then being unable to handle a case with no observable condition. Better to state the rule and the rare exception.

What they are assessing

Depth on a subtle problem that causes real, confusing timeouts.

Model answer

The two mechanisms compound unpredictably. When an implicit wait is set and an explicit wait polls for a condition, each polling attempt can itself trigger the implicit wait, so the effective timeout becomes longer and harder to reason about than either value suggests, and in some driver versions the behaviour differs across browsers. The result is tests that take far longer to fail than expected. The rule I follow is to set the implicit wait to zero and use explicit waits everywhere, so the wait is always visible in the test code.

What they are assessing

Whether you fix the cause or paper over it with retries.

Model answer

It means you are holding a reference to an element that is no longer attached to the DOM, usually because the page re-rendered between finding the element and acting on it. This is common with dynamic frameworks and after any action that triggers a re-render. The proper fix is to locate the element as late as possible, immediately before interacting, rather than caching references, and to wait for the condition that indicates the re-render has finished. Blanket retry-on-stale wrappers hide the timing problem and eventually mask a genuine bug where the application re-renders unexpectedly.

Likely follow-up

How does Page Factory interact with this problem?

What they are assessing

Suite ownership. This is where senior candidates separate themselves.

Model answer

Measure first: track pass and fail history per test so you can identify the genuinely flaky ones rather than guessing. Then categorise the causes, because the fixes differ. Synchronisation issues get proper explicit waits. Test data collisions get isolated or uniquely generated data. Order dependence gets fixed by making each test set up its own state. Environment issues get stabilised or the test gets moved to a lower layer. Third-party dependencies get stubbed. I quarantine flaky tests immediately so the suite stays trustworthy while they are fixed, with an owner and a deadline, because a suite people re-run until it goes green has no value. And I push coverage down the pyramid where the flakiness is inherent to driving a browser for something an API test could verify.

Likely follow-up

What flake rate would you consider acceptable?

What they are assessing

Practical technique on the most common real waiting problem.

Model answer

Prefer waiting on a user-visible condition rather than a technical one: the loading indicator becomes invisible, or the expected content appears. invisibilityOfElementLocated on the spinner combined with visibilityOf on the result is usually the readable version. Where the application exposes a signal, such as jQuery.active reaching zero or a data attribute flipping to loaded, waiting on that is more precise. In Selenium 4 you can also use CDP to observe network activity, though for most suites the visible-condition approach is simpler and less brittle.

What they are assessing

Whether you know the difference between a native select and a custom widget.

Model answer

For a native select element, use the Select class, which gives selectByVisibleText, selectByValue and selectByIndex, plus getOptions and getFirstSelectedOption for assertions. For custom dropdowns built from div and li elements, which is most modern UI, the Select class does not apply: you click to open the control, wait for the option list to be visible, then click the option by its text or test attribute. Confusing the two is a very common mistake, so I check the underlying markup first.

Likely follow-up

How would you assert that a dropdown contains exactly the expected options?

What they are assessing

Familiarity with context switching, which trips up beginners.

Model answer

Alerts are a separate context reached with driver.switchTo().alert(), then accept, dismiss, getText or sendKeys, and you should wait for alertIsPresent rather than assuming timing. Iframes require driver.switchTo().frame() by index, name or WebElement, and crucially switchTo().defaultContent() afterwards, because forgetting to switch back causes confusing not-found failures on the parent page. Windows and tabs are handled through window handles: capture the current handle, iterate getWindowHandles to find the new one, switch, act, then switch back. Selenium 4 adds newWindow to open a tab or window directly.

Trap to avoid

Forgetting to switch back out of a frame. Interviewers know this is the most common cause of the next mysterious failure.

What they are assessing

Whether you have automated beyond clicking and typing.

Model answer

The Actions class builds sequences of low-level input events for interactions the simple element methods cannot express: hover, right-click and double-click, drag and drop, click-and-hold, key combinations with modifiers, and moving to an element before clicking. You chain the steps and call perform to execute. Two practical notes: hover-dependent menus often need moveToElement followed by a wait for the submenu, and drag and drop is notoriously unreliable in some drivers, so for HTML5 drag and drop I often fall back to a JavaScript-based approach or, better, test the underlying behaviour at a lower layer.

What they are assessing

Whether you understand it as an escape hatch rather than a convenience.

Model answer

JavaScriptExecutor runs script in the page context, which is useful for scrolling an element into view, reading a value the DOM exposes but the UI does not, or working around a driver limitation. The risk is that it bypasses the real user path: clicking via JavaScript succeeds even when a real user could not click, because the element is covered, disabled or off-screen, so the test passes while the product is broken. That makes it a false-confidence machine when overused. I use it for setup and diagnostics, and I keep the actual behaviour under test on the real interaction path.

Likely follow-up

You have a test that only passes with a JavaScript click. What does that tell you?

Trap to avoid

Presenting JavaScript click as a general fix for click failures. It is the classic way suites end up green while the feature is unusable.

What they are assessing

Practical knowledge of a case that cannot be solved by clicking.

Model answer

For upload, if the page uses a native input of type file, send the absolute file path to that input with sendKeys and do not click the control, since interacting with the OS dialog is outside the browser and outside Selenium. Where the UI hides the input behind a styled element, you still target the underlying input. For custom drag-and-drop uploaders you may need a JavaScript approach. Downloads are handled by configuring the browser through Options to auto-download to a known directory without prompting, then asserting on the file appearing with the right name, size or content, with a wait since the write is asynchronous.

What they are assessing

Pragmatism about things Selenium genuinely cannot do.

Model answer

Avoid driving the login UI in every test: log in once through the API and inject the session cookie or token, which is faster and removes a shared point of failure. Basic auth can go in the URL or through CDP. For multi-factor codes, use a test account with a known static code in non-production, or read the code from a test mailbox or database rather than a real device. Captcha should be disabled or bypassed with a test key in test environments, which is a configuration request to the team rather than an automation problem. Trying to solve captcha in a test is the wrong battle, and I would say so directly.

Likely follow-up

Is there any risk in bypassing login for every test?

What they are assessing

The most asked framework question. Everyone knows the term, few explain the payoff precisely.

Model answer

Page Object Model represents each page or component as a class holding its locators and the actions available on it, while tests call those actions and hold the assertions. The payoff is that a UI change is fixed in one place rather than across every test that touched that screen, tests read as business intent instead of selector soup, and behaviour is reusable across tests. The discipline that makes it work is keeping assertions out of page objects, so the page describes capability and the test describes expectation.

Likely follow-up

Should a page object method return void or something else?

What they are assessing

Whether you can evaluate a pattern critically rather than adopting it because it is in tutorials.

Model answer

Page Factory is a Selenium support class that initialises WebElement fields annotated with FindBy, using lazy proxies so the lookup happens when the element is used. It reduces boilerplate. I am cautious about it in modern applications because the lazy proxy re-finds on each call in a way that can surprise you, it interacts awkwardly with heavily dynamic DOMs and stale elements, and the annotations push locators into field declarations where conditional logic is harder. For most new suites I prefer explicit locator constants and a find method, which is more predictable. It is a reasonable choice on an existing codebase already using it consistently.

What they are assessing

Whether you separate data from logic, and how you handle data volume.

Model answer

Test logic lives in one place and the data comes from outside it, through a TestNG DataProvider, a parameterised JUnit test, or an external source such as CSV, JSON, Excel or a database for larger sets. Environment configuration stays separate from test data, because they change for different reasons. Data should be either generated uniquely per run or reset deterministically, so parallel execution does not collide. The judgement call is scope: data-driving a login test across twenty invalid inputs is valuable, while data-driving an entire end-to-end journey usually just multiplies runtime for little extra coverage.

Likely follow-up

How do you keep data-driven tests from producing unreadable failure reports?

What they are assessing

Whether you use the framework deliberately rather than only as a test runner.

Model answer

Selenium drives the browser and TestNG provides the structure. The features that matter in practice are annotations for setup and teardown at method, class and suite scope, groups for slicing the suite into smoke and regression, dependsOnMethods used sparingly, DataProvider for parameterisation, parallel execution configuration in the suite XML, retry through IRetryAnalyzer, and listeners for reporting and screenshot-on-failure. Priorities and dependencies deserve caution, because tests that must run in a set order are usually a design smell.

What they are assessing

Architectural thinking. A common senior whiteboard question.

Model answer

I would separate concerns into layers. A driver management layer that creates and disposes drivers, thread-safe for parallel runs, and reads target browser and environment from configuration. A page and component layer holding locators and interactions, with shared components factored out. A business or workflow layer composing page actions into reusable journeys such as placeOrder, so tests stay short. A test layer holding only intent and assertions. Cross-cutting utilities for waits, data generation, API setup calls and file handling. Then configuration externalised per environment, reporting with screenshots and logs on failure, and CI integration with tagged suites. The rule I keep is that a test should read like a description of behaviour, with no locator or wait visible in it.

Likely follow-up

Where would you put the API calls used to set up test state?

What they are assessing

Real parallel-execution experience, which many candidates lack.

Model answer

The core problem is shared driver state. Each thread needs its own WebDriver instance, typically held in a ThreadLocal and cleaned up in teardown to avoid leaks. Page objects must not hold static driver references. Test data has to be unique per thread or isolated, so two tests do not fight over the same user or record. Anything writing to a shared file or a fixed download directory needs per-thread paths. Reporting must be thread-aware so screenshots attach to the right test. And tests must be independent of order, because parallel execution removes any sequence guarantee you were implicitly relying on.

Trap to avoid

Saying "just set parallel in the TestNG XML". That flag is the easy part; the shared state is what breaks.

What they are assessing

Whether you build for debuggability rather than only for passing.

Model answer

Implement it centrally through a TestNG listener or JUnit rule so it happens automatically on every failure rather than being remembered per test, using TakesScreenshot to write the image and attaching it to the report against the failing test. Beyond the screenshot, capture the current URL, the page source, and browser console and network logs where available, because a picture of a page shows the symptom while the console usually shows the cause. This matters most for CI failures, where nobody was watching and the environment is gone by the time you look.

What they are assessing

Whether you keep the pyramid shape rather than automating everything through the browser.

Model answer

UI tests should verify things that only exist in the UI: rendering, navigation, client-side validation and the critical user journeys end to end. Business logic, data validation, permissions and error handling belong in API or unit tests, which are faster, more stable and pinpoint failures better. In practice I use the API for setup and teardown even in UI tests, creating the account and the order through calls rather than clicking through five screens to reach the state under test, which cuts runtime and removes unrelated failure points. If a UI test is long because of setup rather than assertion, that is the signal to move work to the API.

What they are assessing

Understanding of layering, and honesty about when BDD is overhead.

Model answer

Cucumber provides the Gherkin feature files and maps steps to code; the step definitions call your page or workflow layer, which uses Selenium. The layering rule is that Gherkin describes business behaviour with no reference to buttons or selectors, and the technical detail lives below the step definitions. BDD earns its overhead when non-technical stakeholders genuinely read and shape the scenarios. When the feature files are written by the same engineer who writes the steps and nobody else reads them, it adds a translation layer without the collaboration benefit, and I would say so rather than adopt it by default.

What they are assessing

Whether you understand the scaling problem it solves.

Model answer

Grid distributes test execution across multiple machines and browser and platform combinations, so you can run in parallel and cover browsers you do not have locally. You need it when suite runtime has become the constraint, or when you must verify across a browser matrix. Selenium 4 restructured it into standalone mode for simple setups, hub and node, and a fully distributed mode with separate router, distributor, session map and event bus for larger installations, with Docker support. The honest alternative is a cloud device and browser provider, which many teams choose to avoid maintaining Grid infrastructure themselves.

Likely follow-up

Would you self-host Grid or use a cloud provider, and why?

What they are assessing

Whether you have actually shipped automation into CI rather than running it locally.

Model answer

Run headless with a fixed window size so rendering is deterministic, and pin browser and driver versions or manage them automatically to avoid version drift breaking the build overnight. Containerise the run so the environment is reproducible. Externalise environment configuration and secrets rather than committing them. Tier the suite so a fast smoke set gates every commit and the full regression runs on a schedule or before release, because a twenty-minute suite on every push gets disabled by the team. Publish reports and failure artefacts as build artifacts, and make the build genuinely fail on test failure rather than continuing on error.

Likely follow-up

What do you do when a test passes locally but fails only in CI?

What they are assessing

Systematic debugging on the most common real-world automation frustration.

Model answer

Start from the differences rather than the test. Headless versus headed rendering, window size and viewport, timing on a slower or contended agent, missing fonts, timezone and locale, environment data state, network restrictions, and browser or driver version. Reproduce locally in headless at the same viewport first, since that alone explains a large share of cases. Then use the artefacts: screenshot, page source, console and network logs at the point of failure. Add temporary verbose logging around the failing step if needed. Most of these turn out to be an implicit timing assumption that the faster local machine hid.

What they are assessing

Whether you know the cost of the speed you gain.

Model answer

Headless runs the browser without rendering a visible window, which is faster and necessary on CI agents with no display. The trade-offs are real: some rendering and layout issues do not reproduce, viewport defaults differ so responsive behaviour can change, a few interactions behave differently, and visual verification is limited unless you capture screenshots deliberately. My approach is to run the bulk of the suite headless for speed, set the window size explicitly, and run a small headed pass for visually sensitive checks before release.

What they are assessing

Operational maturity. This breaks builds constantly in real teams.

Model answer

Version mismatch between browser and driver is one of the most common causes of a suite failing overnight with no code change. Options are Selenium Manager, which resolves drivers automatically in Selenium 4, a tool like WebDriverManager, or pinning both browser and driver explicitly inside a container image so the environment is immutable. I prefer pinned versions in a container for CI, with a deliberate upgrade step, because automatic latest-version resolution means an external change can break your pipeline without any commit from your team. Then browser upgrades become a scheduled, testable change rather than a surprise.

What they are assessing

Practical coding approach and whether you assert precisely.

Model answer

Locate the table, then find the row by a stable identifying cell rather than by index, using a text-based XPath or by iterating rows and matching a cell value. Once the row is found, read the specific cells you care about and assert their values individually so a failure tells you which field was wrong. I avoid asserting on a concatenated string of the whole row, because the failure message becomes unreadable. For paginated or virtualised tables I would either search or filter first to bring the row into view, or verify the data through the API and keep the UI test focused on rendering.

What they are assessing

A subtle correctness question many candidates get wrong.

Model answer

Use findElements and assert the returned list is empty, since it returns an empty list rather than throwing. The pitfall is the difference between not present in the DOM and not visible: an element can exist but be hidden, so choose the check that matches the requirement and use invisibilityOfElementLocated when you mean not visible. The second pitfall is timing. Asserting absence immediately can pass simply because the element has not rendered yet, so where the element may appear asynchronously you need to wait for the state that proves absence is settled rather than asserting on an empty page.

Trap to avoid

Wrapping findElement in a try and catching NoSuchElementException as the primary technique. It works but it is slow when an implicit wait is set and it reads as inexperience.

What they are assessing

Basic API precision.

Model answer

findElement returns the first matching WebElement and throws NoSuchElementException when nothing matches. findElements returns a list of all matches and returns an empty list when nothing matches, without throwing. That difference is why findElements is the right tool for absence checks and for counting, while findElement is for acting on a single expected element.

What they are assessing

Whether you set up state efficiently rather than clicking through the app.

Model answer

Create the prerequisite state through the fastest reliable route, which is usually an API call or a direct database seed, then start the UI test at the screen under test. Driving five screens through the UI to reach the state adds runtime and, worse, makes the test fail for reasons unrelated to what it is verifying. The exception is when the creation journey itself is what you are testing, in which case it belongs in its own test. I also make the created data unique per run and clean it up, so parallel execution and repeated runs stay reliable.

What they are assessing

Whether you understand retries as a diagnostic tool rather than a fix.

Model answer

Technically it is straightforward, through IRetryAnalyzer in TestNG or the equivalent elsewhere, re-running a failed test a bounded number of times. The judgement matters more. Blanket retries hide flakiness and can hide real intermittent product defects, which is the worse outcome, so a suite that is green only because of retries is lying to you. If I use retries, it is with visibility: the report shows the test needed a retry, the flake rate is tracked, and repeat offenders are quarantined and fixed rather than silently re-run forever. Retries buy time to fix the cause; they are not the cause being fixed.

Likely follow-up

How would you tell an intermittent product bug from a flaky test?

What they are assessing

Whether you can assess your primary tool honestly. A strong differentiator.

Model answer

Selenium is the wrong choice when you need to test something that is not a browser, such as a native mobile or desktop application, where Appium or a platform tool fits. It is wrong for unit or API-level verification, where a browser adds cost and instability for no benefit. It is often the wrong choice for a small team on a modern single-page application, where Playwright or Cypress give better developer experience, auto-waiting and debugging out of the box. Its enduring strengths are broad browser and language support, no vendor lock-in, and a mature ecosystem, which is why large organisations with mixed stacks stay on it.

Likely follow-up

So would you recommend Playwright over Selenium for a new project?

What they are assessing

Whether you build a business case rather than automating what is easy.

Model answer

Score candidates on execution frequency, business criticality, stability of the feature and the manual cost of running them. The best first targets are stable, high-value, frequently repeated flows: smoke checks and critical-path regression, particularly around revenue and data integrity. Poor candidates are features still changing weekly, one-off verifications, and anything needing human judgement such as visual or usability assessment. The common mistake is automating what is easiest to automate rather than what is most expensive to keep testing by hand.

What they are assessing

Commercial literacy, expected at lead level.

Model answer

Cost side: initial build effort, ongoing maintenance which is the part usually omitted, infrastructure, and the engineering time spent investigating failures including false ones. Value side: manual execution hours displaced per release multiplied by release frequency, defects caught earlier and the cost avoided, and faster feedback enabling more frequent releases. The honest framing is that automation rarely reduces headcount; it changes what the team spends time on and shortens the feedback loop. I would also track flake rate as a cost, because an untrusted suite has negative value while still consuming maintenance.

Likely follow-up

What would make you decide to delete part of a suite?

What they are assessing

Turnaround judgement under a realistic bad situation.

Model answer

Stop treating the whole suite as one thing. First get visibility: per-test pass history and duration, so I know what is slow and what is unreliable. Then triage. Quarantine the persistently flaky tests immediately so the signal is trustworthy again, even if coverage temporarily drops, because a suite nobody believes is already providing zero value. Carve out a fast smoke set of critical paths that runs on every commit, and move the rest to scheduled runs. Fix the top flakiness causes by category rather than test by test, usually synchronisation and shared data. Delete tests that verify nothing meaningful or duplicate lower-layer coverage. Then push new coverage down to API level rather than growing the UI suite further.

Likely follow-up

How do you justify deleting tests to a manager who equates test count with coverage?

Trap to avoid

Proposing to rewrite the whole framework immediately. It is expensive, it stops delivery, and it usually recreates the same problems.

What they are assessing

Influence and collaboration rather than technical skill.

Model answer

Reduce the friction first. If running the suite requires tribal knowledge, developers will not run it, so make it a single command, fast at the smoke layer, and readable so a failure is understandable without QA translation. Put the tests in the same repository as the application code and in the pipeline they already watch. Then make ownership visible: a failing test blocks the merge, and the person whose change broke it is the person who looks. Ask developers for test attributes rather than fighting selectors, which gives them a small concrete contribution that pays off immediately. Culture follows once the suite is trustworthy and fast; it never arrives while the suite is slow and flaky.

What they are assessing

Long-term thinking rather than getting tests green once.

Model answer

Treat the suite as a product with a maintenance budget. Locators centralised so a UI change is one edit. Business workflows factored out so a changed journey is fixed once. Tests independent and self-setting so order changes break nothing. Regular pruning, because a suite only ever grows unless someone deletes. Review flake rate and duration as standing metrics rather than noticing when they are unbearable. And keep the pyramid shape, resisting the pull to verify everything through the browser because that is the layer QA controls.

What they are assessing

Honesty and communication rather than tool advocacy.

Model answer

Selenium automates browsers only, so no native mobile or desktop coverage. It has no built-in reporting, assertions or test management, so those are added. It cannot verify visual appearance or usability, only that elements behave as scripted, and it cannot handle captcha or genuine multi-factor authentication without test-environment accommodation. It needs maintenance as the UI changes, which is an ongoing cost rather than a one-off build. Being straight about these up front prevents the expectation that automation replaces manual testing entirely, which is the most common stakeholder misunderstanding.

What they are assessing

Whether you can be balanced about competing tools without being dismissive.

Model answer

Selenium drives real browsers over the W3C protocol, supports the widest browser and language range, and has the deepest ecosystem, which suits large mixed-stack organisations. Playwright offers auto-waiting, built-in tracing, strong parallelism and a better default developer experience, which usually makes it the faster choice for a new project. Cypress runs in the browser with excellent debugging and a tight feedback loop, at the cost of architectural constraints around multi-tab and cross-origin work, and it is JavaScript-centric. In practice the flakiness advantage people attribute to newer tools comes largely from auto-waiting, which a well-built Selenium suite with proper explicit waits also achieves.

Likely follow-up

If you were starting fresh tomorrow, which would you pick and why?