Был ли использован монорепозиторий

Что проверяют

Не само слово «монорепозиторий», а понимаете ли вы, как он влияет на сборку, зависимости и работу нескольких команд. Следом обычно спрашивают, как у вас собирались только изменённые модули и кто решал, какую версию библиотеки использовать.

Как отвечать

Это вопрос про ваш опыт, поэтому говорите о своём проекте, со своими цифрами. Каркас такой:

• что лежало в репозитории: сколько сервисов и общих модулей, одна ли команда или несколько;
• чем собиралось: Maven multi-module с общим родительским pom.xml или Gradle multi-project с settings.gradle. На больших масштабах встречаются Bazel и Pants;
• версии зависимостей: единый dependencyManagement или BOM в Maven, version catalog libs.versions.toml в Gradle. Главный плюс монорепо в том, что общая библиотека и все её потребители меняются одним коммитом;
• CI: собирать всё на каждый коммит быстро становится дорого. Решения: mvn -pl service-a -am для сборки модуля с зависимостями, build cache Gradle, запуск тестов только по затронутым модулям;
• владение кодом: CODEOWNERS, правила ревью по каталогам.

Назовите и минусы, с которыми сталкивались лично: долгий CI, тяжёлый клон, случайные связи между модулями, одинаковые права на весь код.

Если работали только с отдельными репозиториями, так и скажите и расскажите, как решали ту же задачу: общая библиотека публиковалась в Nexus или Artifactory, и её версию поднимали в каждом сервисе отдельно. Затем объясните, в каких условиях выбрали бы монорепо, и это будет честный и сильный ответ.

Где спотыкаются

Пересказывают определение из статьи без единой детали своего проекта. Интервьюер сразу задаёт вопрос про сборку, и ответ рассыпается.

Называют плюсы и не видят цены. Без слов про время CI и границы модулей ответ звучит как чужой опыт.

Придумывают эффектные цифры вроде «ускорили интеграцию на 40%». Про них спросят, как считали, и лучше иметь реальные данные: минуты сборки до и после, число модулей.