Как руководство относится к предложениям по улучшению архитектуры и технологий

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

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

Как отвечать

Если спрашиваете вы, спрашивайте конкретно, иначе услышите дежурное «у нас всё открыто». Уточните:

• процесс: есть ли design doc или RFC, ADR в репозитории, архитектурный комитет, кто решает и сколько это занимает;
• время на техдолг: выделяется ли доля спринта, или улучшения делаются «в свободное время»;
• версия Go: как быстро обновляются. Официально поддерживаются две последние мажорные версии, и сервис на снятой с поддержки версии многое говорит о приоритетах;
• недавний пример: какое предложение приняли за последний год, какое отклонили и почему. Например, перевод межсервисных вызовов на gRPC, golangci-lint в CI, трассировка через OpenTelemetry, sqlc вместо ORM.

Если вопрос задали вам, соберите историю из своего опыта: какая была проблема, какие замеры вы принесли (pprof, латентность p99 до и после), как оценили цену миграции и риски, кто принимал решение, чем кончилось. Цифры только свои, настоящие. Отклонённое предложение тоже хороший материал: расскажите, какие аргументы оказались весомее и что вы поняли о приоритетах бизнеса. Если опыта не было, опишите, как оформили бы предложение: проблема, замеры, варианты, цена.

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

Спрашивают размыто и не просят реальный пример, поэтому уходят с ответом, который ничего не говорит о команде.

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

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