Как оценивать навыки сотрудничества с ИИ на интервью по программированию

Когда работа с ИИ становится навыком, а не поведением, которое нужно выявить

За большую часть последних двух лет ИИ на интервью был чем-то, от чего нужно было защищаться. Рубрика была простой: "использовал ли кандидат ИИ и поймали ли мы его?" Этот подход все еще применим в раундах, где ИИ запрещен, и механизм защиты, который выявляет злоупотребления там, — это настоящая работа.

Но в том же цикле все больше компаний проводят один раунд, где ИИ требуется. Meta, Canva, Shopify и Coinbase явно оценивают кандидатов по умению сотрудничать с ИИ. Если ваш цикл движется в этом направлении, вам нужна рубрика — потому что если вы скажете кандидату "используй любые инструменты, которые хочешь" и оцените его только по тому, работает ли финальный код, вы практически ничего не узнаете. Работающий код — это вклад ИИ. Навык — это то, что приносит в это сотрудничество кандидат.

Этот пост предназначен для руководителей по найму, которые разрабатывают раунд с ИИ-сотрудничеством. Четыре измерения для оценки, один формат упражнения и распространенные ошибки интервьюеров, которые разрушают сигнал.

Четыре измерения, достойные оценки

Полезная рубрика для оценки ИИ-сотрудничества проверяет навыки, которые можно наблюдать в течение 45 минут и которые отличают инженера, хорошо использующего ИИ, от того, кто просто копирует его выход. Четыре измерения с якорями на каждом уровне.

1. Качество запросов и декомпозиция проблемы

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

На что обращать внимание:

• Переформулировал ли кандидат проблему своими словами перед запросом?
• Указал ли он ограничения для модели — пути файлов, сигнатуры функций, структуру данных, примеры ожидаемого вывода?
• Просит ли он одно за раз или вставляет весь брифинг в надежде на везение?

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

2. Проверка и скептицизм

Это измерение чаще всего отличает сильных кандидатов от слабых. Модель выдает результат. Что делает с ним кандидат?

Самый сильный сигнал — проверяет ли кандидат перед интеграцией. Конкретные поведения:

• Построчное чтение сгенерированного кода перед его вставкой
• Запуск кода на тестовых случаях, которые составил сам кандидат (не те, которые предложила модель)
• Обнаружение галлюцинированной функции или библиотеки и либо переформулирование запроса, либо самостоятельная замена
• Замечание, что выход правдоподобен, но неправилен на граничном случае

Самое слабое поведение — "вставь и молись": кандидат копирует код модели в редактор, запускает основной сценарий, видит зелень и двигается дальше. Это эквивалент того, как младший инженер мержит пул-запрос, не читая дифф.

Используйте тот же анализ согласованности кода, который помечает ИИ-сгенерированный код в асинхронных оценках. В раунде, требуемом ИИ, оценка — это не "использовал ли кандидат ИИ" — это ожидается. Оценка — это показывают ли правки кандидата к выходу ИИ признаки чтения и размышления, или диф — это чистая вставка.

3. Контроль над циклом

Младшие кандидаты следуют туда, куда ведет ИИ. Сильные кандидаты ведут ИИ.

Конкретные поведения, на которые нужно обращать внимание:

• Когда модель дает неправильный ответ, диагностирует ли кандидат и переформулирует запрос с исправленным ограничением — или просто регенерирует, надеясь на другой ответ?
• Когда модель предлагает архитектуру, с которой кандидат не согласен, возражает ли он ("Я предпочитаю здесь использовать конечный автомат, можешь ли ты переделать это с этим паттерном?") или просто принимает предложение?
• Когда модель уходит в сторону (рефакторит что-то, о чем кандидат не просил), замечает ли кандидат и возвращает ее на курс?

Это измерение невидимо без записи экрана. Убедитесь, что раунд захватывает историю запросов и диф редактора вместе, а не только финальный код.

4. Коммуникация при работе в паре с ИИ

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

Вот что хорошо выглядит:

• Объяснение перед запросом: "Я собираюсь попросить Claude набросать парсер. Я ожидаю, что он правильно сделает токенизацию, но, вероятно, неправильно обработает экранированные символы — мне это придется исправить."
• Показ запроса перед его отправкой
• Озвучивание несогласия с моделью, а не молчаливое недовольство
• Четкое различение своего вклада от вклада модели при объяснении кода

Слабая версия: молчаливые запросы, долгие паузы, пока кандидат читает выход модели без объяснения своих мыслей, код появляется в редакторе без объяснения откуда. Кандидат, который молча кодит с ИИ, будет молча работать и с людьми, а это сигнал о динамике команды, который вы хотите выявить в цикле.

Упражнение, которое выявляет эти навыки

Искушение — дать кандидату задачу на алгоритм и позволить использовать ИИ. Не делайте этого. ИИ решит задачу за секунды, и кандидат потратит 40 минут на редактирование комментариев. Вы ничего не узнаете.

Хорошее упражнение имеет три свойства:

