Проводилось ли ревью кода в команде

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

Был ли у вас настоящий процесс или формальная кнопка одобрения. Для Java интервьюер почти сразу уводит разговор в то, что именно вы ищете в чужом коде, и по этому списку видно уровень.

Как отвечать

Опишите процесс коротко: изменения идут запросом на слияние, нужен минимум один одобряющий, сборка гоняет тесты и статический анализ, форматирование правит инструмент, а не человек. Дальше перечислите, что смотрите в самом коде, это и есть содержательная часть ответа:

• согласованность equals и hashCode, неизменяемость объектов, которые кладут в множества и в ключи отображений;
• общее изменяемое состояние и потокобезопасность, в том числе поля синглтонов и бинов Spring;
• закрытие ресурсов через try-with-resources, проглоченные исключения, перехват Exception вместо конкретного типа;
• границы транзакции: вызов метода с @Transactional изнутри того же класса идёт мимо прокси и транзакцию не открывает;
• работа с JPA: запросы в цикле, ленивые связи вне сессии, выборка всей таблицы в список;
• тесты на изменённое поведение и понятность имён.

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

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

Превращают обсуждение в спор о стиле. Пока выясняют порядок модификаторов, мимо проходит гонка на общем поле. Форматирование и очевидные шаблоны отдают инструментам, человеку оставляют архитектуру и ошибки.

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

Путают критику кода с личной. Автор защищается и спорит до последнего, ревьюер пишет в приказном тоне. Рабочая формулировка звучит как предложение с причиной, а не как требование.