Compare monorepo and polyrepo strategies in CI/CD

WHAT THIS TESTS: This question tests whether you can reason about second-order effects of repository topology on continuous integration and delivery systems. Interviewers care less about which strategy you prefer and more about whether you understand the mechanical implications for build graphs, pipeline triggers, dependency resolution, and team autonomy at scale. They want to see systems thinking about how a git boundary changes caching, blast radius, and coordination overhead.

A GOOD ANSWER COVERS: First, define the core tradeoff: monorepo optimizes for code sharing and atomic changes across services, while polyrepo optimizes for deployment independence and team sovereignty. Second, for build orchestration, explain that monorepos require incremental builds and fine-grained dependency graphs to avoid O(n) build times, typically using tools like Bazel, Buck, Nx, or Turborepo with remote caching, whereas polyrepos naturally scope builds to a single service but require orchestrating downstream builds when shared libraries change. Third, for dependency management, note that monorepos can use source-based dependencies where all code moves in lockstep, eliminating version skew but requiring strict code health, while polyrepos rely on published artifacts, semantic versioning, and artifact registries, introducing diamond dependency problems and upgrade lag. Fourth, for pipeline triggering, describe how monorepos need path-based filters or affected-graph detection to run only relevant pipelines, while polyrepos need cross-repo webhook chains or metadata files to trigger dependent service builds when a shared library is released. Fifth, propose concrete mitigations: for monorepo, invest in change-detection algorithms, build caching layers, and CODEOWNERS for scoped approvals; for polyrepo, invest in internal package registries, contract tests, and automated dependency update bots.

COMMON WRONG ANSWERS: Declaring monorepo is always simpler because everything is in one place without acknowledging the CI complexity of rebuilding a thousand services on every commit. Conversely, claiming polyrepo eliminates coupling without explaining how you prevent breaking changes in shared libraries consumed by ten downstream repos. Another red flag is suggesting git submodules as a clean polyrepo solution, since submodules create more CI orchestration pain than they solve. Finally, confusing the repository strategy with the deployment strategy, such as assuming monorepo means monolith or that polyrepo requires microservices.

LIKELY FOLLOW-UPS: How would you migrate from one model to the other without halting releases? What is your strategy for handling security patches across a hundred polyrepo services versus a monorepo? How do you manage long-running feature branches in a monorepo when mainline changes affect multiple services? Describe how you would design a build cache eviction policy for a monorepo with hundreds of daily developers.

ONE CONCRETE EXAMPLE: At a previous company using a monorepo with roughly fifty microservices, CI time ballooned because any commit triggered every pipeline. We mitigated this by migrating to Nx with a distributed task execution graph and remote caching. The CI system computed the affected project graph from the merge base, running only tests and builds for changed services and their dependents. Build times dropped from forty-five minutes to eight minutes for typical changes. In contrast, when I worked with a polyrepo setup, we established an internal npm registry and required every shared library change to pass a downstream compatibility matrix in CI before the artifact could be promoted from release candidate to stable, preventing silent breakages in consuming services.

Source: aviator.co