Why do teams run automated tests automatically in a CI pipeline on every change, instead of just having developers run them locally before they push?

technical-conceptual · Junior level · software-engineering

What the interviewer is really asking

Probes understanding of why tests are integrated into CI: consistency, a shared source of truth, and catching regressions early rather than relying on individual discipline.

What to say

• Explain that local runs are inconsistent: people skip them, forget, or have a different environment, so a green local run doesn't guarantee the change is safe.
• Describe CI as a consistent, shared gate that runs the same tests in a clean, known environment on every change before it merges.
• Note the early-feedback value: catching a regression at the pull request is far cheaper than discovering it after it's merged or shipped.

What to avoid

• Don't imply local testing is pointless; it gives fast feedback, but it can't be the only gate.
• Don't frame CI as just 'a server that runs tests' without the points about consistency and being a merge gate.
• Don't claim CI guarantees zero bugs; it catches regressions the suite covers, not everything.

Example answers

Strong: Running tests only locally relies on every person remembering to run them, in their own environment, which drifts from production. CI runs the same suite in a clean, known environment automatically on every pull request, so it's a consistent gate nobody can skip. It also catches regressions at the PR stage, where they're cheap to fix, instead of after a change merges and someone else inherits the breakage.

Weak: Because it's more convenient to have a server do it. Developers can run tests locally too, but CI just does it for you so you don't have to.