Кто инициирует рефакторинг и улучшения

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

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

Как отвечать

Короткий ответ: инициировать может любой, кто работает с кодом, а решение о больших переделках принимается вместе с техлидом и тем, кто ведёт бэклог. Дальше разведите два масштаба:

• мелкий рефакторинг: делается попутно в задаче, по принципу «оставь код чище, чем был». Переименование через gopls, вынос функции, замена interface{} на any, ioutil на io и os, обёртка ошибок через %w с проверкой errors.Is. Отдельного согласования не требует, но лучше отдельным коммитом, чтобы ревьюеру было видно;
• крупный: смена структуры пакетов, переход на другой драйвер базы, переделка работы с горутинами и каналами. Здесь нужна задача в бэклоге с обоснованием, оценкой и планом отката.

Обоснование сильнее, когда опирается на данные, а не на вкус: профиль pprof с горячей функцией, гонка, найденная go test -race, предупреждения golangci-lint и staticcheck, частота инцидентов в одном модуле, время, которое уходит на типовую доработку.

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

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

Отвечают «это решает тимлид». Звучит как отсутствие инициативы, даже если в прошлой команде так и было.

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

Объясняют пользу словами «код стал чище» без измеримого эффекта. Хотя бы одна цифра или конкретная проблема, которая ушла, делает историю убедительной.