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

Параметры задачи изменились

К середине 2026 года важен не вопрос о том, открыт ли у кандидата ChatGPT. Важнее то, измеряет ли ваше интервью хоть что-нибудь, когда он есть под рукой. Большинство команд отреагировали, добавив детектирование — биометрия нажатия клавиш, флаги копирования, анализ согласованности кода. Детектирование помогает. Но дизайн вопроса помогает больше. Задача, которую ЛЛМ решает за восемь секунд, ничего не говорит о человеке за клавиатурой, неважно как чистенько вы флаганете копирование.

Это полевой справочник по написанию вопросов для интервью по программированию, которые всё ещё дают сигнал, когда предполагается помощь ИИ.

Что делает вопрос простым для ЛЛМ

Три свойства работают против вас:

1. Это появляется в тренировочном корпусе. LeetCode, HackerRank, Codeforces, популярные репозитории GitHub — всё это в весах модели. Если ваш вопрос имеет название в стиле Википедии (Two Sum, Word Ladder, Longest Increasing Subsequence), то ответ заучен.
2. Полная спецификация выдаётся с самого начала. Полный, однозначный промпт — это именно то, на что обучена ЛЛМ. Модель не нуждается ни в чём от кандидата.
3. Выход замкнут. Функция с одним входом, одним выходом, одним правильным ответом тривиально оценивается и тривиально генерируется.

LeetCode №1 соответствует всем трём. Как и большинство вопросов из библиотеки, которую вы унаследовали.

Принцип дизайна 1: скрыть спецификацию, выявить симптом

Вместо "реализовать функцию, которая возвращает самую длинную подстроку без повторяющихся символов", дайте кандидату падающий тест и расплывчатый отчёт об ошибке: "Покупатели видят дублирующиеся товары в корзине после выполнения этого endpoint'а. Вот один падающий вход. Исправьте это."

Теперь кандидату нужно:

• Прочитать существующий код
• Сформировать гипотезу о том, что не так
• Решить, что вообще означает "правильно"

Модель всё ещё может помочь — но только после того, как кандидат сформулирует проблему. Формулировка проблемы — вот навык, который вы на самом деле хотели измерить.

Принцип дизайна 2: выдайте кодовую базу, не промпт

Замените отдельные головоломки небольшим репозиторием. 100–300 строк, несколько файлов, один-два намеренных бага, краткий README. Спросите: "Найди баг, который вызывает 500 ошибку на POST /orders, и исправь его."

Модель, которая не видела ваш репозиторий, не будет лучше кандидата в этой задаче. Она будет предположительно и уверенно гадать — и ошибаться — потому что ответ в окружающем коде, не в промпте.

Этот формат также работает как интервью без LeetCode для команд, которые хотят измерить реальную инженерную деятельность, а не скорость решения головоломок.

Принцип дизайна 3: добавьте поворот в середине вопроса

На половине пути измените требование. "Теперь клиент хочет поддерживать частичные возвраты — расширьте своё решение." Или: "Этот endpoint теперь должен быть идемпотентным. Что изменится?"

Поворот делает три вещи:

• Заставляет кандидата продемонстрировать, что он понимает собственный код (свежая вставка из окна чата не может).
• Выявляет архитектурные инстинкты, которые однократное решение скрывает.
• Делает очевидным подсказывание модели во время интервью — кандидат либо остановится, попросит несколько минут, либо выдаст второй аккуратный вставку, которая не похожа на первую. Всё это становится сигналом в отчёте о целостности.

Принцип дизайна 4: просите суждение, не результат

Некоторые вопросы с наибольшим сигналом не требуют никакого кода:

• Упражнения по проверке кода. Дайте diff из 60 строк. Попросите кандидата оставить комментарии, как если бы он был рецензентом PR'а. ЛЛМ выдают добросовестные, общие замечания ("рассмотри добавление комментария здесь"). Старшие инженеры выдают специфичную, приоритизированную критику ("этот блокировщик удерживается во время сетевого вызова — это приведёт к deadlock'у под нагрузкой").
• Разговоры о компромиссах. "У тебя есть два варианта для этого кэша инвалидации. Какой бы ты выбрал и почему?" Кандидат должен защитить выбор. Модель не заинтересована и будет увиливать.
• Чтение незнакомого PR'а. "Разложи мне, что делает это изменение и что может пойти не так."

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

Принцип дизайна 5: необычные ограничения вместо необычных проблем

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

• "Реализовать rate limiter — но часы могут идти назад на до 30 секунд из-за сноса NTP."
• "Построить queue — но enqueue должен быть O(1) в худшем случае, не амортизированным, потому что это работает в жёсткой системе реального времени."
• "Распарсить этот файл конфигурации — но спецификация развивается. Покажи мне, как ты бы обработал обратную совместимость три версии спустя."

ЛЛМ могут решать эти задачи. Они часто упускают ограничение. Кандидат, который заметит ограничение, спросит о нём и спроектирует вокруг него — это кандидат, который вам нужен.

Чего не делать

Несколько типичных реакций, которые дают обратный эффект:

• Запрет ИИ без изменения вопроса. Вы потеряете лучших кандидатов, которые уже хорошо используют ИИ, оставите у себя мошенников, которым наплевать на ваши правила, и ничему не научитесь.
• Делать проблемы непропорционально сложными, чтобы "перещеголять" модель. Враждебная сложность отбирает людей, готовых работать под давлением, а не людей, которые могут выполнять работу. Процент успеха падает и воронка захлопывается.
• Переключиться полностью на интервью на доске / без ноутбука. Это реальный вариант, но у него есть свои компромиссы — доступность, стресс кандидата и тот факт, что ни один инженер так не кодирует на своей работе.
• Доверять "устойчивым к ИИ" меткам от поставщиков вопросов. Некоторые поставщики проверяют, что вопрос получает оценку ниже порога при передаче GPT-4 сегодня. Модель завтрашнего дня переоценится по-другому. Рассматривайте метку как отправную точку, не как гарантию.

Сопоставьте дизайн вопроса с уровнем измерения

Даже хорошо разработанный вопрос выигрывает от уровня целостности, который даёт вам вторую ось сигнала. Анализ согласованности кода ИИ от ClarityHire читает траекторию отправки, не только финальный код — итерировал ли кандидат, тестировал и рефакторил, или решение пришло одной большой согласованной вставкой? В сочетании с синхронизацией нажатий клавиш и событиями вставки/переключения вкладок вы получаете оценку уверенности, которая сочетается с описанными выше вариантами, а не заменяет их.

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

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

Выберите три вопроса, которые вы назначаете чаще всего, и оцените их по принципам выше:

1. Каждый ли вопрос скрывает какую-то часть спецификации, которую кандидат должен выявить?
2. Требует ли вопрос чтения кода, который кандидат ещё не видел?
3. Есть ли поворот или решение о компромиссе, которым готовая модель не может легко владеть?

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

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