Как интервьюировать инженеров на навык работы с ИИ при программировании
Навык, на который никто не проверяет
К середине 2026 года большинство инженеров используют ассистента с ИИ в какой-то части своей ежедневной работы. Вопрос, на который должно ответить ваше интервью, не "может ли этот кандидат кодить без него" — это гипотеза. Вопрос: "может ли этот кандидат разработать и запустить код быстрее и надежнее с его помощью, чем инженер, сидящий рядом".
Это другой навык, и он требует другого подхода к интервью. Take-home задача со скрытым запретом на ИИ его не измеряет. LeetCode не измеряет его. Даже большинство открытых форматов позволяют кандидату пройти, просто используя ИИ как турбированную поисковую систему. Ниже приведен практический гайд по дизайну раунда, который измеряет беглость работы с ИИ напрямую и оценивает её без поощрения театральности.
Как выглядит реальная беглость работы с ИИ
Понаблюдайте час, как сильный инженер использует ассистента. Вы увидите пять ключевых паттернов:
- Структурируют запрос вокруг ограничений, а не решений. Они говорят модели, что код должен и не должен делать, затем итерируют.
- Уверенно отвергают. Когда модель предлагает что-то с тонкой ошибкой — неправильная версия API, галлюцинированная библиотека, хрупкий паттерн — они ловят это в секунды и корректируют.
- Используют ассистента больше всего на скучных частях. Boilerplate, подготовка тестов, конвертация форматов — высокорычажные применения. Load-bearing логику они пишут сами или задают модели жесткую спецификацию.
- Проверяют перед тем, как доверять. Они запускают код, читают diff и проверяют граничные случаи. Они не коммитят просто так.
- Знают, когда остановиться. Когда модель зацикливается, они переключаются обратно на самостоятельное мышление и чтение кода.
Слабый пользователь ИИ делает наоборот: задает широкие вопросы, принимает длинные выводы без критики, позволяет модели проектировать решение и выпускает, что бы ни работало. Задача интервью — различить эти два типа.
Формат вопроса, который это выявляет
Структура вопроса важнее конкретной задачи. Выбирайте такую, с этими свойствами:
- Наивный ответ ИИ неправилен в тонком смысле. Не трюк — реальное ограничение, которое кандидат должен заметить. Распространённый вариант: попросить реализовать что-то с недавним или необычным API, где данные обучения модели устарели.
- Задача слишком большая для кандидата без ИИ, чтобы закончить, и слишком тонкая для кандидата только с ИИ, чтобы решить с одного раза. Это требует обоих инструментов и судебного решения.
- Критерии приёма ясны. Не "сделай что-то хорошее" — явные must-have, которые кандидат может проверить.
- Есть намеренная двусмысленность в спеке. Разумный инженер либо уточнит, либо сформулирует предположение. Слабый пользователь ИИ вставляет спек в модель и выпускает, что бы ни вышло.
Рабочий пример: "Создай небольшую команду, которая читает CSV заказов, вычисляет ежемесячные итоги по клиентам и выводит JSON. Две неясности, которые ты должен разрешить: часовые пояса заказов и как обрабатывать строки возвратов. 60 минут. Любой инструмент."
Проводите live, не асинхронно
Чисто асинхронная take-home не может различить два профиля. Артефакт выглядит одинаково так или иначе. Проведите это как 60–75 минутную live-кодирование с демонстрацией экрана или совместный редактор, с явным разрешением использовать ИИ.
Правила, объявленные заранее:
- Любой инструмент ИИ справедлив. Скажите нам, какие вы используете.
- Мы не будем вычитать за использование ИИ. Мы проверим, как вы его используете.
- Мы проверим, что дал вам ИИ. Будьте готовы объяснить всё, что вы оставили.
Такой фрейм переводит кандидата из защитной позиции в демонстративную. Сильные кандидаты включаются в работу. Слабые нервничают, потому что их workflow не выдерживает проверку.
На что смотреть в реальном времени
Пять конкретных сигналов во время сеанса:
- Качество запроса. Они объясняют ограничения, примеры и форму желаемого вывода? Или вставляют спек и надеются?
- Частота отвержения. Как часто они отбрасывают поколение? Сильные инженеры отвергают хотя бы несколько — иногда молча, иногда вслух. Инженеры, которые всё оставляют, не читают, что выпускают.
- Где они не трогают ИИ. Они сами пишут критическую логику? Или позволяют ассистенту владеть частью, которая определяет корректность?
- Привычки проверки. Они запускают код на реальных входных данных? Они читают diff перед принятием? Они смотрят на граничные случаи?
- Восстановление. Когда модель зацикливается, они отступают и думают или продолжают делать запросы?
Это наблюдаемо в 60-минутном окне, если смотреть на нажатия клавиш, а не только на артефакт. Совместный редактор ClarityHire записывает полный сеанс с события вставки помеченными отдельно от вводимого текста — полезно, когда вы хотите вернуться к конкретному выбору с кандидатом во время разбора.
Рубрика оценки
Пять измерений, по 1–4 каждое, оценивается перед разбором:
| Измерение | Слабо (1) | Сильно (4) |
|---|---|---|
| Запросы | Вставляет спек, задаёт широкие вопросы | Структурирует ограничения, дает примеры, итерирует |
| Критическое чтение | Принимает длинные поколения без проверки | Отвергает, редактирует и переписывает в секунды |
| Суждение о рычаге | Использует ИИ на load-bearing логике | Использует ИИ на boilerplate, владеет критическим путём |
| Проверка | Выпускает непроверенный или едва проверенный код | Запускает на реальных входах, читает diffs, проверяет края |
| Восстановление | Зацикливается с моделью, когда застрял | Переключается на чтение кода или уточняющий вопрос |
Оценивайте каждое независимо. Структурированные интервью ClarityHire блокируют эти карточки оценок, чтобы рецензенты не дрейфили после просмотра артефакта.
Разбор после сеанса
Потратьте последние 15 минут на три вопроса:
- "Покажи мне поколение, которое ты отвергнул. Почему?"
- "Пройди меня по части, которую ты написал сам, и почему ты не дал ИИ это делать."
- "Какая самая хрупкая часть того, что мы выпустили? Что бы ты исправил дальше?"
Кандидаты, которые действительно рассуждали во время сеанса, могут ответить на эти вопросы без запинки. Кандидаты, которые приняли то, что произвела модель, не могут — и разница проявляется в первые десять секунд каждого ответа. Это тот же тест авторства, который вы бы провели на take-home, применённый к live использованию ИИ.
Где это подходит в цикл
Рассматривайте этот раунд как замену стандартного live-кодирования, а не дополнение. Ваш цикл должен всё ещё включать раунд дизайна систем и поведенческий раунд; вопрос, на который отвечает этот раунд, это тот, который ранее обрабатывался закрытым live-кодированием, которое потеряло большинство своего сигнала в эпоху LLM.
Что делать дальше
Три конкретных шага перед вашим следующим AI-разрешённым раундом:
- Выберите одну роль и переработайте live-кодирование на тот, который ИИ не может решить с одного раза, но который кандидат без ИИ не может закончить.
- Обучите ваших интервьюеров оценивать workflow, а не артефакт. Артефакт теперь базовое требование. Workflow это сигнал.
- Решите, что "проверено" значит перед тем, как кандидат приходит. Блокировка рубрики заранее предотвращает ретроспективную рационализацию, которая разрушает калибровку.
Команды, которые правильно это делают в 2026, переутруждают команды, которые притворяются, что модель не в комнате. Навык реален, разница между сильными и слабыми пользователями огромна, и формат интервью для его измерения не сложнее, чем тот, который он заменяет.