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

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

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

Как отвечать

Нужна одна реальная история из вашей практики, не собирательная. Каркас:

• контекст: что за изменение и какое замечание. Во фронтенде это обычно выбор между локальным состоянием и стором, лишние useMemo и useCallback, новая зависимость ради одной функции, доступность (кнопка на div без role и клавиатуры), размер бандла;
• почему вы были не согласны: аргумент технический, а не «мне так привычнее»;
• как решали: сначала уточнили, что именно беспокоит ревьюера, потом принесли факты. React Profiler показывает лишние рендеры, bundle analyzer показывает вес библиотеки, Lighthouse и axe находят проблемы доступности, ссылка на документацию закрывает спор о рекомендуемом подходе. Если переписка ходила по кругу, созвонились на десять минут;
• итог: кто оказался прав. Хорошо, если в одной из ваших историй это были не вы;
• что изменили в процессе: правило в ESLint, пункт в гайде по ревью, договорённость помечать мелочи префиксом nit: в духе Conventional Comments, чтобы необязательное не блокировало мерж.

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

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

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

Говорят «я всегда соглашаюсь с замечаниями». Это не гибкость, а признак того, что вам нечего защищать.

Спорят о вкусе: отступы, кавычки, порядок импортов. Такие вещи решают Prettier и настроенный линтер, а не обсуждение в каждом пулреквесте.