Вопросы технического собеседования, устойчивые к ИИ: Что работает в 2026

Проблема с "устойчивостью к ИИ"

Строго говоря, никакой вопрос собеседования не может быть полностью устойчивым к ИИ. Целеустремлённый кандидат со вторым монитором и быстрой печатью может пропустить почти любой ответ через LLM. Реалистичная цель — не невозможность, а неблагоприятная экономика: вопросы, где стоимость корректного использования ИИ выше, чем стоимость просто дать свой ответ.

Когда использование ИИ перестаёт быть короткой дорогой, оно перестаёт быть проблемой. Паттерны ниже — это те, которые мы видим в собственной библиотеке оценок и в циклах интервьюирования клиентов в 2026.

Паттерн 1: Привяжите каждый вопрос к коду, который кандидат должен сначала прочитать

Автономный вопрос — "напишите функцию, которая делает X" — есть в обучающих наборах. Вопрос, который зависит от 80 строк кода, которые кандидат никогда не видел, — нет.

Конкретная форма:

• Дайте небольшой репозиторий или файл (40–200 строк).
• Задайте вопрос, чей ответ требует понимания этого конкретного кода: "что произойдёт, если два запроса попадут в processOrder одновременно с тем же order id?"
• Затем попросите исправление.

LLM без доступа к файлу может угадать общий ответ. Кандидат, который прочитал код, может дать конкретный. Разница между ними — это сигнал.

Это та же логика, что стоит за форматом fix-the-codebase, но применённая к формулировкам вопросов, а не к формату вопросов.

Паттерн 2: Неоднозначные требования, которые наказывают спешку с кодированием

LLM обучены давать уверенные, полноценно выглядящие решения. Они плохи в том, чтобы жить с неопределённостью. Вопросы, которые вознаграждают уточняющие вопросы перед написанием кода, естественным образом отбирают против вставки ИИ.

Пример вопроса: "Мы хотим добавить функцию 'отметить как избранное' в приложение заметок. Расскажите мне, как бы вы это реализовали."

Старший инженер спрашивает: по пользователям или глобально? Синхронизация между устройствами? Порядок сохраняется? Что происходит при удалении заметки? Каждый уточняющий вопрос — это сигнал. Вставленный ответ ИИ прыгает прямо к схеме таблицы favorites и никогда не поднимает единого компромисса.

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

Паттерн 3: Дополнительные вопросы, требующие ответственности за предыдущий ответ

Самый устойчивый к ИИ ход в любом собеседовании — это живое дополнение. LLM может писать код. Он не может отвечать на вопросы о собственном коде в реальном времени, в то время как интервьюер смотрит.

Полезные паттерны дополнительных вопросов:

• "Почему вы выбрали хеш-таблицу здесь? Что изменилось бы, если бы входные данные были отсортированы?"
• "Прогуляйтесь со мной через то, что происходит, если эту функцию вызывают из двух потоков."
• "Я собираюсь изменить требования: вместо одного пользователя это миллион. Что сломается в первую очередь?"
• "Вы написали const result = x ?? 0. В чём разница между ?? и || здесь?"

Кандидаты, которые написали свой собственный код, могут импровизировать на нём. Кандидаты, которые вставили, обычно отвечают на один дополнительный вопрос, иногда на два, а затем сломаются. Три дополнительных вопроса — это почти идеальный фильтр — и тот же playbook, который работает на take-home submissions, работает и внутри live rounds.

Паттерн 4: Вопросы с новыми ограничениями, а не новыми темами

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

Конкретные модификации, которые работают:

• Пользовательская форма данных ("входные данные — это поток объектов {userId, eventType, ts}, а не массив целых чисел").
• Необычная модель стоимости ("чтение бесплатно, запись стоит 100x — проектируйте соответственно").
• Ограничение, которое переворачивает очевидное решение ("вы не можете использовать никакую структуру на основе хеша").
• Реальный аспект ("функция будет запущена в Lambda с лимитом памяти 6 МБ").

Классическая задача ("найти дубликаты") есть в обучающих данных каждой модели. Та же задача с событиями {userId, ts} и лимитом памяти — нет, по крайней мере не в форме, которую модель может вставить напрямую. Кандидат должен адаптировать, а адаптация — это навык, который вы действительно нанимаете.

Паттерн 5: Вопросы "Объясните компромисс, который вы лично сделали"

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

Паттерн:

1. Задайте вопрос о компромиссе: "Расскажите мне о времени, когда вы выбрали худшее на бумаге решение, потому что лучшее было неправильным для контекста."
2. После ответа спросите: "Какая метрика вас волновала?"
3. Затем: "Какой был самый сильный аргумент против вашего выбора?"
4. Затем: "Что бы вы сделали иначе сейчас?"

В сочетании с структурированной бихевиоральной рубрикой, эти вопросы почти невозможно подделать с разрешением, с которым работают реальные собеседования. Кандидат, который действительно развёртывал систему, отвечает за 90 секунд. Кандидат, который запрашивает ChatGPT в другой вкладке, требует 30 секунд, чтобы начать, дает общий ответ и путается со вторым дополнительным вопросом.

Что не работает в 2026

Для полноты, паттерны, которые теперь в основном являются мёртвым сигналом:

• Классические LeetCode-подобные подсказки алгоритмов — вставлены в любой LLM, решены за секунды.
• "Напишите функцию, которая…" без окружающего кода — та же проблема.
• Тривиальные вопросы о языке ("в чём разница между let и var?") — решены первым токеном модели.
• "Спроектируйте Twitter" / "спроектируйте Uber" подсказки — каждый YouTube канал по подготовке к интервью охватывает эти, и любой LLM вернёт эталонную архитектуру.

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

Сочетайте проектирование с обнаружением

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

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

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

Проверьте вашу текущую базу вопросов на соответствие пяти паттернам выше. Всё, что:

1. Не имеет кода или контекста для чтения перед ответом,
2. Имеет единственное "правильное" решение из учебника,
3. Не может быть отработано три раунда дополнительных вопросов, или
4. Явно является ссылочной задачей Big Tech,

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

Команды, чьи сигналы найма держатся в 2026, — это команды, которые выполнили эту работу в 2024 и 2025. Команды, жалующиеся "кандидаты проходят наше собеседование, но не могут кодировать в первый день", в основном этого не сделали.