Сколько разработчиков можно привлечь для максимальной параллельной работы

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

Понимаете ли вы, что работа людей не масштабируется линейно, и умеете ли объяснить это через структуру задачи, а не лозунгом. Вопрос почти всегда идёт следом за оценкой сроков: интервьюер хочет услышать, чем на самом деле ограничен параллелизм.

Как отвечать

Главный тезис: предел задаёт не число людей, а зависимости внутри задачи. Разложите работу на куски и посмотрите, сколько из них можно делать одновременно. Столько исполнителей и имеет смысл ставить, остальные будут ждать. Неделимый кусок (миграция схемы, один общий модуль, согласование контракта) задаёт критический путь и не сократится ни при каком числе людей.

Второе: с ростом команды растут издержки. Число связей между участниками растёт квадратично, поэтому каждый следующий человек приносит меньше предыдущего, а с какого-то момента начинает замедлять. Новичков ещё и вводит в контекст тот, кто сейчас пишет код. Формулировку Брукса про то, что люди, добавленные в горящий проект, делают его ещё более поздним, уместно назвать вслух.

Третье: чем ограничение реально снимается. Ранняя договорённость о контрактах, заглушки вместо ожидания чужого кода, нарезка по границам модулей, а не по слоям, короткие ветки и частые вливания, фиче-флаги.

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

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

Второе: слышат слово «параллельная» и уезжают в технику, начиная рассказывать про потоки, GIL и asyncio. Про это спросят отдельно, здесь речь о людях, и подмена темы выглядит как попытка ответить заготовкой.

Третье: забывают про то, что не параллелится в принципе. Ревью, приёмка и выкатка обычно идут через одного или двух человек, и когда пишущих становится вдвое больше, очередь на ревью превращается в новое узкое место, а сроки не меняются.