What is CI, and what is its single most important goal?

What's really being asked

This question tests whether you understand Continuous Integration as a software engineering practice rather than a specific tool or pipeline stage. Interviewers want to see that you separate the mechanism, automated builds and tests, from the intent, keeping the integrated codebase healthy. It also checks if you can state the single most important goal without drifting into Continuous Delivery or Deployment.

The full answer

A strong answer hits four things in order. First, define CI as the practice of integrating source code changes frequently, usually by merging into a shared integration branch. Second, note that an automated system builds and tests the software, running on each commit or on a schedule such as daily. Third, explicitly state that the single most important goal is ensuring the integrated codebase remains in a workable state at all times. Fourth, optionally mention that Grady Booch first proposed the term in 1991 and that the practice later evolved to include integrating multiple times per day.

The mistakes people make

The biggest red flag is conflating CI with CD by saying the goal is deploying to production or releasing software. Another mistake is listing tools like Jenkins, GitHub Actions, or CircleCI without defining the practice itself. Some candidates describe CI as merely running unit tests or linting, which misses the integration aspect. Saying the goal is finding bugs fast is partially true but secondary; the core objective is codebase workability.

What usually comes next

An interviewer might ask how often a team should integrate, what makes a build green versus red, or how CI relates to trunk-based development. They may probe on what workable state means in practice, such as whether it requires all tests to pass or merely successful compilation. Be ready to explain the difference between CI, Continuous Delivery, and Continuous Deployment in one sentence each.

A concrete example

Imagine a team of eight developers working on a monorepo. Without CI, each developer works on a feature branch for a week and merges on Friday, causing a day of merge conflicts and broken builds. With CI, every developer merges to the main branch at least once daily. The automated pipeline compiles the application, runs the test suite, and reports status within ten minutes. If the build fails, the team stops and fixes it immediately because the integrated codebase is no longer workable. The goal is not to deploy that day; it is to know that the code on the integration branch is always in a valid, buildable, testable state.