Политика ИИ при техническом собеседовании: как разработать и оценивать работы
Вопрос политики, на который каждой инженерной команде приходится давать ответ
Meta открыла двери первой. Shopify, Canva и Rippling последовали за ней в течение квартала. К середине 2026 года примерно каждый четвёртый работодатель явно разрешает использование ИИ на техническом собеседовании, и это число продолжает расти. Вопрос на большинстве инженерных комиссий по подбору кадров изменился с стоит ли запретить ChatGPT? на если 90% наших инженеров используют ИИ при кодировании каждый день, как выглядит честное собеседование?
Этот пост описывает политику и рубрику, которые мы рекомендуем командам, создающим это с нуля. Это не разрешение на произвольное кодирование. Это способ провести собеседование, на котором кандидат использует те же инструменты, что и в день начала работы, и при этом вы получите защищаемый сигнал.
Начните с определения того, что вы действительно измеряете
Ошибка, которую почти каждая команда делает, когда впервые разрешает ИИ — оставляет рубрику неизменённой. Они берут свою старую задачу "реализуй LRU кеш", дают кандидату вкладку Claude и удивляются, когда все проходят.
Если вы разрешите ИИ, вы больше не оцениваете способность кандидата создавать рабочий код. Вы оцениваете четыре вещи, которые ИИ не может сделать за них:
- Постановка задачи. Может ли он преобразовать расплывчатую бизнес-задачу в конкретную спецификацию, включая граничные случаи, которые не упомянул запрашивающий?
- Расстановка приоритетов. Может ли он решить, что строить в первую очередь, что пропустить и когда отказаться от черновика?
- Критическая оценка. Когда ИИ возвращает уверенно неправильный код, замечает ли это? Просит ли он альтернативу или отправляет ошибку в боевой код?
- Обоснование. Может ли он защитить каждую строчку, которую он отправил? "Модель это написала" — это не ответ.
Запишите это перед тем, как писать единую задачу. Рубрика определяет все остальное.
Разработка задачи, которую ИИ не может решить за один раз
Хорошая задача, разрешающая ИИ, имеет три свойства:
- Она намеренно недоопределена. Кандидат должен задавать уточняющие вопросы или явно высказывать предположения. Задача, которая включает все ограничения с самого начала, позволяет кандидату просто передать спецификацию модели и отправить её.
- "Счастливый путь" — это только половина работы. Вторая половина — это работа с ограничением, которое противоречит более раннему предположению. Настоящая инженерия — это примирение противоречий, а не реализация задач с leetcode.
- В ней есть хотя бы одна ловушка. Тонкое требование, которое при пропуске делает решение выглядящим правильным, но работающим неправильно на нетривиальном вводе. Модели её надёжно пропускают; думающие люди её ловят.
Конкретный пример. Вместо "реализуй ограничение по скорости запросов" спросите: "Добавь ограничение по скорости запросов к этой существующей точке входа API. Команда продукта хочет "разумной" защиты от злоупотреблений. Эта точка входа вызывается как из мобильного приложения, так и из внутреннего крон-задания. Вот существующий код." Теперь кандидат должен определить "разумно", заметить, что крон-задание сработает на наивном ограничении по IP, и объяснить свои компромиссы. ИИ счастливо напишет ограничение по IP. Кандидат должен решить, что оно неправильно.
Подробнее о создании задач, которые сопротивляются решениям, полученным от LLM, см. как отбирать разработчиков без LeetCode.
Как выглядит само собеседование
Живое собеседование с поддержкой ИИ по кодированию на практике длится 60 минут:
- 10 минут — постановка задачи. Интервьюер представляет задачу. Кандидат читает её, задаёт уточняющие вопросы, формулирует свои предположения. Они явно ещё не кодируют. Это наиболее информативная часть собеседования и в основном неуязвима для ИИ.
- 35 минут — разработка с доступом к ИИ. Кандидат пишет код, обращается к модели, когда хочет, и комментирует, что он делает. Интервьюер наблюдает за тем, как используется ИИ: правильно ли кандидат формулирует запросы, некритично ли принимает вывод или рассматривает его как младшего партнёра при парном программировании?
- 15 минут — защита и расширение. Интервьюер просит кандидата разобраться в функции, которую написал ИИ, изменить ограничение и объяснить, что сломается. Здесь слабые кандидаты терпят крах.
Это та же структура, что и сильное собеседование с живым кодированием, с одним явным поворотом: ИИ — это инструмент, который оценивается по правильному использованию, а не запрещённое устройство.
Рубрика оценки: пять измерений, пять баллов за каждое
Используйте одну и ту же рубрику для каждого кандидата и каждого интервьюера с закреплённым поведением на каждом уровне. Хорошая отправная точка:
| Измерение | Что оно измеряет |
|---|---|
| Постановка задачи | Качество уточняющих вопросов и сформулированных предположений до написания кода. |
| Принятие решений | Выбрал ли он правильную задачу для разработки в первую очередь? Остановился ли и пересмотрел, когда попал в тупик? |
| Владение ИИ | Правильно ли сформулированы и ограничены запросы? Отвергает ли он плохие результаты и просит альтернативы? |
| Критическая оценка | Когда ИИ ошибается, замечает ли это? Тестирует ли он случай с ловушкой? |
| Обоснование | Может ли он объяснить каждую строчку, изменить её по запросу и защитить компромиссы? |
Оцените каждое измерение 1–5 с поведенческими якорями. Якоря — это то, что отличает это от импровизации; если вы никогда не калибровали рубрику, сделайте это перед проведением собеседования. Неструктурированная оценка различными интервьюерами — это то, как самый громкий голос решает вопрос найма.
Создайте форму один раз в вашей системе оценочных карточек и переиспользуйте её. Если ваша оценочная карточка не может обеспечить оценку каждого измерения перед отправкой, найдите ту, которая может.
Вопрос интегрности: доверяй, но проверяй
Разрешение на использование ИИ не означает доверие к тому, что человек на линии — это именно тот, кого нанимают. Два конкретных риска остаются:
- Подмена личности. Кто-то другой сидит за клавиатурой или шепчет кандидату что-то за кадром.
- Заученные ответы. Кандидат использует второе устройство, на котором заранее подготовлены фразы для формулировки задачи и "уточняющие вопросы", которые он фактически не сгенерировал.
Ни один из этих рисков не имеет отношения к политике использования ИИ. Они существуют в любом удалённом собеседовании. Уровень интегрности ClarityHire создан именно для такого мира: мы не помечаем кандидатов за использование ИИ, когда ИИ разрешён. Мы проверяем, что один и тот же человек печатал всё время, что его лицо соответствует личности в файле, и что результат работы отражает то, что мы наблюдали. Сигналы биометрии отпечатков клавиш и непрерывности лица ловят подмену личности независимо от того, использовал ли кандидат Claude.
Если вы проводите собеседования с разрешением на ИИ, ваш отчёт об интегрости должен ничего не говорить об использовании ИИ и всё о том, кто делал работу.
Что делать дальше
Если вы переводите существующий процесс собеседования на разрешение ИИ, работайте в таком порядке:
- Переработайте одну задачу так, чтобы она была недоопределена и содержала скрытое ограничение. Протестируйте её с двумя внутренними инженерами перед тем, как её увидит любой кандидат.
- Замените старую рубрику "корректность кода" на рубрику с пятью измерениями выше. Закрепите каждый уровень примером поведения.
- Калибруйте трёх интервьюеров на записанной сессии перед переходом к живым кандидатам.
- Решите на своей политику интегрости отдельно от политики ИИ. Это не один и тот же вопрос.
- После десяти циклов проверьте распределение оценок и проверьте сдвиг. Если все получают 4 балла за владение ИИ, ваши якоря слишком щедрые.
Команды, которые это делают правильно, — это не те, у которых самые строгие политики. Это те, чьи рубрики измеряют суждение, а не скорость печати.