Был ли опыт работы с монорепозиториями

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

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

Как отвечать

Опирайтесь на свой проект, примеры и цифры должны быть ваши. Каркас:

• что лежало внутри: например, два приложения на React или Next.js, UI-кит, общий пакет с типами и API-клиентом, общие конфиги ESLint и TypeScript;
• инструменты: workspaces в pnpm, npm или Yarn для связи пакетов, поверх них Turborepo или Nx для графа задач. Lerna сейчас используют в основном для публикации версий, для версий и changelog часто берут Changesets;
• кэш и выборочная сборка: локальный и удалённый кэш задач, запуск только затронутых пакетов (nx affected, фильтры --filter в Turborepo). Это главный ответ на «CI стал медленным»;
• границы: кто владеет пакетами (CODEOWNERS), правила импортов между слоями, запрет тянуть код приложения в библиотеку;
• что болело: две копии React в node_modules, фантомные зависимости при hoisting, долгая установка, конфликты при одновременном обновлении общих пакетов.

Хороший ответ заканчивается выводом: что бы вы сделали иначе и когда монорепо не нужен, например у независимых команд с разными циклами релиза.

Если опыта не было, скажите прямо и расскажите, как у вас делились общим кодом: приватный npm-реестр, git-подмодули, копирование. Назовите боль этого подхода (рассинхрон версий UI-кита между проектами), объясните, как монорепо её снимает и что вы проверили бы первым. Такой ответ честнее и убедительнее выдуманного опыта с Lerna.

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

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

Перечисляют инструменты без причин выбора. Интервьюеру важно, почему Turborepo, а не Nx, и какую проблему это решило.

Приводят круглый процент ускорения без базы сравнения. Скажите, сколько шёл CI до и после кэша и на каком объёме кода.