17 WebElement State and Interaction Interview Scenarios for Senior SDETs

Senior SDETs treat a WebElement as a remote reference, not a frozen copy of a DOM node. Every information or interaction method becomes a WebDriver command evaluated against the current document and the referenced node. That model explains why attributes drift from properties, why visible controls can still reject clicks, and why stale references cannot be refreshed in place.

These scenarios test precise state reasoning. A credible answer names the state source, selects the matching WebElement API, anticipates browser-side interactability checks, and verifies what changed after the command.

Follow State from Lookup to Outcome

Selenium's element information guide covers properties, attributes, text, CSS, geometry, and element state. Its element interaction guide connects those observations to click, clear, and send-keys commands.

1. 01 / located element

   Located Element

   A selector resolves to one remote node in the active browsing context.

   query state

2. 02 / state inspection

   State Inspection

   Read markup, live properties, selected state, text, or geometry deliberately.

   interpret

3. 03 / interaction decision

   Interactability Decision

   Check whether the intended command is meaningful for the current state.

   issue action

4. 04 / webdriver command

   WebDriver Command

   The remote end scrolls, hit-tests, edits, or activates the element.

   verify result

5. 05 / outcome assertion

   Outcome Assertion

   Relocate as needed and prove the application-level result.

No single boolean answers every question about a control. Display, enabled state, selection, editability, pointer hit testing, and domain permission are related but separate contracts.

Separate Markup from Live DOM State

1. Why can the value attribute differ from the text currently typed into an input?

The serialized value attribute represents markup or a default, while the DOM value property tracks live edits. I would read getDomProperty("value") or use a value assertion after typing, and reserve getDomAttribute("value") for a test about markup initialization. A candidate who uses a convenience getAttribute call should explain its binding behavior rather than assuming attribute and property are synonyms.

2. How would you verify a checkbox that began checked but the user cleared?

I would use isSelected() for current user-facing selection and assert it is false after the click. If initialization is also under test, I would separately inspect the serialized checked attribute before interaction. A boolean attribute's presence in markup is not a history of current state. I would then verify the domain effect, because toggling the DOM control may still fail to persist the preference.

3. Why is getText not the right API for the value shown inside a text field?

An input's edited value is exposed as a DOM property, not a descendant text node. getText() addresses rendered element text and can legitimately return an empty string for an input. I would read the live value property and, when accessibility matters, inspect the associated label separately. Using JavaScript textContent would not fix the semantic mismatch because the control still stores its value elsewhere.

4. How would you test a custom element whose status is reflected to an aria attribute?

I would distinguish the component's internal JavaScript property from its public accessibility contract. If the requirement is assistive state, inspect the appropriate DOM attribute or accessible state and verify the visible outcome. If property reflection is the component contract, read both property and attribute at the transition boundary. One passing value does not prove synchronization between internal state, markup reflection, and what the user perceives.

Interpret Displayed, Enabled, and Selected State

5. Why can isDisplayed return true for a control a user cannot practically operate?

Displayed state does not prove that another element is covering the click point, that animation has stopped, that the control is enabled, or that the active frame is correct. I would inspect geometry, screenshot, computed layout, and the actual click error. The WebDriver click command performs additional interactability processing. A pre-check can improve diagnostics, but it must not be presented as a guarantee that the next command will succeed.

6. How would you explain isEnabled on a visually disabled custom button built from a div?

WebDriver enabled-state semantics recognize disabled form controls, but a styled div with aria-disabled="true" may not behave like a native disabled button. I would test its accessibility state and attempt the representative user interaction, then assert no forbidden action occurs. The product should prefer native semantics where possible. A CSS class named disabled is visual evidence, not a protocol-level guarantee that click will be blocked.

7. Why can an option be selected even though its select element is not displayed?

Selection state and display state answer different questions. A hidden or collapsed control can retain a selected option in the DOM. I would verify isSelected() when the data state matters, then separately verify whether the user can see or operate the control. If a hidden option influences checkout, the test should assert the displayed summary or submitted value instead of treating hidden selection alone as sufficient evidence.

8. How would you validate an indeterminate checkbox?

isSelected() covers checked selection, but indeterminate is a separate live property commonly set by script. I would read getDomProperty("indeterminate"), assert the accessible mixed state if that is the contract, and verify the transition after user activation. A test that checks only selected false cannot distinguish an intentionally mixed parent from an ordinary unchecked box, which changes the meaning of the control.

