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

Почему классический live coding больше не работает

Раньше live coding проверял способность писать код под наблюдением и рассуждать вслух. Сегодня кандидат может незаметно вставить условие задачи в чат с LLM и получить готовое решение. Даже если интервьюер видит экран, суфлёр может отображаться на втором устройстве или в оверлее. В результате вы оцениваете не навыки разработчика, а скорость работы с подсказками. Кроме того, типовые задачи (FizzBuzz, реверс строки, обход дерева) настолько заезжены, что LLM выдаёт их без ошибок. Это создаёт ложное ощущение компетентности.

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

Разрешите ИИ официально, но измените задачи

Один из подходов — не бороться с инструментами, а легализовать их использование на интервью. Кандидату разрешают применять ИИ-агентов, но задачи формулируются так, что без понимания контекста, архитектуры и ограничений нейросеть даёт неверные или поверхностные ответы. Например, вместо «напиши функцию сортировки» можно предложить спроектировать модуль, который должен работать в условиях жёстких ограничений по памяти, сетевым задержкам и обработке ошибок. LLM может сгенерировать код, но не сможет обосновать выбор структуры данных или предсказать поведение системы под нагрузкой.

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

Какие навыки проверять вместо алгоритмов

Сместите фокус с синтаксиса и заученных паттернов на навыки, которые сложно автоматизировать:

  • Понимание архитектуры и trade-offs. Попросите сравнить два подхода к решению задачи и объяснить, почему один лучше в данном контексте. Спросите, какие ограничения есть у каждого варианта и как они повлияют на поддержку.
  • Работа с нечётными требованиями. Дайте задачу с противоречивыми условиями или неполными данными. Оцените, как кандидат выявляет пробелы и формулирует предположения.
  • Отладка и анализ кода. Предложите фрагмент кода с намеренно внесённой ошибкой (например, race condition или утечка памяти) и попросите найти проблему. LLM может подсказать типовое решение, но не всегда объяснит, почему оно применимо именно здесь.
  • Рефакторинг и оценка качества. Покажите работающий, но плохо спроектированный код и попросите улучшить его с обоснованием. Важно, чтобы кандидат аргументировал каждое изменение.
  • Коммуникация и совместная работа. Включите элемент парного программирования или обсуждения дизайна, где кандидат должен объяснить свои решения и ответить на контраргументы.

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

Практические шаги по перестройке интервью

Чтобы перейти на новый формат, начните с малого:

  • Пересмотрите банк задач. Уберите задачи, которые легко гуглятся или решаются шаблонно. Замените их на сценарии из вашего продукта, требующие анализа.
  • Сформулируйте правила использования ИИ. Чётко скажите кандидату, что можно использовать LLM, но нужно комментировать каждое действие и обосновывать выбор. Это снимает напряжение и делает процесс прозрачным.
  • Оценивайте процесс, а не только результат. Введите рубрику: понимание задачи, декомпозиция, качество вопросов, обоснованность решений, работа с обратной связью. Это снижает вес «правильного ответа».
  • Проведите пилот на нескольких кандидатах. Сравните, насколько новые задачи дифференцируют сильных и слабых разработчиков. Соберите обратную связь от интервьюеров.
  • Обучите интервьюеров. Они должны уметь задавать уточняющие вопросы и замечать, когда кандидат просто пересказывает ответ ИИ, не понимая его.

Не пытайтесь сразу заменить все этапы — начните с одного типа задач, например с отладки или дизайна.

Типичные ошибки при переходе

Даже при благих намерениях легко допустить ошибки:

  • Усложнение ради сложности. Задачи становятся настолько запутанными, что даже сильные кандидаты не успевают вникнуть. Цель — проверить мышление, а не выносливость.
  • Игнорирование контекста. Если задача оторвана от реальной работы, кандидат может показать хорошие результаты на интервью, но провалиться в проекте. Используйте сценарии, близкие к вашему стеку.
  • Отсутствие критериев оценки. Без чёткой рубрики интервьюеры субъективны. Заранее определите, что считается сильным ответом, а что — поверхностным.
  • Запрет ИИ без альтернативы. Если вы просто запрещаете инструменты, но оставляете старые задачи, кандидаты всё равно найдут способ обойти правила. Лучше легализовать и адаптировать формат.
  • Недооценка коммуникации. В погоне за технической глубиной забывают, что разработчик должен уметь объяснять свои решения. Включите в оценку ясность изложения.

Пример: компания заменила алгоритмические задачи на проектирование API для системы с жёсткими лимитами по latency. Кандидатам разрешили использовать LLM, но попросили обосновать каждый выбор. В результате слабые кандидаты генерировали код, но не могли ответить, почему выбрали именно такую структуру данных, а сильные — демонстрировали понимание компромиссов.

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