Attack it on four fronts: parallelize across workers, move coverage down the pyramid so API and unit tests replace slow UI journeys, cut duplicate and low value tests, and speed up setup by creating state through the API instead of the UI. Then split the suite so a fast subset gates merges and the full run happens nightly.
Why interviewers ask this
A suite nobody waits for provides no protection, so this measures whether you can make hard prioritization calls about test code. The strongest answers cut tests rather than only optimizing them, and rebalance coverage onto cheaper layers. Splitting into a fast gate plus a scheduled full run shows you understand that feedback speed is itself a quality attribute, not a convenience.
How to structure your answer
- Measure first: find where the four hours actually goes.
- Parallelize, which requires test isolation to work.
- Push coverage down to API and unit layers.
- Delete duplicated and low value tests without flinching.
- Split into a fast merge gate and a nightly full run.
Example answer
First I get the data, because guessing which tests are slow is usually wrong. I pull per test durations and almost always find a small number of tests eating a disproportionate share, often because of fixed sleeps or driving the UI through a long setup. Parallelization is the quickest structural win, but it only works if tests are properly isolated, so that usually means fixing shared test data first. The bigger lever is rebalancing. I look at each end to end test and ask what it is really proving. A test that walks through six screens to check a validation message is a unit test wearing a costume, and it belongs at a layer where it runs in milliseconds. Then I delete, which people find uncomfortable. Tests that have never failed for a real reason, tests duplicating coverage that exists elsewhere, tests for features nobody uses. Coverage that costs more than it returns is a liability. And I do setup through the API, so a checkout test creates its account and cart in two calls rather than fifteen page loads. Finally I split it: fifteen minutes of critical path on every merge, full suite nightly.
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
- How would you prove to the team that deleting those tests is safe?
- What would you put in the fifteen minute merge gate?
- How do you stop the suite from creeping back up to four hours?
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