Насколько большие проекты у тебя были

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

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

Как отвечать

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

Дальше про то, что на этом масштабе ломается и чем вы это лечили:

• context с таймаутом и отменой на всю цепочку вызовов, иначе горутины копятся;
• ограничение параллелизма пулом воркеров или семафором вместо неограниченного разветвления;
• errgroup для групп вызовов, аккуратное завершение при ошибке одного;
• профилирование через pprof, снижение аллокаций и давления на сборщик мусора;
• размер пула соединений к базе, ретраи только там, где операция идемпотентна, корректное завершение по сигналу.

Закончите одной историей, где масштаб реально что-то сломал, и что поменяли после.

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

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

Подменяют свой вклад стеком проекта. Перечислять Kubernetes, gRPC и очереди легко, но интервьюеру нужно, за какие сервисы отвечали лично вы, что писали с нуля, что поддерживали. Честное «я вёл два сервиса в большой системе» звучит сильнее размытого «мы».

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