Кандидат сдает задание за 3 минуты. Вы проверяете код - идеально. А потом узнаете, что это сделал Claude 4.5
В 2026 году это происходит каждый день. Кандидаты за 5 долларов получают готовые решения от GPT-5, Claude 4.5 или Gemini 3.0 Ultra. Ваше тестовое задание, над которым раньше разработчики корпели неделю, теперь решается за пару минут. И выглядит решение как работа senior-инженера.
Anthropic - компания, которая создает Claude - столкнулась с этим парадоксом первой. Их же собственная модель решала их же тестовые задания для разработчиков. Ирония? Да. Проблема? Колоссальная.
Факт: Внутреннее исследование Anthropic показало, что Claude 4.5 решает 87% стандартных алгоритмических задач из технических собеседований FAANG-компаний. При этом 30% кандидатов-людей используют ИИ для решения тестовых заданий.
Почему ваши тестовые задания больше ничего не показывают
Типичное задание: "Напишите функцию, которая находит пересечение двух массивов". Или "Реализуйте кэш LRU". Или "Оптимизируйте SQL-запрос".
Claude 4.5 справляется с этим за секунды. И не просто справляется - генерирует код с комментариями, тестами, обработкой edge cases. Вы смотрите на решение и думаете: "Вау, какой талантливый разработчик!". А потом он приходит на работу и не может объяснить, почему выбрал именно такой подход.
Проблема в том, что мы десятилетиями измеряли не то. Мы проверяли знание алгоритмов, синтаксиса, паттернов. Но ИИ знает все это лучше любого человека. Современные LLM прошли все наши тесты, но не приобрели интеллект. И теперь они сдают наши экзамены за кандидатов.
Как Anthropic перевернула свои собеседования
В начале 2025 года инженеры Anthropic заметили странную закономерность. Кандидаты, которые блестяще решали coding challenges, на системном дизайне проваливались. Те, кто писал идеальный код, не могли объяснить trade-offs.
Они запустили эксперимент. Дали 100 тестовых заданий Claude 4.5 (своей же модели) и 100 разработчикам. Результат шокировал: ИИ решал задачи быстрее, код был чище, покрытие тестами - полнее.
Но был один нюанс. Когда задачи усложнялись не алгоритмически, а контекстуально - ИИ начинал "галлюцинировать".
1 Принцип 1: Контекст вместо алгоритма
Вместо "реализуйте бинарный поиск" - "у нас есть legacy-система на PHP 5.6, которая обрабатывает 10 млн запросов в день. Код спагетти, документации нет. Нужно добавить поиск по логам. Как будете подходить?"
ИИ знает, как реализовать бинарный поиск. Но не понимает, что в PHP 5.6 нет типизации, что система может упасть от любого изменения, что команда из 3 человек боится трогать этот код годами.
2 Принцип 2: Ограничения, которые нельзя найти в учебнике
"Оптимизируйте этот SQL-запрос. База данных - PostgreSQL 9.6 на сервере с 2 ГБ RAM. Миграцию на новую версию нельзя - зависит legacy-софт. Индексы добавлять нельзя - диск почти полный."
Claude 4.5 предложит создать индекс, обновить PostgreSQL, увеличить RAM. Потому что в его тренировочных данных лучшие практики. Но реальный разработчик должен работать в рамках ограничений.
3 Принцип 3: Мультимодальность и неполные данные
Дайте кандидату скриншот интерфейса, голосовое сообщение от продукт-менеджера ("нужно, чтобы тут было как в том приложении, ну ты понял"), и кусок логов с ошибками. Попросите написать ТЗ для разработки фичи.
ИИ плохо работает с таким шумом. Человек - отлично. Особенно если он умеет структурировать хаос в четкое ТЗ.
Пошаговый план: как создать задание, которое не решит ИИ
Шаг 1: Возьмите реальную проблему из вашего production
Не выдумывайте. Возьмите баг, который фиксили на прошлой неделе. Или фичу, которую только планируете. Уберите специфичные названия переменных, домены. Оставьте суть.
Пример: "У нас есть микросервис на Go, который падает раз в 2-3 дня. В логах только 'connection reset by peer'. Мониторинг показывает всплеск памяти перед падением. Команда из 5 человек уже месяц не может найти причину. С чего начнете?"
Шаг 2: Добавьте бизнес-контекст
"Это платежный шлюз. Каждый час простоя - 50 тысяч долларов убытка. Руководство требует фикса 'вчера'. Одновременно нужно готовить презентацию для инвесторов. В команде один senior ушел в отпуск, два junior'а только вышли с больничного."
Важно: ИИ не понимает давления deadlines, политики компании, человеческой динамики в команде. А разработчик - должен.
Шаг 3: Спросите не 'что', а 'почему' и 'как'
Вместо "напишите код" - "объясните, какой инструмент мониторинга выберете и почему именно его". Вместо "сделайте архитектуру" - "нарисуйте диаграмму взаимодействия сервисов и обоснуйте каждый компонент".
ИИ генерирует ответы. Человек строит рассуждения. Разница видна сразу.
Шаг 4: Дайте неполные и противоречивые требования
"Продукт-менеджер говорит: 'Нужна кнопка, которая делает волшебство'. Дизайнер прислал макет, где эта кнопка перекрывает половину контента. Технический лид пишет: 'Только не трогайте базу данных, она и так падает'."
Попросите кандидата написать ответ всем трем сторонам. ИИ выдаст вежливый, но бесполезный текст. Хороший разработчик задаст уточняющие вопросы, найдет компромисс, как в методе Стэнфорда.
Типичные ошибки при создании устойчивых заданий
| Как НЕ надо делать | Почему это плохо | Как сделать правильно |
|---|---|---|
| Давать задание на 40 часов работы | Кандидат либо откажется, либо использует ИИ еще больше | Ограничить 2-4 часами. Качество, а не объем |
| Просить решить невозможную задачу | Проверяете не навыки, а стрессоустойчивость | Давать сложную, но решаемую задачу. Смотреть на подход |
| Требовать знания вашего стека | ИИ знает все стеки. Человек - нет | Разрешить использовать любой знакомый стек. Смотреть на архитектурные решения |
Что делать, если кандидат все равно использует ИИ?
Он будет использовать. И это нормально. Современная разработка - это симбиоз человека и ИИ. Вопрос в том, как он использует.
Добавьте в процесс проверки:
- Живой разбор кода с вопросами "почему здесь именно этот паттерн?"
- Просьбу изменить требование на лету и посмотреть, как кандидат адаптирует решение
- Обсуждение trade-offs: "А что если нам нужно будет масштабироваться в 100 раз?"
Хороший разработчик, даже используя ИИ как быстрого junior'а, сможет объяснить каждое решение. Тот, кто просто скопировал код - нет.
FAQ: Частые вопросы от тимлидов
А если кандидат не знает наш стек технологий?
Отлично. Посмотрите, как быстро он разберется. Дайте доступ к документации, разрешите гуглить. Современный разработчик не должен знать все. Он должен уметь учиться.
Сколько времени должно занимать задание?
Не больше 4 часов. Если нужно больше - вы проверяете не навыки, а выносливость. Лучше несколько коротких заданий разного типа.
Как оценивать такие задания?
По четким критериям:
- Качество вопросов, которые задал кандидат
- Способность работать с неполной информацией
- Умение расставлять приоритеты
- Понимание бизнес-контекста
Будущее технических собеседований
Через год-два стандартные coding challenges умрут. Их место займут:
- Парное программирование с ИИ. Вы даете задачу, кандидат использует Claude/GPT, а вы смотрите, как он взаимодействует с моделью
- Симуляции реальных рабочих ситуаций: "вас только что разбудили в 3 ночи, production падает, вот логи, что делаете?"
- Работа с legacy-кодом: "вот 1000 строк спагетти-кода на COBOL, нужно добавить фичу, не сломав ничего"
Курсы вроде Профессия Разработчик + ИИ уже учат не просто кодить, а работать в симбиозе с нейросетями. А для тестировщиков есть Профессия Инженер по автоматизации тестирования, где учат создавать автономных ИИ-агентов для QA.
Прогноз: К 2027 году 70% технических собеседований будут включать задания, которые нужно решать вместе с ИИ. Не вместо него, а с ним. И оценивать будут не знание синтаксиса, а способность ставить правильные задачи нейросетям.
Самая большая ирония? Anthropic, создавая Claude, непреднамеренно сделала лучший инструмент для фильтрации некомпетентных разработчиков. Потому что теперь, чтобы пройти собеседование, нужно быть не просто тем, кто умеет гуглить. Нужно быть тем, кто умеет думать.
И это, пожалуй, самый здоровый тренд в IT за последние 10 лет.
