A hard sleep pauses for a fixed duration regardless of state, which is both slow and unreliable. An implicit wait sets a global polling timeout applied to every element lookup. An explicit wait polls for a specific condition on a specific element, such as clickable or visible. Explicit waits are the right default, and mixing implicit with explicit waits produces unpredictable timeouts.
Why interviewers ask this
Waiting strategy is the single largest source of flaky UI tests, so this is a practical competence check. The interviewer wants the distinction stated cleanly and a firm rejection of fixed sleeps. Knowing that combining implicit and explicit waits causes compounding timeout behavior, and that newer frameworks auto wait on actionability, marks you as current rather than self taught from old tutorials.
How to structure your answer
- Define all three precisely and briefly.
- Explain why a fixed sleep is both slow and unreliable.
- State explicit waits as the default and give a condition example.
- Warn about mixing implicit and explicit waits.
- Note that newer frameworks auto wait on actionability.
Example answer
A hard sleep just blocks for a set number of seconds. It is the worst option twice over: too short and it is flaky, too long and you have added that time to every run forever. I treat any sleep in a test as a defect unless it carries a comment explaining why. An implicit wait is a global setting telling the driver to keep polling whenever it cannot find an element. It is convenient but blunt, because it applies to everything and it makes a genuinely absent element take the full timeout to fail, which slows down all your negative cases. An explicit wait targets one element and one condition, so wait until this button is clickable, or until this spinner disappears. That is my default, because it states intent and fails fast with a meaningful message. The gotcha is mixing implicit and explicit waits in one suite, which in Selenium can produce timeouts that are neither value and are painful to reason about, so I set the implicit wait to zero and do everything explicitly. Playwright removed most of this by auto waiting on actionability, which is a big part of why I prefer it now.
Walking into this interview soon? GhostPilot listens to your live call, spots the question the moment it is asked, and puts a structured answer on your screen in real time. Try it on your next mock, or grab a $29 Session Pass, no subscription, for the real thing.
See how it worksFollow-up questions to expect
- What condition would you wait on before asserting that a table has refreshed?
- How do you handle an element that appears and then moves as the page settles?
- What would you do about a page that never stops making background requests?
Related qa engineer questions
Your interviewer will ask their own version of this. Paste your actual job description into the free Question Predictor and get the 20 questions that role is most likely to ask, with what each one is really probing.
Predict my questions