Order stages by cost and feedback speed. On every commit, run linting and unit tests, targeting a few minutes. On pull requests, add integration and contract tests. After deployment to a shared environment, run smoke tests as a promotion gate. Run the full regression suite and slower checks like performance and accessibility nightly or before release.
Why interviewers ask this
This checks whether you can design a feedback system rather than just write tests. Interviewers want stages ordered by cost, an explicit time budget for the fast stage, and a clear statement of what each stage gates. Mentioning that a red pipeline must genuinely block, and what you do about flakiness at the gate, shows you understand that a pipeline nobody trusts is worse than none.
How to structure your answer
- Order stages by execution cost and feedback speed.
- Give an explicit time budget for the commit stage.
- State what each stage gates and what it blocks.
- Put slow, broad checks on a schedule instead of the gate.
- Say how you keep the gate trustworthy.
Example answer
I design it around how long a developer will actually wait, which is not long. On every commit: linting, static analysis, and unit tests, and I hold that under about five minutes, because past that people context switch and the feedback loses most of its value. On a pull request: integration tests against real dependencies in containers, plus contract tests, so anything that breaks another service fails here rather than in a shared environment. After deployment, a smoke suite that gates promotion, maybe fifteen tests proving the build is alive and the critical journeys work. Then nightly, the full regression run plus the expensive checks, so performance, accessibility scans, and dependency and security scanning. Before a release, a targeted risk based pass on what changed. The rule I enforce is that if a stage is a gate then it genuinely blocks, and if it does not block it should not be presented as a gate, because a permanently red pipeline everyone merges through is worse than no pipeline at all. Which is also why flaky tests come out of the gating stages immediately and sit in quarantine until fixed.
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 would you do if the unit test stage grows past your time budget?
- How would you handle tests that need a deployed environment on a pull request?
- Who should fix a broken pipeline, and how fast?
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