Monorepo vs polyrepo for a product portfolio

WHAT THIS TESTS The interviewer wants tradeoff reasoning, not a fashion statement. Both models work; the senior skill is matching the model to how coupled the products and their release cadences actually are, and explaining the tooling consequences.

A GOOD ANSWER COVERS For a monorepo: shared components live in one place, so a change and all its consumers update atomically in a single commit, there is one source of truth and no version drift, and large refactors are tractable. The cost is needing build tooling like affected-target detection so CI only builds and tests what changed, plus discipline to prevent unintended coupling. Independent deployment still works: each product has its own pipeline triggered by changes to its paths. For a polyrepo: each product owns its repo and deploys fully independently with strong team autonomy, but shared components must be published as versioned packages, which introduces version drift and the coordination of upgrading five consumers. Tie the recommendation to the products: tightly related products that frequently change shared code lean monorepo; loosely coupled products with very independent cadences and separate ownership lean polyrepo.

COMMON WRONG ANSWERS Asserting monorepos or polyrepos are always superior. Claiming a monorepo forces lockstep deploys (it does not with per-path pipelines). Ignoring how shared-component versioning differs between the two. Forgetting CI scaling tooling for a monorepo.

LIKELY FOLLOW-UPS How do you keep monorepo CI fast at scale? How do you manage shared-package version drift in polyrepo? How do you enforce module boundaries in a monorepo?

ONE CONCRETE EXAMPLE If the five products share a common design system and domain model that change weekly, a monorepo with affected-build CI lets a design-system update land atomically across all consumers in one reviewed PR, each product still deploying on its own schedule via path-triggered pipelines. If instead the products are largely independent with separate teams and rare shared changes, polyrepo with a versioned shared package and Renovate-style upgrade PRs fits better.