Было ли кодревью в предыдущей команде

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

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

Как отвечать

Опишите процесс своей команды по шагам и со своими цифрами:

• где и как: pull request в GitHub или merge request в GitLab, сколько нужно аппрувов, кто может мёржить, защищена ли основная ветка;
• что проверялось автоматически: линтер и форматтер (ruff, black), типы через mypy, тесты pytest в CI, хуки pre-commit. Тогда ревьюер не тратит время на пробелы и порядок импортов;
• на что смотрели люди: логика и граничные случаи, наличие тестов, обработка исключений, запросы к базе. В Django это прежде всего N+1, которые лечат select_related и prefetch_related, в любом стеке это миграции на больших таблицах и секреты в коде;
• правила: размер PR (небольшие проходят быстрее и внимательнее), срок реакции на ревью, деление замечаний на обязательные и пожелания.

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

Если ревью не было, скажите прямо и объясните, что его заменяло: парное программирование, самопроверка по чек-листу, тесты в CI. И покажите, как ввели бы его сами: начать с линтера в CI и одного обязательного аппрува, а не с регламента на три страницы.

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

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

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

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