Для найма инженеров с ИИ нужно другое собеседование

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

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

Не считайте создание кода главным сигналом

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

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

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

Оставьте короткий этап без помощника, если сотруднику придется читать код во время аварии или работать в изолированной среде. Десяти или пятнадцати минут хватит, чтобы убедиться: кандидат прослеживает поток управления, знает базовые структуры данных и умеет рассуждать самостоятельно. Не превращайте эту проверку во все собеседование. Заученный синтаксис теряет ценность, как только открывается редактор.

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

Дайте кандидату задачу, похожую на продакшен

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

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

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

Выдайте такой набор материалов:

1. Одностраничное описание результата для пользователя и два явных ограничения задачи.
2. Карту репозитория, которая может быть неполной, но не вводит в заблуждение.
3. Команды для тестов, линтера и запуска зависимостей.
4. Записку от поддержки об одном прошлом сбое авторизации.
5. Пустую запись о решении, куда нужно внести допущения, отвергнутые варианты и проверки перед релизом.

Не оценивайте кандидата по тому, нашел ли он каждую спрятанную деталь. Смотрите, как он ищет границы, обновляет свою модель после новых фактов и сообщает о неопределенности. Кандидат, который говорит: «Я нашел три пути записи и должен проверить, нет ли других», показывает больше ответственности, чем тот, кто уверенно правит первый контроллер.

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

Зрелость решения видна до первого патча

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

Слушайте вопросы, ответы на которые меняют реализацию. Блокировка запрещает запланированные операции или только новые интерактивные запросы? Может ли администратор действовать от имени заблокированного пользователя? Должен ли существующий проект остаться доступным для чтения? Как быстро должны истечь кешированные разрешения? Какое событие должна видеть поддержка? Это инженерные вопросы, потому что каждый ответ меняет код, данные, тесты или порядок выпуска.

Слабые кандидаты часто задают много малополезных вопросов, а затем заявляют, что уточнили задачу. Подсчет вопросов поощряет представление. Оценивайте результат каждого вопроса. Нашел ли он отсутствующий инвариант, сузил ли опасное допущение, определил ли владельца решения? Если нет, это беседа, а не анализ.

До любой генерации попросите кандидата написать короткий план. Такого шаблона достаточно:

Behavior: Suspended accounts cannot create projects through any write path.
Invariants: Existing projects remain readable; admin recovery remains possible.
Boundaries to inspect: HTTP API, import worker, authorization cache, audit events.
Largest risk: A stale cached decision permits a write after suspension.
Evidence required: Path-level tests, cache invalidation test, audit event assertion.
Rollout: Migration first, guarded application change, observable rejection count.

План нужен не для видимости документации. Во время ревью сравните его с итоговыми изменениями. Сильные кандидаты исправляют план, когда репозиторий опровергает их представления. Слабые молча меняют направление и не объясняют причину. В обычной работе отсутствие такого объяснения дорого обходится инженеру, который позже разбирает изменение.

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

Хороший вкус в ревью находит убедительные ошибки

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

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

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

Документация GitHub по ревью кода, созданного ИИ, советует сначала запускать тесты и статический анализ, а затем проверять замысел, зависимости, удобство сопровождения и характерные ошибки ИИ, например выдуманные API или удаленные тесты. Порядок разумный, но я добавляю еще одно требование: до доверия автоматическим проверкам рецензент должен восстановить радиус воздействия изменения. Тесты охватывают только те пути, которые кто-то догадался в них заложить.

При оценке ревью используйте категории комментариев:

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

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

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

Системное мышление выходит за границы репозитория

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

Разберите упражнение с блокировкой. Кандидат добавляет колонку статуса и проверяет ее в эндпоинте создания проекта. Модульные тесты проходят. Через несколько минут отложенный импорт создает проект, потому что обработчик загрузил учетную запись до блокировки. Повтор создает еще один, поскольку токен идемпотентности охватывает HTTP-запрос, но не задание. Поддержка не видит причины в журнале аудита, а кеш авторизации на другом экземпляре по-прежнему разрешает запись.

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

Попросите кандидата набросать последовательность блоками и стрелками, а затем удалить все, что не влияет на решение. На чистой схеме могут остаться клиент, API, хранилище учетных записей, кеш, очередь, обработчик и приемник событий аудита. Смотрите, где кандидат ставит проверки. Если авторизация есть только на краю, внутренние вызовы могут ее обойти. Если она есть только глубоко в хранилище, пользователь получит медленные или непонятные ошибки. Часто правильный ответ сочетает ранний отказ для удобства пользователя с обязательной проверкой рядом с записью.

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