Diagnose Click Interactability

9. Why does click sometimes report element click intercepted after isDisplayed passed?

The click algorithm scrolls the element and performs hit testing near its in-view center. A sticky header, modal backdrop, toast, or animation can own that point even while the target is displayed. I would capture the intercepting element, rectangles, and screenshot, then wait for the owning transition or report a product defect. JavaScript click bypasses the user interaction path and is not an equivalent repair.

10. How would you handle a button that becomes disabled between inspection and click?

I would treat the check and click as separate remote commands with a race between them. The click result and application state are authoritative; an earlier isEnabled() cannot lock the control. Wait for the domain prerequisite, click once, and classify an intervening disable as either expected concurrent behavior or a product race. Repeating clicks automatically could submit twice if the first command actually reached the handler.

11. Why can a zero-sized child still appear to be part of a clickable control?

The event target may be a parent button while the selected icon or span has no useful box. I would locate the operable ancestor by role or stable control identity and click that element. Geometry from getRect() helps explain why a child is unsuitable, but expanding the child with CSS or coordinate offsets in the test would mutate or depend on implementation. The locator should represent the actual interactive element.

12. How would you review a framework that calls JavaScript click after every WebDriver click failure?

I would remove the unconditional fallback. It suppresses interception, disabled state, wrong-context, and scrolling defects, and it dispatches behavior through a different browser path. The framework should preserve the standardized error and gather hit-test evidence. JavaScript activation is valid only when the scenario explicitly tests a programmatic API and says so; it must not make an inaccessible checkout action look healthy.

13. Why should a successful click be followed by a domain assertion?

A successful command means the remote end completed element activation without a protocol error. Client validation, a rejected API call, navigation cancellation, or a no-op handler can still leave the business state unchanged. I would assert a durable result such as order status, URL plus unique content, or persisted setting. The assertion should relocate elements because the click may replace the original DOM subtree.

Reason About Editing Commands

14. Why might clear fail to produce the same behavior as repeated Backspace keys?

The element-clear command follows WebDriver's editing algorithm, while a sequence of key inputs exercises keyboard event handling and application masks differently. I would choose based on the requirement. For a normal editable field, clear and then assert the live value. For keyboard-specific validation, send user keys and verify events through the application outcome. I would not assume all frameworks react identically to every editing mechanism.

15. How would you set a date input without hiding browser-specific behavior?

I would use the binding's element input command with the format expected by the controlled test environment, then read the live value and assert the application's interpreted date. If the requirement covers the browser's native picker, direct value entry is insufficient; that interaction may require platform-specific coverage. Executing JavaScript to assign value bypasses input semantics and can leave framework state unsynchronized with the DOM.

16. Why can sendKeys append to an unexpected field after a rerender?

The original reference may become stale, or focus may move to a replacement element while a composite widget handles keys globally. I would locate the intended editable control after the transition, verify its identity and current value, send the sequence, and assert the resulting property. Action logs should include active element and frame context. Blindly sending a global chord can make a focus defect appear as a data-entry failure.

Manage Remote Element Identity

17. How would you distinguish stale element reference from no such element after navigation?

Staleness means a previously returned remote element id no longer belongs to the active document; no such element means a fresh search found no match in its current search context. I would preserve which command failed. After expected navigation, discard old references and search in the new document. If a fresh locator fails, inspect URL and context. Retrying a stale reference and retrying a locator are fundamentally different operations.

Review State Assertions as Contracts

A strong review asks whether the API matches the state under test. Use DOM properties for live values, DOM attributes for serialized declarations, selection for native selectable controls, and explicit accessibility assertions for custom semantics. Treat displayed and enabled checks as observations, not reservations on future state.

Failure evidence should include the locator, remote command, element tag and stable id, relevant property or attribute values, rectangle, current browsing context, screenshot, and standardized error. That package lets a reviewer separate a bad assertion from a real interaction defect.

Close with the Application Outcome

WebElement methods are precise only when the framework preserves their distinctions. Inspect the right layer, expect state to change between commands, relocate after replacement, and let genuine interactability errors remain visible. Most importantly, finish every interaction by proving the durable application result. That is where a remote element command becomes a trustworthy test.