Кто проверяет merge requests?

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

Как в вашей команде устроено код-ревью и участвуете ли вы в нём сами, в роли автора и в роли ревьюера. За формулировкой «кто» стоит вопрос о культуре качества. Следом обычно спрашивают, на что вы смотрите в чужом MR и как решаете споры в комментариях.

Как отвечать

Опишите процесс, который был у вас, по шагам:

• автоматика до человека: CI собирает проект, гоняет unit-тесты, Android Lint, detekt или ktlint, иногда скриншотные тесты. Пока пайплайн красный, ревьюера не зовут;
• ревьюеры: обычно один или два разработчика из команды. Ответственных за модули назначает файл CODEOWNERS, а защита ветки требует нужное число одобрений перед слиянием;
• техлид или владелец модуля: подключается при изменениях в архитектуре, общих модулях, сборке;
• кто сливает: чаще сам автор после одобрений и зелёного CI, иногда мейнтейнер.

Покажите, на что смотрите именно в Android-коде: утечки Context и подписок, тяжёлая работа в главном потоке, корректная отмена корутин через viewModelScope и lifecycleScope, миграции Room при изменении схемы, новые разрешения в AndroidManifest.xml, правила R8 для классов, которые используются через рефлексию, изменения версий в libs.versions.toml. Для правок интерфейса в описание MR кладут скриншоты или запись экрана.

Добавьте про размер: MR на 200-400 строк реально прочитать внимательно, на 2000 строк ревью превращается в формальность. Большую задачу режут на несколько MR или прячут незаконченное за фиче-флагом.

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

Отвечают одним словом «тимлид». Звучит так, будто у кандидата нет опыта ревью чужого кода, и сразу следует вопрос, почему.

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

Не могут рассказать, как разрешали несогласие. Сильный ответ: аргумент в комментарии, при затяжном споре короткий созвон, решение фиксируется, и спор не переносится на следующий MR.