Используется монорепозиторий или несколько репозиториев

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

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

Как отвечать

Коротко разведите подходы и сразу переводите разговор на тестирование:

• монорепозиторий: все сервисы, общие библиотеки и тесты в одном репозитории. Изменение API и правка тестов идут одним merge request и проверяются вместе. Чтобы не гонять всё на каждый коммит, пайплайн вычисляет затронутые проекты: nx affected в Nx, Turborepo, Bazel, фильтры по путям в GitLab CI;
• много репозиториев: у каждого сервиса свой репозиторий, релизный цикл и пайплайн. Команды независимы, но появляется матрица версий: какой фронт с каким бэкендом совместим;
• автотесты отдельно: частый вариант, отдельный репозиторий с автотестами. Минус в том, что тесты и код расходятся, и нужна договорённость, какая ветка тестов соответствует какой версии приложения.

Для схемы с многими репозиториями добавьте контрактное тестирование, например Pact: оно ловит несовместимость API до того, как сервисы встретятся на стенде. Для монорепозитория скажите про CODEOWNERS и время прогона пайплайна.

Расскажите, как было у вас и что это означало для вашей работы: где лежали тесты, запускались ли они на каждый merge request, кто чинил упавшие.

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

Путают монорепозиторий с монолитом. В одном репозитории может жить десяток микросервисов, которые деплоятся независимо.

Отвечают без собственной позиции. «Работал с обоими, у каждого свои плюсы и минусы» без примера из своего проекта звучит как пересказ статьи.

Не связывают ответ с тестированием. Интервьюеру важно услышать, как вы понимали, какую версию проверяете и почему упал тест: из-за кода или из-за рассинхрона версий.