> Приведи пример самого частого комментария в код-ревью (Go)

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

Самый частый комментарий в код-ревью на Go - про обработку ошибок. Кандидаты часто игнорируют err или логируют его без контекста. Я обычно пишу: добавь %w для wrapping и верни ошибку наверх, а не глотай её. Это снижает время дебага в проде.

Пример по STAR

Ситуация: в одном из сервисов на Go мы разбирали инцидент, где падал воркер при обработке платежей. Ошибка терялась в логах, потому что в коде было if err != nil { return nil }. Задача: понять, почему падает, и не допустить повторения. Действие: я оставил комментарий в код-ревью с примером return fmt.Errorf("process payment: %w", err) и добавил чек-лист по ошибкам в шаблон PR. Результат: за две недели доля PR с корректным wrapping выросла с 40% до 85%, а среднее время поиска причины ошибки в логах сократилось с 30 до 5 минут.

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

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

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

Проверяет, умеешь ли ты давать обратную связь в код-ревью. Смотрит, понимаешь ли ты типичные проблемы Go-кода, особенно обработку ошибок. Оценивает, можешь ли ты аргументировать свою позицию и предлагать улучшения. Также важно, как ты относишься к чужому коду и умеешь ли отделять личное от профессионального.

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

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