Code review интервью: вопросы, критерии оценки и почему это лучше алгоритмов

Что такое code review интервью на самом деле

Code review интервью — это ровно то, что звучит в названии: кандидату дают рабочий pull request — от 100 до 400 строк кода, одну фичу или багфикс — и просят его сделать review как товарищ. Он ищет ошибки, предлагает изменения, объясняет свои рассуждения интервьюеру. Иногда там намеренно заложены баги. Всегда там есть моменты, где нужна экспертная оценка.

Это самый недооценённый формат в техническом найме. Большинство интервью по-прежнему выбирают классические алгоритмические раунды или take-home проекты. Оба дают хорошие сигналы для определённых навыков. Но ни один не тестирует то, чем инженеры занимаются больше всего после найма.

Почему это лучше алгоритмического раунда

Три причины, в порядке важности.

1. Это тестирует реальную работу. Инженеры тратят на review кода больше часов, чем на написание с нуля. Интервью, которое не измеряет способность к review, измеряет не ту компетенцию и выдаёт её за инженерное мастерство.
2. Это сложно подделать с ИИ. LLM могут написать diff. Но когда опытный ревьюер имеет защищённую позицию и может её отстоять, LLM теряется в аргументации. Сигнал — в диалоге, а LLM-ориентированные кандидаты в диалоге ломаются.
3. Это масштабируется по уровню сениорности. Джуниоры видят синтаксис и баги. Мидлы видят структуру. Синиоры видят архитектурные выборы, которые скрывает diff (что удалили, что намеренно не изменили). Один и тот же PR, но совершенно разные чтения — это значит, один PR может работать для интервью от L3 до L6 с разными весами в рубрике вместо разных банков вопросов.

Это формат, к которому обращаются команды, когда поняли, что LeetCode не предсказывает и чистый work-sample take-home слишком дорогой для масштабирования на входе воронки.

Как выбрать репозиторий

PR, который вы выберете, определит, измеряет ли интервью экспертное суждение или знание деталей. Три вещи важны:

• Используйте настоящий, аnonimized код. Игрушечный фрагмент с тремя очевидными ошибками обучает кандидатов искать подвохи. Настоящий diff со смешанным качеством изменений заставляет их действительно читать.
• Выбирайте домен, который кандидат не зубрил. Избегайте TODO приложения или LeetCode-стиля алгоритма. Используйте что-то с бизнес-логикой — правило прайсинга, проверку прав доступа, политику повторных попыток. Знакомство с доменом — это не сигнал.
• Убедитесь, что есть хотя бы одно защищённое суждение. Лучшее code review интервью не имеет "неправильных" ответов и три места, где внимательный ревьюер мог бы спорить в обе стороны. Вот где вы измеряете сениорность.

Проводите раунд с diff загруженным в настоящий редактор — не в статичный PDF. Collaborative coding rooms ClarityHire открывают файл с аннотациями и треадом комментариев, который интервьюер может смотреть в реальном времени, поэтому review ощущается как нормальный GitHub PR, а не допрос.

Четырёхмерная рубрика оценивания

Возьмите структуру из системной рубрики дизайна, но переделайте размерности для review работы.

1. Идентификация проблем

Они поймали то, что поймал бы настоящий review? Оценивайте по плотности и серьёзности:

• 4 — поймали несущую проблему (безопасность, корректность или архитектура) плюс мелочи
• 3 — поймали несущую проблему ИЛИ большинство мелочей
• 2 — поймали поверхностные ошибки, но пропустили структурную проблему
• 1 — пропустили несущую проблему и придирались к форматированию

2. Приоритизация

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

3. Качество аргументации

Для каждого комментария, который они оставляют, могут ли они объяснить trade-off? "Я бы выделил этот хелпер" — это B-уровневый комментарий. "Я бы выделил этот хелпер, потому что та же логика есть в потоке отмены заказа и мы хотим их развивать вместе" — это синиор версия. Оценивайте специфичность, не словарный запас.

4. Тон и сотрудничество

Code review — это навык в отношениях. Ревьюер, который технически прав, но пишет комментарии, которые ненавидит команда — это чистый минус. Оценивайте: комментарий звучит как предложение, которое автор может реализовать, или как укор?

Это размерность, которую большинство интервью вообще не могут измерить. Code review интервью это чисто выявляют.

Примеры вопросов для якорения разговора

Это подсказки, которые интервьюеры должны придержать до того, как кандидат сам сделает свой pass:

• "Пройдитесь по комментариям, которые вы действительно оставили бы, в порядке, в котором вы их оставили бы."
• "Какой один комментарий вы сделали бы блокирующим?"
• "Если автор возразит на ваш самый важный комментарий, какой ваш второй по силе аргумент?"
• "Что не в этом diff, но должно быть? Что вы бы спросили в описании PR?"
• "Что вы бы не поднимали, хотя заметили?"

Последний вопрос — самый дискриминирующий по сениорности из всего набора. Знание того, что игнорировать — половина эффективного code review.

Как оценить открытый review

Интервью производит беспорядочные артефакты — inline комментарии, транскрипт вербального обхода, иногда письменное резюме. Три правила для согласованной оценки:

• Используйте общий шаблон оценки для каждой роли. Построьте его один раз из вашей библиотеки рубрик и переиспользуйте для кандидатов.
• Оценивайте артефакт и разговор отдельно. Кандидат, который написал отличные комментарии, но спорил плохо в живом обсуждении — это другой наём, чем если бы это было наоборот.
• Запустите письменный раунд в масштабе, живой лично для финалистов. AI-помощь при оценке письменных комментариев даёт полезный первый pass по плотности и специфичности на входе воронки, где вы не можете позволить себе живое время. Живой раунд подхватывает сигнал разговора, который оценка не может.

Сопротивление ИИ-помощи во время раунда

Если кандидат прогонит diff через Claude или GPT в другой вкладке, комментарии, которые они вставят, будут технически плотные, но стилистически несовместимы с их собственной аргументацией в обсуждении. Два способа это выявить:

• Смотрите паттерны редактирования — чистые, большие вставки структурированной прозы, за которыми идёт молчание — это признак, так же как в coding раунде
• Сделайте живое обсуждение обязательным и состязательным: возьмите самый сильный комментарий кандидата и спорьте против него. ИИ-авторские комментарии ломаются, когда кандидат не может защитить конкретную фразу, которую он выбрал

Вам не нужно запрещать ИИ, чтобы раунд работал. Вам нужно его спроектировать так, чтобы кандидат, полагающийся только на ИИ, не мог пройти половину разговора.

Что делать дальше

Выберите один PR из вашего кодбейза, аnonimize его и пилотируйте раунд с двумя текущими инженерами на следующей неделе. Пусть они сделают review diff с холодной головой и оценят себя по рубрике. Любое несовпадение между их оценкой и вашим интуитивным чувством того, как они действительно делают review на работе — это несовпадение, которое ваша рубрика исправляет. Потом запустите это на следующем цикле найма и сравните оценки кандидатов с вашими существующими результатами coding assessment. В нашей базе клиентов ранжирование сдвигается — и новый порядок лучше коррелирует с тем, кто действительно показывает результаты после найма.