Your team's UI test suite has become slow, flaky, and a nightmare to maintain — a small UI change breaks dozens of tests. As a senior engineer, how do you reason about what's structurally wrong with the framework and how to fix it?
technical-conceptual · Senior level · software-engineering
What the interviewer is really asking
Assesses whether the candidate understands the structural causes of brittle UI suites — fragile locators, duplicated selectors, implicit timing waits — and modern framework design (stable locators, abstraction layers, auto-waiting tools) to fix maintainability and flakiness at the root.
What to say
- Diagnose the brittleness sources: fragile locators (deep CSS/XPath tied to DOM structure) and selectors duplicated across many tests mean one UI tweak breaks dozens; flakiness usually traces to fixed sleeps or racing the UI instead of waiting for the actual condition.
- Fix locators and structure: standardize on stable, intent-revealing locators (test ids / roles / accessible names) so cosmetic refactors don't break tests, and centralize element access behind an abstraction layer (page objects, or for component-heavy UIs component objects / app-action helpers) so a change updates one place, not fifty.
- Fix flakiness at the root with modern tooling: prefer frameworks with built-in auto-waiting and web-first assertions (e.g. Playwright) over manual sleeps, and treat flaky tests as bugs — quarantine, root-cause, and use trace/replay tooling rather than reflexively re-running until green.
What to avoid
- Blaming the team or 'bad tests' generically without identifying the structural causes — fragile locators, duplication, and timing waits.
- Adding fixed sleeps / Thread.sleep to 'fix' flakiness, which slows the suite and only masks the race condition.
- Defaulting to retries-until-green as the answer to flakiness, hiding real timing bugs instead of root-causing them.
Example answers
Strong: I'd find the structural causes before touching individual tests. 'One change breaks dozens' almost always means brittle locators — deep CSS or XPath bound to the DOM shape — duplicated across tests, so I'd move to stable, intent-based locators like test ids, roles, and accessible names, and centralize element access behind an abstraction so a UI change updates one place, not fifty. For component-heavy UIs that's component objects or app-action helpers rather than giant page-object god classes. The flakiness usually comes from fixed sleeps or racing the UI, so I'd adopt a framework with real auto-waiting and web-first assertions like Playwright instead of manual waits, and treat each flaky test as a bug to root-cause with trace tooling, not something to re-run until it's green.
Weak: I'd add some waits to fix the flakiness and set the CI to retry failed tests a couple of times so they pass. For the maintenance, I'd ask the team to be more careful updating the selectors when the UI changes.