Как решали конфликты в код ревью

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

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

Как отвечать

Возьмите реальный случай из своей практики на .NET и разложите его: о чём спор, какие аргументы, чем закончилось. Хорошие темы: async void вне обработчиков событий, .Result и блокирующее ожидание асинхронного кода, AsNoTracking в запросах EF Core на чтение, LINQ против цикла в горячем пути, подавленные предупреждения nullable reference types.

Затем покажите, как вы снижаете конфликтность процесса в целом:

• стиль в автоматику: .editorconfig, анализаторы Roslyn, dotnet format в CI, TreatWarningsAsErrors для важных правил. Спор о скобках и var закрывается правилом, а не комментарием;
• аргументы вместо вкуса: спор о производительности решает замер в BenchmarkDotNet, спор о поведении решает тест, спор о практике решает ссылка на документацию;
• уровень замечания: блокирующее помечается явно, мелочи с префиксом nit: автор вправе не править;
• смена канала: если ветка перевалила за три-четыре ответа, лучше короткий созвон с итогом в пулл-реквесте;
• финальное слово: способ закрыть спор, например решение техлида или запись в ADR, чтобы он не повторялся в следующем ревью.

С вашей стороны как автора: отвечать на каждое замечание, не принимать критику кода как критику себя и спокойно говорить «вы правы, поправлю».

Если острых конфликтов в вашем опыте не было, так и скажите и опишите, как вы действуете при несогласии. Примеры и цифры должны быть вашими.

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

Выбирают историю про форматирование и скобки. Это не конфликт, а отсутствие линтера, и интервьюер задаст именно этот вопрос.

Рассказывают, как «победили» коллегу. Сильнее звучит история, где вы признали чужую правоту или нашли третий вариант.

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