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

Вы не можете запретить ИИ. Вы можете проектировать вокруг него.

К 2026 году просить кандидатов отказаться от ИИ-ассистентов на собеседовании — это спектакль. Уровень, который кандидаты преодолевают с ChatGPT в отдельной вкладке, — это уровень, на который нанимают конкуренты. Вопрос не в том, как обнаружить использование ИИ — это половина работы, и мы рассматриваем это в как обнаружить ChatGPT на собеседованиях по программированию. Другая половина — это разработка задач, которые не разваливаются, когда у кандидата есть доступ к LLM.

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

Почему стандартные задачи больше не работают

Типичная задача LeetCode имеет три свойства, которые делают её тривиальной для LLM:

1. Она находится в наборе данных для обучения. Каждая классическая задача с двумя указателями, скользящим окном и динамическим программированием была решена, объяснена и переобъяснена по всему интернету.
2. Входные данные хорошо определены. Два целочисленных массива, цель, вернуть индексы. Модель точно знает, что производить.
3. Выход является бинарным. Тесты проходят или не проходят. В ответе нет суждения, которое кандидат должен защищать.

Задача со всеми тремя свойствами — это, в 2026 году, проверка навыков ChatGPT, а не проверка навыков программирования. Каждое свойство, которое вы удаляете, делает задачу сложнее для аутсорсинга.

Принцип 1: укорените задачу в коде, который ИИ никогда не видел

Самый чистый способ исключить преимущество набора данных для обучения — это заставить кандидата работать внутри конкретной кодовой базы. LLM может написать обход графа с нуля. Но оно не может надёжно расширить репозиторий из 400 строк, где два модуля используют внутреннее соглашение, которое оно никогда не встречал.

Как это выглядит на практике:

• Исправьте ошибку. Репозиторий из 200–400 строк с неочевидной ошибкой. Симптом дан, причина нет. Кандидат должен читать, выдвигать гипотезы, тестировать и исправлять. Мы описываем формат в нашем руководстве по собеседованиям без Leetcode.
• Расширьте функцию. Работающее приложение с небольшим, чётко определённым запросом на новую функцию. Качество diff является оценкой. LLM может сгенерировать правдоподобный diff; он не может гарантировать, что diff соответствует существующим соглашениям и проходит существующие тесты с первой попытки.
• Рефакторинг с ограничением. «Этот файл содержит 600 строк и его сложно читать. Разделите его на три файла без изменения поведения. Тесты всё ещё должны проходить.» Правильный ответ — это вопрос суждения. Нет канонического решения для запоминания.

Эти форматы нейтрализуют преимущество набора данных для обучения, потому что LLM не мог видеть репозиторий. Способность кандидата ориентироваться в незнакомом коде становится сигналом.

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

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

Стандартная задача: «Дан CSV заказов, вычислить ежемесячный доход.»

Версия, более сложная для аутсорсинга: «Вот CSV заказов. Вычислите ежемесячный доход. Некоторые строки — это возвраты и представлены как отрицательные суммы. Некоторые строки — это частичные возвраты и используют другое значение status. Некоторые строки — это из снятой с производства линии продуктов, которая на самом деле не была отправлена. Решите, какие из них включить, и объясните своё рассуждение прежде чем вы напишете любой код.»

Этап рассуждения является оценкой. LLM охотно производит код, который обрабатывает канонический случай и тихо отбрасывает остальное. Реальный инженер остановится, перечислит неоднозначности и задаст уточняющий вопрос — или задокументирует предположения, которые он сделал.

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

Принцип 3: сместите акцент на разговор вокруг кода

Представление — это образец, а не ответ. LLM может произвести представление. Только кандидат может защитить его при живом опросе.

Два способа на это опереться:

