> Что нравилось и что хотелось бы изменить в процессе код-ревью на последнем проекте (Go)

Короткий ответ

На последнем проекте нравилось, что код-ревью было обязательным и быстрым: среднее время до первого комментария - меньше двух часов. Хотелось бы изменить культуру: убрать формальные approve без реального чтения diff. Также не хватало чек-листа для критичных мест: обработка ошибок, контексты, graceful shutdown. Предлагал ввести ротацию ревьюеров и метрику "комментариев на 100 строк", но не успел довести до конца.

Пример по STAR

Ситуация: В команде из шести backend-разработчиков на Go мы поддерживали монолит с десятками микросервисов. Код-ревью формально существовало, но часто сводилось к "LGTM" через пять минут после открытия pull request.

Задача: Мне как senior-разработчику нужно было повысить качество ревью без роста времени на merge. Основная боль - пропущенные баги в конкурентном коде и необработанные ошибки.

Действия: Я предложил три изменения. Первое - шаблон pull request с обязательными пунктами: как тестировал, какие edge cases покрыл, есть ли изменения в API. Второе - ротация: каждый разработчик раз в неделю был "дежурным ревьюером" и проверял все PR в своём сервисе. Третье - я начал оставлять комментарии не только про баги, но и про альтернативы: например, почему errgroup лучше ручного WaitGroup в конкретном месте.

Результат: Через месяц количество комментариев на PR выросло с 0.8 до 2.3, а время до merge увеличилось всего на 15 минут. Мы поймали два race condition до продакшена. Однако сопротивление осталось: двое разработчиков считали ротацию дополнительной нагрузкой. Я не смог полностью убрать формальные approve - это осталось как задача для следующего квартала.

Как отвечать на собеседовании

Сначала назовите одну конкретную вещь, которая нравилась, и одну, которую хотели бы изменить. Не говорите абстрактно "всё было хорошо" или "всё было плохо". Приведите метрику или пример: время до первого комментария, количество найденных багов, конкретный случай. Покажите, что вы не просто критиковали, а предлагали решение и измеряли эффект. Если изменение не удалось - честно скажите почему и что бы сделали иначе. Для senior-уровня важно показать, что вы влияли на процесс, а не только на код.

Что проверяет интервьюер

Интервьюер хочет услышать, что вы умеете давать и принимать обратную связь. Проверяется, отделяете ли вы личные предпочтения от объективных проблем процесса. Также важно, как вы работаете с сопротивлением: давите, договариваетесь или отступаете. Для backend на Go отдельно смотрят, упоминаете ли вы специфичные для языка вещи: обработку ошибок, конкурентность, context. Ещё один сигнал - готовы ли вы признать, что не всё получилось. Senior-кандидат, который говорит только об успехах, вызывает меньше доверия.

Типичные ошибки

Говорить только о том, что нравилось, и избегать критики. Или наоборот - жаловаться на коллег без предложений. Называть абстрактные проблемы без примеров: "мало ревьюили" вместо "среднее время до первого комментария - 8 часов". Приписывать все улучшения себе, игнорируя командную работу. Не упоминать метрики или результат. Путать код-ревью с парным программированием. Забывать, что интервьюер может спросить: "А что вы сделали, когда коллега не согласился?" - и не иметь ответа.