Tell me about a time you simplified a complex test suite or process.

Simplification stories are easy to tell badly — "I deleted a bunch of stuff and it was simpler." The interviewer wants to see investigation, principled cuts, and validation that you didn't break anything.

STAR walkthrough — sample answer:

Situation: A previous team's API regression suite had grown over three years to about 1,400 tests and a 35-minute runtime. It was the bottleneck on PR feedback and several tests had been quarantined as "investigate later" but never re-enabled.

Task: I'd been on the team for about a year and had inherited ownership of the suite. I had a sprint of capacity earmarked for "improve PR pipeline speed."

Action: Three phases.

Investigate first. I tagged tests by category and mapped the runtime: 220 tests accounted for 60% of runtime; 600 tests accounted for less than 10%. About 180 tests were quarantined or skipped. I also ran a coverage analysis: a lot of the tests were duplicating what unit tests already verified — the suite had grown organically without anyone asking "is this the right layer?"

Cut with intent, not by gut.

• Deleted 230 tests that duplicated unit-level coverage (verified each had equivalent unit tests; submitted in batches with clear commit messages).
• Re-enabled the 180 quarantined ones — most needed minor updates, 30 were real bugs that had been hidden, 10 were genuinely broken and got rewritten.
• Replaced 40 of the slowest with focused integration tests that were 10x faster and tested the same behaviour.

Validate the change didn't lose coverage. I ran the old vs new suite against a curated set of recent regressions (pulled from the bug tracker for the last 6 months). The new suite caught 24 of the 25; the one it missed was caught by a unit test that hadn't existed at the time of the original bug.

Result: Suite dropped from 1,400 tests to 990, runtime from 35 minutes to 11 minutes. PR feedback improved from "go for a coffee" to "stay in flow." The team adopted a quarterly review pattern to prevent the suite from regrowing without intent.

What I learned: complexity in test suites usually has a history. Investigating why it got that way is more valuable than blindly cutting; some tests look redundant but are catching specific edge cases the unit tests miss.

Why this works: investigation before action, measured results (test count + runtime + coverage validation), and a process change to prevent the same accretion next time.