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

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

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

Как отвечать

Возьмите свой реальный случай и расскажите по порядку: суть спора, аргументы сторон, чем проверяли, итог, вывод. Хорошие темы из стека React и TypeScript:

• производное состояние в useEffect: стейт синхронизируют эффектом, хотя значение можно вычислить при рендере. Аргументы: лишний рендер и раздел документации React «You Might Not Need an Effect»;
• мемоизация: useMemo и useCallback на всём подряд или нигде. Спор решает React Profiler, а не мнение, а в проекте с React Compiler ручная мемоизация чаще всего не нужна;
• типы: any и as вместо сужения типов, отключённый strict;
• доступность: div с onClick вместо button. Здесь аргумент объективный: клавиатура и скринридер;
• зависимости: новая библиотека ради одной функции. Аргументом служит размер бандла по отчёту анализатора.

Покажите, как снимаете повторяющиеся споры: ESLint с eslint-plugin-react-hooks и eslint-plugin-jsx-a11y, Prettier, проверки в CI. Для визуальных правок помогает превью-стенд на пулл-реквест или история в Storybook.

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

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

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

Выдают архитектурный выбор за конфликт в ревью, как в истории «я убедил команду взять Context вместо Redux». Такой спор должен идти до написания кода, а сам Context не заменяет стейт-менеджер для часто меняющихся данных: каждое изменение значения перерисовывает всех потребителей.

Спорят о форматировании. Это задача Prettier, и такая история говорит об отсутствии настроенного инструмента.

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