Не требуйте единственной архитектуры. Просите объяснить компромиссы. Кандидат может выбрать очистку кеша, короткий срок хранения, версионные разрешения или прямое чтение хранилища для рискованных записей. Полезный сигнал дает связь варианта с требованиями к согласованности, поведением при отказе, нагрузкой и откатом.

Стройте собеседование на проверяемых фактах

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

При обсуждении опыта спросите об одном изменении, за которое кандидат отвечал и после релиза. Пройдите по времени: что он знал в начале, какое допущение оказалось неверным, какой сигнал это показал, кто выбрал компромисс и что затем изменили? Те, кто делал работу, обычно отделяют свои решения от решений команды. Отточенные общие слова рассыпаются при вопросах о последовательности событий.

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

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

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

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

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

Уровень специалиста меняет масштаб решений

Не отказывайте начинающим кандидатам из-за отсутствия продакшен-опыта, который им негде было получить. Проверяйте, как они строят модель, замечают противоречия, внимательно читают сгенерированный код и учатся после обратной связи. Дайте им достаточно подсказок по репозиторию, чтобы поиск не зависел от знания вашего фреймворка. Самым сильным сигналом может оказаться точное объяснение того, чего человек пока не знает.

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

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

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

Не используйте один проходной ответ для всех уровней. «Нашел скрытый обработчик» может быть сильным сигналом для начинающего, ожидаемым поведением для среднего уровня и недостаточным для staff, если кандидат не спросил, почему организация постоянно создает пути обхода. Настройте планку до просмотра имен и резюме.

Сделайте работу с ИИ видимой и безопасной

Кандидатам стоит разрешить ИИ по понятным правилам собеседования. Сообщите, какие инструменты разрешены, какие данные можно вводить, какие материалы вы сохраните и записывается ли сессия. Предложите контролируемый компанией вариант тем, кто не хочет подключать личную учетную запись. Равный доступ важнее обязательного общего интерфейса.

Не оценивайте красоту промпта. Длинные промпты могут скрывать слабое мышление, а короткий запрос может сработать благодаря отлично собранному контексту. Смотрите, выбирает ли кандидат надежные исходные данные, ограничивает ли рискованные действия, читает ли команды до подтверждения и проверяет ли результат. В рекомендациях Anthropic по безопасности Claude Code пользователь отвечает за проверку предложенного кода и команд до одобрения. На собеседовании нужна та же граница: запрос разрешения не передает ответственность инструменту.

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

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

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

Проверяйте восстановление после ошибки агента

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

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

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

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

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

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

Такое упражнение проверяет и владение агентами, не награждая знание одного интерфейса. Любому агенту для программирования можно сузить контекст, поручить просмотр изменений, запуск теста и исправление плана. Конкретные команды меняются между инструментами, но схема ответственности остается. Кандидат, способный объяснить эту схему, перейдет между продуктами по мере их развития.

Нанимайте ради ответственности после генерации

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

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

Посмотрите и на среду, куда вы нанимаете. Если команда поощряет огромные изменения, пропускает контекст проектирования и считает ревью очередью на слияние, даже отличным сотрудникам будет трудно безопасно использовать агентов. Быстрая генерация повышает потребность в небольших изменениях, явных инвариантах, быстрых тестах и времени рецензентов на размышление. Рекомендации GitHub ставят автоматические проверки на первое место. Организация должна сделать их достаточно быстрыми, чтобы инженеры действительно их запускали.

Не усредняйте оценки вслепую, когда факты противоречат друг другу. Кандидат с четверкой за управление агентом и единицей за проверку не находится на уверенном среднем уровне. Такое сочетание описывает человека, способного очень быстро выпускать опасные изменения. Установите обязательный минимум для рисков конкретной роли, а затем обсудите наблюдения за каждой выбивающейся оценкой. Если два интервьюера не согласны, вернитесь к записанному поведению или проведите короткую дополнительную проверку спорного навыка. Уверенность в общем обсуждении не должна перевешивать прямые факты.

Здесь может помочь Team

Здесь может помочь Team & AI Audit AI Audit: я вместе рассматриваю работу, роли и процесс с ИИ, а затем нахожу, где небольшая команда инженеров с ИИ сможет работать, не скрывая риски. Оценочная шкала найма остается вашей, потому что внешний советник не должен решать, за какие компромиссы отвечают ваши инженеры.

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