Что нравилось и что хотелось бы изменить в процессе код-ревью на последнем проекте
Что проверяют
Умеете ли вы критиковать процесс, а не людей, и есть ли у вас представление о том, каким код-ревью должно быть. Заодно прикидывают, как вы себя ведёте внутри ревью: будете ли спорить с командой из-за стиля и как принимаете замечания.
Как отвечать
Говорите про реальный процесс и разделяйте: что работало, что мешало, что бы поменяли и какой ценой.
Обычно работает: небольшие пул-реквесты, автоматика до человека (go vet, линтеры, gofmt, прогон тестов с -race), договорённости по стилю вынесены в конфиг, а не в спор. В Go это особенно заметно: язык сам снимает половину стилевых дискуссий, и ревью остаётся про существенное, про обработку ошибок и обёртки к ним, про границы пакетов, про то, кто закрывает ресурс и отменяет контекст, про гонки в тестах.
Проблемы стоит называть прямо: ревью висит днями и блокирует ветку; непонятен вес комментария, блокер это или пожелание; один человек оказывается бутылочным горлышком на весь сервис; архитектуру начинают обсуждать, когда код уже написан.
Улучшения формулируйте как договорённости: помечать важность комментария, ограничить размер изменения, обсуждать подход до реализации, назначить второго ревьюера на критичные пакеты, повторяющиеся замечания уносить в линтер.
Где спотыкаются
Съезжают в жалобу на коллег. «Ревьюили долго и придирались» звучит как рассказ о конфликте, а не о процессе. Тот же факт нормально формулируется через сроки и договорённости.
Говорят, что всё было идеально. Это читается либо как отсутствие опыта, либо как нежелание думать про процесс: вопрос задан именно ради второй половины, и пустой ответ на неё запоминается.
Предлагают улучшения, за которые сами не платили. Два обязательных апрува в маленькой команде удлиняют цикл вдвое, а строгий шаблон ревью превращается в формальность, и про эту цену лучше сказать самому.