1. Why is a fixed sleep a weak synchronization strategy?
A fixed sleep waits even when the page is ready and still fails when the page takes longer than expected. Wait for a meaningful condition instead: an element becoming usable, a result appearing, or a state changing. Choose the condition based on the next action, not merely the existence of an element somewhere in the document.
For our example, clicking Save triggers a request and then a success message. Waiting for the Save button to exist proves little because it existed before the request. Wait for the result that represents completion, and assert its content. If an error message appears instead, the test should preserve that evidence rather than continue as though saving succeeded.
2. Should implicit and explicit waits be mixed?
Selenium's waiting documentation warns against mixing implicit and explicit waits because the resulting timing can be unpredictable. Be able to describe the suite's chosen strategy and where timeouts are configured. A collection of unrelated waits added after failures makes execution time difficult to reason about.
In an interview, state the expected application behavior and a bounded timeout. Do not promise that a larger timeout fixes every flaky test. If a required state never occurs because the request failed, waiting longer only delays a useful failure. Include the URL, relevant state, and diagnostic artifacts in the report so the next engineer can investigate.
3. What causes a stale element reference?
An element reference can become invalid when the underlying page or relevant DOM node changes. A test may locate a row, trigger a redraw, and then try to interact with the old row reference. The appropriate response is to understand the update and locate the current element at the correct time, not to suppress all exceptions.
Our practice page filters a list after each keystroke. Locate the desired row after the filter result is ready, then perform the action. Check that the row still represents the intended record. Re-finding the first matching button without verifying identity can make a stale-reference workaround click the wrong item and create a more serious false positive.
4. How do you choose a maintainable locator?
Prefer a locator whose meaning is stable for the application: a reliable identifier, a deliberate test attribute, or an appropriate user-facing relation. Avoid brittle position-based paths that break when an unrelated element is inserted. Agree with developers on testable interfaces when the page offers no stable way to identify an important control.
A locator must also be sufficiently specific. If a page has several Delete buttons, identify the intended record before selecting its control. Ask what happens after sorting or pagination. A passing test that acted on the wrong row provides no evidence about the desired behavior, even if its selector looked short and elegant.
5. How would you investigate a CI-only failure?
Compare browser versions, viewport, timezone, headless behavior, test data, permissions, and resource contention. Capture the page state at failure and reproduce with the same configuration where practical. First determine whether the failure is deterministic in CI or intermittent everywhere but more visible under load.
For parallel runs, isolate accounts and records. If two workers edit the same user preference, a wait will not solve the race. If an overlay blocks a click, inspect why it remains open rather than immediately forcing a JavaScript click that bypasses normal interaction. The test should exercise supported user behavior unless its purpose explicitly requires a lower-level action.
A short answer structure for debugging questions
Use four sentences: the observed failure, the likely competing causes, the evidence you would gather, and the smallest change you would verify. For a missing confirmation, compare a failed request, a wrong locator, and a synchronization issue before choosing a fix. This structure demonstrates investigation rather than memorized exception handling.
Practise with the automation strategy guide next. Use Cluegent during preparation to generate follow-up constraints, such as a slower backend or reordered table, and explain how your test remains valid. Finish by naming the regression assertion that proves the fix without masking a real product failure.
Sources checked
These official references support the guide. Product details and technical documentation can change; check the linked source for current information.
Where Cluegent helps
Cluegent supports permitted live workflows with transcript context, typed prompts, screenshot-aware answers, resume context, custom response behavior, quick action buttons, and a private desktop overlay. It is most useful when you already understand the subject and need help staying structured under pressure.
Frequently asked questions
Should I mix implicit and explicit waits?
Selenium's documentation advises against mixing them because the combined wait timing can be unpredictable.
Is catching every stale-element error a good fix?
No. Understand the DOM update, synchronize with the intended state, and re-locate the correct current element without hiding unrelated failures.