Бывали ли ситуации несогласия с замечаниями в код ревью

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

Умеете ли вы спорить по делу: отделять вкусовщину от реальных проблем, приносить аргументы, а не упрямство, и доводить спор до решения. Следом обычно спрашивают: «А если бы вас так и не убедили, что бы вы сделали?»

Как отвечать

Нужна одна реальная история из вашей практики, коротко: что было в PR, в чём суть замечания, почему вы не согласились, как проверили, чем закончилось. Цифры и детали только свои, выдуманный «рост производительности на 40%» разваливается на первом же уточнении.

Сюжеты для C#-разработчика:

• производительность: ревьюер просил переписать LINQ на цикл «ради скорости». Вы сделали замер в BenchmarkDotNet и показали, что на реальных объёмах разница в пределах шума, а LINQ читается лучше. Или замер убедил уже вас;
• асинхронность: спор про ConfigureAwait(false) в коде приложения на ASP.NET Core, где нет SynchronizationContext, или про async void вне обработчиков событий;
• архитектура: выносить логику в сервис сейчас или отдельной задачей, чтобы не раздувать PR;
• стиль: var, именование. Такие споры закрывают правилом в .editorconfig и анализаторах.

Поведение, которое стоит показать:

• сначала понять: переспросить, что имел в виду ревьюер, иногда несогласие оказывается недопониманием;
• проверяемый аргумент: тест, бенчмарк, ссылка на документацию Microsoft или на принятый в команде гайд;
• голосом, если переписка затянулась: после двух-трёх кругов комментариев быстрее созвониться;
• решение без обид: если не сошлись, решает техлид или договорённость команды, и решение фиксируется, чтобы не спорить снова.

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

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

Рассказывают историю, в которой кандидат был полностью прав, а коллега ничего не понимал. Это звучит как неумение работать с людьми.

Уходят в другую крайность: «я всегда соглашаюсь с ревьюером». Это сигнал, что вы не отстаиваете качество кода.

Не называют итог. Интервьюеру важно, чем закончилось и что поменялось в процессе команды.