Как нанять инженера ИИ без риска
Нанимайте за проверенное суждение
Демонстрация работает. Резюме впечатляет. Все уходят с интервью в восторге.
Затем кто‑то спрашивает, что произойдёт, если система выдаст один и тот же возврат дважды.
Молчание — дорогой ответ.
Найм ИИ‑инженеров сложен, потому что видимая часть работы заканчивается рано. Окно чата, отвечающее плавными абзацами, выглядит завершённым. Ничто из этого не говорит, соблюдает ли система права доступа, выдерживает ли тайм‑аут или стоит ли она дороже за билет, чем человек, которому должна помогать.
Вам не нужно выигрывать спор о головах внимания. Нужно достаточно доказательств, чтобы решить, кто будет принимать эти решения от вашего имени.
Нанимайте по суждению, стоящему за демонстрацией. Сделайте это суждение наблюдаемым до того, как сделаете предложение.
Вот процесс, который я бы использовал для инженера, внедряющего ИИ в продукт: написать ожидаемый результат, открыть один реальный кусок работы, оплатить короткую рабочую сессию и оценить то, что вы действительно увидели. Для ролей в исследованиях и инфраструктуре нужны другие упражнения. Начните с работы.
Сначала опишите работу, а потом просматривайте резюме
«Нужен ИИ‑инженер» — примерно так же полезно, как «нужен кто‑то, разбирающийся с деньгами». Бухгалтер? Финансовый директор? Человек, который говорит основателю перестать покупать домены?
Выберите проблему, которой вы хотите, чтобы кандидат занимался.
| Какую работу нужно выполнить | На что обратить внимание |
|---|---|
| Исследования или разработка модели | Эксперименты, базовые линии, выбор данных и честный отчёт о том, что не сработало |
| Инженерия ИИ‑приложений | Полезный рабочий процесс, интеграции, оценка и обработка сбоев |
| Инфраструктура ИИ | Развёртывание, ёмкость, мониторинг, контроль расходов и восстановление под нагрузкой |
| Оценка и качество | Представительные тестовые случаи, обоснованная оценка и диагностика регрессий |
| Инженерия ИИ‑продукта | Исследование пользователей, проектирование рабочего процесса, внедрение и доказательство того, что функция улучшила работу |
Один человек может покрыть несколько строк. Ожидать одинаковой глубины во всех пяти областях — это путь от описания вакансии к списку желаний с указанием зарплаты.
Сформулируйте результат первых 90 дней, прежде чем открывать интервью. Например:
Определить, уменьшает ли помощник по составлению ответов время обработки без увеличения количества ошибок в политике. Провести измеряемый пилот, создать путь человеческой проверки и дать рекомендацию о расширении, корректировке или прекращении проекта.
Это даёт кандидату возможность задать вопросы — а это и есть цель. Сильный кандидат спросит, как измеряется время обработки, кто отвечает за политику и проверял ли кто‑то, насколько хороши текущие ответы человека. Слабый кандидат просто скажет, что это звучит захватывающе.
Если никто в вашей команде не может оценить технические доказательства, привлеките внешнего специалиста для оценки — и спросите, планирует ли он потом продавать вам реализацию. Иначе кандидат окажется собственным техническим справочником, что создаёт конфликт интересов и ухудшает позицию.
Попросите их открыть капот
Знаменитый работодатель указывает, где кто‑то работал. Демонстрация показывает, что что‑то однажды сработало на ноутбуке, когда настроение было хорошим. Ни то, ни другое не говорит, что этот человек сможет взять на себя в вашей команде.
Попросите рассказать о конкретном проекте от начала до конца:
«Расскажите, что вы лично выпустили в продакшн. Что вы контролировали, что сломалось и какие изменения были внесены на основе полученных данных?»
Затем проследите одно решение через весь цикл. Какой был первый подход? Что они измеряли? Какую альтернативу отклонили и почему? Что внес коллега? Что они сделали бы иначе сейчас?
Попросите показать артефакт: очищенный трассировочный лог неудачного запуска, отчёт об оценке, проектный документ, тест, короткий обзор кода. Трассировка — это просто запись того, что система делала на пути к своему ответу: каждый вызов инструмента, каждую повторную попытку, каждое тихое подавление. Это разница между чтением эссе и наблюдением за реальной работой.
Кандидат, отказывающийся передать данные клиента бывшего работодателя, проходит тест, а не проваливает его.
Возьмите вместо этого реконструированный пример или используйте приведённое ниже совместное упражнение. «Покажите доказательства» никогда не должно превращаться в «принесите нам чужие секреты».
Для найма на более раннюю позицию объём доказательств будет меньше — и это нормально. Масштабируйте ожидаемый охват и уровень надзора в соответствии с ролью. Вы проверяете понимание и владение, а не доступ к известным брендам.
Пять вопросов, стоящих затраченного времени интервью
Это подсказки для расследования, а не викторина. Если достаточно просто запомнить ответ, вопрос ничего не даёт.
1. «Как бы вы определили, улучшился ли этот агент?»
Слушайте, как успех определяется в терминах работы: правильно решённые тикеты, черновики, которые агент действительно отправил, эскалации, которых не потребовалось. Затем спросите, какие сбои скрывает средний балл, и с чем они сравнивают новую версию.
Хороший ответ делает измерение проверяемым. Попросите на месте набросать три тестовых случая и указать, кто решает, прошёл ли каждый из них. Если модель оценивает ответы, спросите, как они проверяют оценщик. «Оценка 94%» — это не измерение, если тот же запуск во вторник дает 82%.
Руководство Anthropic по оценке агентов (guide to agent evaluations) подчёркивает различие, которое должно присутствовать в вашем интервью: запись того, что агент сделал, не равна результату. Агент, говорящий «Я выдал возврат», — это лишь предложение, а не сам возврат.
2. «Инструмент превысил тайм‑аут после отправки возврата. Что дальше?»
«Повторить» — неправильный рефлекс. Деньги могут уже быть списаны.
Слушайте, как проверяется статус транзакции перед действием, наличие ключа идемпотентности, чтобы вторая попытка «попала» на первую, и путь эскалации, когда состояние действительно неизвестно. Спросите, кто видит сбой и как работа возобновляется после него. Словарь важен меньше, чем то, может ли их дизайн дважды списать деньги за одну ошибку.
3. «Что эта система может читать, изменять и тратить?»
Запросите границы: какие записи система может читать, какие действия может выполнять, где требуется одобрение человека и что останавливает бесконечный цикл, работающий всю ночь за ваш счёт.
Затем спросите, где эти границы реализованы. Подсказка модели «будьте осторожны» — это лишь политика в виде текста, намерение присутствует, но принудительное исполнение отсутствует. Попросите их нарисовать границу и предложить тест, который пытается её пересечь.
Не забудьте про раскрытие данных: что уходит к провайдеру модели, что записывается в логи и кто может их читать. «Мы логируем всё» — это лишь предлог для будущего разговора о соответствии требованиям.
4. «Какую часть вы бы построили без LLM?»
Способный инженер может вынести ИИ из части собственного предложения. Правила допуска, арифметика и проверки прав доступа имеют скучные реализации, которые никогда не галлюцинируют. Интерпретация того, что хотел сказать раздражённый клиент, — нет.
Спросите, что модель даёт в этом конкретном рабочем процессе и какие доказательства оправдывают дополнительную поверхность отказов. Если каждый блок в диаграмме требует агента, попросите более компактную диаграмму.
5. «Расскажите о подходе, который вы отказались использовать.»
Слушайте, какое наблюдение заставило их изменить мнение. Пользователи захотели поиск, а не чат. Дороже стоящая модель сократила общие затраты на обработку. Функция не стоила выпуска, и они это признали.
Честный негативный результат важнее отшлифованной истории успеха, потому что последняя редко раскрывает правило принятия решений. Спросите, что они перестали делать и сколько времени заняло прекращение этой практики.
Оплата небольшого практического сеанса
Используйте ограниченное, оплачиваемое задание на синтетических данных. Отправьте задание и критерии оценки заранее — вы нанимаете за способность принимать решения, а не за умение уклоняться от неожиданностей. Позвольте кандидатам пользоваться теми же инструментами, что и на работе, включая ИИ, а затем попросите их объяснить и проверить полученные результаты.
Пример 90‑минутного сеанса для инженера‑приложений:
Вам достался помощник службы поддержки, который составляет черновики ответов и предлагает возвраты. Здесь двенадцать синтетических тикетов, короткий документ политики и четыре записанных запуска. Один ответ ссылается на политику, отменённую в марте. Один запрос возврата истёк по таймауту. Один тикет запрашивает информацию другого клиента. Рекомендуйте, расширять ли пилот, и покажите одно небольшое улучшение или тест.
Пятнадцать минут на уточнение цели, сорок пять — на погружение, тридцать — на объяснение рекомендации. Предоставьте подготовленную среду, чтобы упражнение не превратилось в скрытый тест npm install. Учтите потребности в доступе и обеспечьте одинаковые условия для всех кандидатов.
Вы наблюдаете, какие вопросы они задают, какие доказательства открывают и к какому риску обращаются в первую очередь. Замечают ли они, что двенадцать тикетов не позволяют установить надёжность? Могут ли они выпустить одно узкое исправление, не заявляя, что система теперь в порядке? Могут ли они сказать, что должно произойти на следующей неделе?
Кандидат, добавивший падающий тест для дублирующего возврата, может рассказать вам больше, чем тот, кто выпустил красивый чат‑интерфейс.
Используйте одинаковый набор основных вопросов и одинаковые критерии оценки для всех претендентов — это базовая структура, лежащая в основе рекомендаций по структурированным интервью Управления персонала США (structured interview guidance), и она существует, чтобы ваша панель сравнивала кандидатов, а не «вибрации». Держите упражнение близким к реальной работе. Граница между образцом работы и бесплатным консультированием тоньше, чем полагают большинство менеджеров по найму, и кандидаты видят её издалека.
Карточка оценки при найме
Скопируйте это в документ интервью. Согласуйте требуемый уровень для каждой измерения заранее, до встречи с кем‑либо, потому что планка меняется, как только вам кто‑то понравится. Каждый интервьюер оценивает независимо до обсуждения и прикрепляет конкретное наблюдение к каждой оценке.
Используйте 1 = неподдерживаемо или существенно ошибочно, 2 = работоспособно при существенном руководстве, 3 = обоснованно в рамках роли, 4 = хорошее суждение плюс продемонстрированная проверка. Применяйте N/O = не наблюдалось, когда интервью не дало доказательств. N/O — это пробел, который нужно заполнить, а не ноль, который можно просто усреднить.
| Измерение | Доказательство, получающее 3 | Оценка / наблюдаемое доказательство |
|---|---|---|
| Техническое суждение | Выбирает пропорциональный дизайн и объясняет отклонённую альтернативу | ___ / ___ |
| Продуктовое суждение | Определяет пользовательский результат, базовый уровень и причину остановки | ___ / ___ |
| Оценка | Предлагает репрезентативные случаи и проверяет результаты, а не просто бегло отвечает | ___ / ___ |
| Дисциплина производства | Обрабатывает частичный сбой, восстановление, мониторинг, стоимость и задержку | ___ / ___ |
| Безопасность | Выявляет чувствительные данные и объясняет принудительные ограничения доступа и расходов | ___ / ___ |
| Коммуникация | Чётко заявляет о неопределённости и объясняет последствия для принимающего решение | ___ / ___ |
| Ответственность | Отделяет свою работу от команды и отслеживает сбои до их разрешения | ___ / ___ |
Это вспомогательный инструмент, а не проверенный предиктор эффективности работы. Настройте его под свою роль и сравните с тем, что происходит после того, как люди присоединились — иначе вы будете калибровать судью, которого никогда не оценивали.
Для роли, где человек будет единолично отвечать за производство, я хочу надёжные доказательства во всех ключевых измерениях. Сильный суммарный балл не должен скрывать нерешённую слабость в разрешениях или восстановлении; именно эти два пункта позже обойдутся вам дорого. Для развивающегося инженера запишите, какую поддержку он получит и кто её предоставит.
Завершите обсуждение тремя предложениями: Что этот человек может взять на себя? Какую поддержку ему понадобится? Что остаётся неясным? Комиссия, не способная ответить на эти вопросы, готовится к сорокаминутному разговору об executive presence.
Предупреждающие сигналы требуют ещё одного вопроса
Будьте осторожны, когда кандидат не может отделить свой вклад от команды, представляет каждый прошлый проект как безупречный успех или отвечает на вопросы измерения прилагательными. «Высокая точность» требует знаменателя.
Другие тревожные признаки: агенты появляются в дизайне до того, как проблема понятна; операционные расходы не имеют верхнего предела; восстановление сбоя возлагается на другую команду; безопасность полностью живёт в подсказке.
Сначала задайте конкретный сценарий, прежде чем делать выводы. Незнакомый термин — не отсутствие концепции, и многие сильные инженеры знакомы с идеями под другими названиями. Отдавайте должное, когда кто‑то замечает собственную ошибку в процессе ответа. Отказ обновиться после получения противоречивых данных — дисквалифицирующий шаг; необходимость короткой паузы для размышления — нет.
Уже беспокоитесь о найме? Проведите аудит работы
Проблемный AI‑проект не доказывает, что вы наняли неправильного инженера. ТЗ могло быть невозможным, данные непригодными, или руководство обещало полную автономию в keynote, прежде чем кто‑то измерил качество.
Прежде чем заказывать переписывание, сохраните код, конфигурацию, результаты оценок и соответствующие логи под надлежащим контролем доступа. Затем определите, какие учётные записи, сервисы и API‑ключи действительно контролирует компания — это место, где команды обнаруживают, что весь конвейер работает на личном биллинговом аккаунте одного человека.
Получите независимый обзор нескольких репрезентативных рабочих потоков. Что работает? Что падает? Какие утверждения воспроизводятся? Ограничьте рискованные действия, пока исследуется неопределённое поведение, и распределите работу по категориям: оставить, отремонтировать, заменить.
Попросите короткий план восстановления с тестами приёмки, назначенными владельцами и датой решения. «Нужна новая платформа» — это предложение к рассмотрению, а не диагноз.
Дайте новому сотруднику разрешение разочаровать дорожную карту
Ничто из этого не сработает, если ваша компания наказывает суждение, которое только что отобрали за шесть недель.
Инженер, говорящий «человеческое одобрение остаётся на этом этапе» или «пилот пока не оправдывает расширения», нуждается в лидере, который услышит это перед другими людьми. Нанимайте по доказательствам, а затем зарывайте неудобные выводы — и вы построите дорогую машину, генерирующую ответы, которые вы уже хотели получить.
Итак, для следующей роли в области ИИ: сформулируйте ожидаемый результат, используйте оценочную карту и наблюдайте, как кандидат разбирается с несовершенным решением.
Вам нужен человек, который сможет объяснить, почему система готова — и который откровенно скажет в тот же день, если она ещё не готова.