Какие технические вызовы и сложности возникали во время работы

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

Какие задачи вы считаете сложными и как вы их решаете: через замеры и диагностику или наугад. Следом почти всегда копают в детали: как нашли причину, какими инструментами, что сделали бы иначе.

Как отвечать

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

• утечка горутин: число горутин растёт, память вместе с ним. Нашли через pprof (/debug/pprof/goroutine), причина в незакрытом канале или забытой отмене context.Context;
• гонки данных: плавающий баг, пойманный go test -race, исправление через sync.Mutex, атомики или передачу владения по каналу;
• память и GC: рост потребления в контейнере, профилирование кучи, настройка GOMEMLIMIT и GOGC, переиспользование буферов через sync.Pool;
• пул соединений к базе: таймауты под нагрузкой, потому что SetMaxOpenConns по умолчанию не ограничивает число соединений, подбор лимитов и таймаутов;
• graceful shutdown: потеря запросов при деплое, решение через signal.NotifyContext и http.Server.Shutdown.

Цифры должны быть вашими: p99 до и после, RPS, потребление памяти, число инцидентов. Если нагруженного прода не было, возьмите самый трудный баг из пет-проекта или учебной задачи и честно назовите масштаб. Разобранная утечка горутин в небольшом сервисе звучит лучше, чем выдуманные «тысячи транзакций в секунду».

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

Рассказывают «добавил горутины, и стало в два раза быстрее». Сразу следует вопрос, откуда вы знали, что узкое место в этом, и без профиля ответа нет.

Говорят только «мы». Интервьюеру нужно понять вашу роль: что делали лично вы, а что команда.

Приносят круглые проценты без базы сравнения, вроде «отклик сократился на 30%». Без исходного значения и способа замера цифра вызывает недоверие, а не уважение.