1. Многошаговое, с встроенным сюрпризом. Начните с небольшой задачи, которую кандидат может явно решить. На полпути введите запрос на изменение, который нарушает предположение — новый формат данных, требование по производительности, устаревшая библиотека. Адаптация — вот где проявляется навык ИИ-сотрудничества.
2. Тонко сломанная начальная точка. Дайте кандидату код, который компилируется и работает, но имеет тонкую ошибку — ошибку на единицу, проглоченное исключение, race condition под нагрузкой. Посмотрите, ловят ли они это сами или доверяют ИИ найти это. Большинство моделей не найдут тонкую ошибку без явной подсказки.
3. Компонент документации или исследования. Задача требует интеграции с незнакомой библиотекой или API. Модель о них знает. Кандидат должен проверить утверждения модели против реальной документации. Разрыв между "модель утверждает" и "документация говорит" — это богатый сигнал.

Сорок пять минут на весь раунд. Редактор совместного кодирования ClarityHire запускает Monaco с встроенным выполнением и парит его с захватом истории запросов, так что интервьюер может видеть диф редактора и беседу с моделью бок о бок во время разбора — не только финальный код.

Якоря оценки, от 1 до 4

Оцените каждое измерение независимо по шкале от 1 до 4. Привяжите уровни к конкретным поведениям, а не к прилагательным.

Качество запросов (1–4):

• 1: Вставляет всю формулировку проблемы в модель; нет разбиения на части.
• 2: Просит функцию целиком, но добавляет как минимум одно ограничение.
• 3: Разбивает задачу на две или три части; запрашивает каждую отдельно с релевантным контекстом.
• 4: Пишет хорошо определенные запросы, которые включают сигнатуру функции, структуру данных и проработанный пример.

Проверка (1–4):

• 1: Вставляет выход модели без чтения.
• 2: Читает выход, но тестирует только счастливый путь.
• 3: Составляет как минимум один тестовый случай независимо от предложений модели; обнаруживает как минимум одну проблему.
• 4: Относится к каждому выходу как к подозрительному; проверяет против реальной документации, реальных тестовых данных и граничных случаев перед интеграцией.

Контроль (1–4):

• 1: Следует тому, что производит модель; регенерирует вместо переформулирования при ошибке.
• 2: Переформулирует с тем же контекстом после ошибки; иногда замечает, когда модель сбивается.
• 3: Диагностирует, почему модель неправа, и переформулирует с исправленным ограничением.
• 4: Сам задает архитектуру и использует модель для тактических деталей; возражает, когда модель предлагает другой подход.

Коммуникация (1–4):

• 1: Молчаливые запросы; выход появляется в редакторе без объяснений.
• 2: Объясняет финальный результат, но не процесс.
• 3: Объясняет перед запросом и показывает запрос интервьюеру.
• 4: Четко различает свой вклад от вклада модели; озвучивает несогласие с моделью.

Используйте структурированную карточку оценки, где каждый интервьюер фиксирует свою оценку перед разбором. Измерения достаточно независимы, поэтому несогласие между интервьюерами информативно — один может оценить кандидата 4 за проверку и 2 за коммуникацию, и этот паттерн — именно то, что стоит обсуждать.

Распространенные ошибки интервьюеров

Пять ошибок, которые разрушают сигнал в этом раунде:

1. Оценка финального кода. Код — это вклад ИИ. Суждение, запросы и правки — это вклад кандидата. Оцените именно это.
2. Просьба кандидату "объяснить, что сделала ИИ". Это тестирует понимание прочитанного, а не сотрудничество. Вместо этого спросите "что бы ты изменил в том, как ИИ подошла к этому?"
3. Позволение раунду быть молчаливым. Если кандидат молчит две минуты, читая выход модели, подскажите ему: "расскажи мне, на что ты смотришь". Молчание — это не тест; вы оцениваете, как они работают в паре.
4. Выбор задачи, которую модель может решить с первой попытки. Тривиальная задача означает, что кандидат никогда не должен демонстрировать контроль, проверку или восстановление после ошибки. Выберите задачу, которая требует как минимум одного раунда несогласия с моделью.
5. Забывчивость о базовом уровне защиты. Это раунд, требуемый ИИ, но вы все еще в том же цикле, что и раунд, запрещающий ИИ. Если паттерн печати кандидата в этом раунде выглядит идентично раунду без ИИ, это интересно — как по хорошим причинам (кандидат действительно печатает так), так и по подозрительным (один и тот же помощник вне кадра запускает оба раунда).

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

Если вы собираетесь добавить раунд ИИ-сотрудничества в ваш цикл:

1. Решите, какие из четырех измерений наиболее важны для конкретной роли. Инженер прикладного машинного обучения, вероятно, будет взвешивать проверку выше всего; обобщенный инженер-программист может взвешивать коммуникацию.
2. Разработайте одно упражнение, которое включает сюрприз в середине и тонкую ошибку в начале. Напишите якоря перед тем, как первый кандидат его увидит.
3. Захватите историю запросов вместе с диффом редактора. Без запросов вы оцениваете код; с ними вы оцениваете инженера.
4. Откалибруйте с двумя интервьюерами на записанной сессии перед запуском в боевом режиме. Несогласие между ними — это ваша рубрика.
5. Оцените этот раунд независимо от раунда, запрещающего ИИ. Они измеряют разные вещи, и их смешивание вознаградит неправильного кандидата.

Цель этого раунда не в том, чтобы найти кандидатов, которые могут использовать ИИ — почти все кандидаты могут. Это найти тех, чей суд, проверка и направление достаточно хороши, чтобы помощь ИИ стала настоящей силой, вместо дорогостоящей игры в "вставь и молись".