Как принимаются решения о внедрении изменений

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

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

Как отвечать

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

• повод: измеримая проблема, а не вкус. Профиль из pprof, рост p99 задержки, частые инциденты, уязвимость от govulncheck;
• предложение: короткий design doc: что меняем, какие были альтернативы, риски, как откатываться;
• доказательства: прототип в ветке, бенчмарки через go test -bench и сравнение в benchstat, интеграционные тесты, golangci-lint;
• выкатка: фича-флаг, канареечный релиз на часть трафика, метрики на дашборде, заранее оговорённый критерий отката;
• закрепление: решение фиксируется в ADR, чтобы через год было видно, почему выбрали именно так.

Если инициатором вы не были, так и скажите и расскажите, как участвовали: ревьюили design doc, писали бенчмарки, дежурили на выкатке. Это честнее, чем присваивать чужое решение.

Вопрос бывает и обратным, когда его задаёте вы работодателю. Тогда слушайте, кто решает (лид единолично, команда, архитектурный комитет) и сколько проходит от идеи до продакшена.

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

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

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

Не упоминают несогласие. Сильный ответ показывает, как вы приняли отказ команды или переубедили её данными, а не авторитетом.