• Асинхронно, затем синхронно. Сначала запустите домашнее задание или асинхронный раунд кодирования, затем запланируйте 30-минутный живой раунд, где кандидат пройдёт вас через своё представление. Попросите его расширить его, изменить ограничение или аргументировать, почему они выбрали одну структуру данных над другой. Мы развернули этот формат в вопросы для уточнения представления домашнего задания.
• Живое парное программирование с собственным кодом кандидата. В середине собеседования измените одно требование и попросите его рефакторить на глазах у вас. Кандидат, который вставил исходное решение из LLM, будет с трудом его развивать без повторного запроса.

В ClarityHire мы оснащаем живой раунд проверками согласованности кода исходного представления, поэтому интервьюер входит, зная, какие части кода кандидата выглядят как сгенерированные LLM и какие выглядят как написанные вручную. Разговор может затем целенаправленно нацеливаться на подозрительные разделы.

Принцип 4: выбирайте задачи, где помощь ИИ — это функция, а не ошибка

Если в вашем объявлении о вакансии сказано «вы будете использовать инструменты ИИ каждый день в этой роли», то разработайте задачи, которые позволяют вам наблюдать, как кандидаты на самом деле их используют. Это не то же самое, что позволить им вставить ответ.

• Открытая книга с атрибуцией. Явно укажите: «Вы можете использовать ChatGPT или любую документацию. Задокументируйте каждый запрос, который вы использовали, и часть решения, которое оно произвело.» Сильный кандидат использует модель хирургически; слабый запрашивает пять раз одну и ту же неработающую функцию. Трасса — это сигнал.
• ИИ как противник. Дайте кандидату сгенерированную ИИ функцию с ошибками в качестве начальной точки. Его работа — определить, что не так, почему, и исправить это. Это проверяет навык, который роль на самом деле требует: критическое рассмотрение выходных данных ИИ перед отправкой.
• Отладка с помощью ИИ. Дайте им незнакомый репозиторий с реальной ошибкой, разрешите использование инструментов и наблюдайте, как они определяют причину. Инженеры, которые полагаются на модель для узких вопросов («что означает эта трассировка стека?»), выглядят совсем иначе от тех, кто вставляет весь файл и надеется на лучшее.

Мы исследуем большую картину этого формата в оценивание кодирования с открытой книгой.

Принцип 5: объедините предотвращение с обнаружением — никогда не полагайтесь только на одно

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

• Биометрия клавиатуры флаги событий burst-paste, которые не соответствуют авторству человека.
• Анализ согласованности кода ловит стилистические сдвиги середина-представление.
• Живое уточнение ловит авторов, которые не могут защитить собственный код.

Каждый по отдельности слабый. Вместе они делают стоимость мошенничества выше, чем стоимость выполнения работы.

Краткий чек-лист перед тем, как вы отправите вопрос

Перед тем как вы поставите задачу кодирования перед кандидатом в 2026 году, спросите себя:

1. Может ли ChatGPT решить это только из формулировки задачи? Если да, переработайте или снизьте её вес в контуре.
2. Является ли спецификация неоднозначной так, как это вознаграждает уточняющие вопросы? Если нет, добавьте неоднозначность.
3. Должен ли кандидат защищать или эволюционировать своё решение в реальном времени? Если нет, запланируйте уточнение.
4. Вы измеряете, как они используют ИИ, или претворяетесь, что они этого не будут? Будьте честны с кандидатом в любом случае.
5. У вас есть сигнал целостности, который подтверждает, что один и тот же человек написал представление и провёл уточнение? Если нет, добавьте один.

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

Если ваш текущий раунд кодирования — это одна задача в стиле LeetCode с дропбоксом домашнего задания, вы в этот момент проверяете инженерию подсказок, а не инженерию. Выберите один из форматов выше, напишите одну задачу в нём и запустите его на трёх внутренних инженерах перед тем как вы поставите это перед кандидатом. Первая версия будет либо слишком лёгкой, либо слишком неясной; третья будет той, которая производит реальный сигнал.

Для более широкого контекста о том, где асинхронное вписывается в контур, см. асинхронное vs живое техническое собеседование. Для части обнаружения этой же проблемы начните с как обнаружить ChatGPT на собеседованиях по программированию.