Найм инженеров для AI‑команд: что нужно проверять

Почему старые привычки интервью здесь работают хуже

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

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

Многие наймы всё ещё фокусируются на задачах, которые мало соответствуют реальной работе: заучивание синтаксиса, решение аккуратных головоломок в одиночку и быстрый первый ответ без ревью. Большинство команд с AI так не работают. Люди работают с сгенерированным кодом, ревьюят диффы, сравнивают варианты и решают, что не должно попасть в продакшен. В условиях таймера суждение важнее скорости.

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

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

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

Что меняется в команде с AI

Инженер с AI‑инструментами не работает так же, как инженер с одним редактором и поиском. Много работы смещается от ручного написания каждой строки к тому, чтобы правильно сформулировать задачу, чтобы модель могла помочь. Важны понятные промпты, но ещё важнее чёткие ограничения. Если инженер не может сказать, что код обязан делать, чего он не должен делать и где он сломается, инструмент уйдёт в сторону.

Это меняет повседневную работу. Инженеры тратят больше времени на определение входов, краевых случаев и правил приёмки до того, как просят код. Затем они проверяют то, что приходит назад. Хорошие инженеры не доверяют отшлифованному ответу только потому, что он аккуратно выглядит. Они читают его как ревьюеры, тестируют допущения и спрашивают: «Что модель пропустила?»

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

Архитектура по‑прежнему за инженером. Модели могут предлагать паттерны, но не принимают компромиссы. Человек решает, оставить ли сервис простым, разделить его, добавить кэш, или выбрать медленную, но более безопасную стратегию. То же самое с обработкой отказов. Когда API таймаутит, очередь растёт, или миграция трогает не ту таблицу, инженер должен думать дальше «счастливого пути».

Лучшие инженеры ещё и могут объяснить, почему ответ AI неверен. Это важнее, чем быстрое починение. «Выглядит нормально» — слабый ответ. «Игнорирует идемпотентность» или «Работает в демо, но падает под нагрузкой» — намного сильнее.

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

Что проверять в первую очередь

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

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

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

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

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

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

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

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

Как построить цикл интервью

Хороший цикл должен быть близок к реальной работе. Откажитесь от шарад и длинных сессий live‑coding. Дайте человеку небольшую продуктную проблему, позвольте задавать вопросы и наблюдайте, как они формируют задачу.

Практичный цикл для стартапа или маленькой команды может оставаться коротким и при этом его трудно подделать.

1. Начните с продуктного задания на 15–20 минут. Возьмите что‑то обычное: сократить число неудачных платежей, ускорить поиск или добавить аудиторские логи. Сильные кандидаты сужают объём, называют допущения и замечают риски прежде чем говорить про инструменты.
2. Затем упражнение по ревью. Покажите короткий фрагмент кода, написанного AI, с несколькими реальными недостатками: слабая обработка ошибок, непонятные имена, отсутствие тестов или тихая проблема безопасности. Вы узнаете больше из их комментариев к ревью, чем наблюдая за тем, как они печатают.
3. Попросите обсудить компромиссы после ревью. Если предлагают кэширование — спросите, что сломается первым. Если предлагают отдельный сервис — спросите, какую дополнительную работу это даст команде. Хорошие инженеры редко говорят, что есть один идеальный ответ.
4. Проведите короткий разговор про систему. Держите его практичным: трафик удваивается за ночь, очередь забивается или один из зависимостей начинает таймаутить. Слушайте спокойное суждение, а не архитектурные речи.
5. Завершите примером из прошлого опыта. Попросите пройтись по одному проекту, за который они отвечали: что менялось в процессе, где они ошибались и что бы вырезали при перепроектировании.

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

Если вы используете AI‑инструменты в работе, скажите об этом. Сообщите, можно ли пользоваться ассистентом в упражнении и что вы всё ещё ожидаете от кандидата объяснений. Это делает цикл честнее и ближе к реальной задаче.

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

Задачи интервью, которые показывают настоящее суждение

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

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

Хорошие задачи часто выглядят так:

• расплывчатая фича вроде «Добавьте AI‑резюме к тикетам поддержки»
• pull request с скрытыми проблемами в обработке ошибок, промптах, тестах или логировании
• два варианта дизайна с явными компромиссами: один быстрый и дорогой, другой дешевле, но медленнее
• рабочий процесс с ручными шагами, где кандидат решает, что автоматизировать сейчас, а что оставить человеку

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

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

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

Что обычно делают лучшие кандидаты

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

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

Этот баланс важен. AI‑инструменты экономят время, но беспечная автоматизация создаёт часы уборки позже.

Реалистичный пример найма

Представьте небольшую SaaS‑команду с двумя неделями на создание инструмента триажа поддержки. Цель простая: читать входящие тикеты, сортировать по нескольким корзинам и отправлять очевидные случаи в нужную очередь, чтобы саппорт не тратил часы на ручную сортировку.

Двум кандидатам дают одно и то же take‑home задание.

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

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

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

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

Типичные ошибки при скрининге

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

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

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

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

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

Знакомство с инструментами — ещё одна ловушка. Знание Claude Code, Cursor, Copilot или другого ассистента помогает, но инструменты меняются быстро. Хорошее мышление живёт дольше.

Несколько красных флагов повторяются:

• Принимают сгенерированный код без проверки.
• Отстаивают дизайн, но не могут объяснить, что в нём ломается.
• Говорят о инструментах больше, чем о результатах.
• Звучат уверенно при слабых доказательствах.

Лучший скрин ищет привычки ревью, понятность письма и системное суждение. Эти качества сохраняются, когда новизна инструментов проходит.

Бычная проверка перед оффером

Перед тем как делать оффер, дайте кандидату одну грязную, плохо определённую задачу и посмотрите, как он с ней справится. Эта последняя проверка часто говорит больше, чем ещё один код‑раунд.

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

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

Лучшие ответы спокойны и просты. Они могут сказать: «Я бы ещё не строил это, потому что мы не знаем, какое действие пользователя запускает флоу», или «Код работает, но скрывает случай ошибки, я бы вернул его на доработку». Такой ответ показывает суждение.

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

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

Последняя интуитивная проверка всё ещё важна: доверили бы вы этому человеку проверить чужой pull request в занятый неделю? Если ответ «пока нет», продолжайте поиск. Команды, использующие AI, двигаются быстро. Качество ревью — то, что мешает этой скорости превратиться в ущерб.

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

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

Это одно изменение обычно улучшает остальное. Описание вакансии становится понятнее, интервьюеры меньше гоняются за мелочами, а кандидаты лучше понимают, о чём работа.

Простой план достаточен. Переделайте одно описание роли так, чтобы оно просило привычки ревью, продуктовое чутьё и обоснованные технические решения вместо скорости. Замените одну головоломку на упражнение‑ревью с несовершенным кодом или AI‑pull request. Используйте один и тот же скоркард для всех кандидатов с простыми критериями: формулировка проблемы, качество ревью кода, мысль о компромиссах и коммуникация.

Это особенно важно для команд, которые уже активно применяют AI. AI помогает писать код быстрее. Он мало помогает, когда кто‑то выбирает неправильный подход, пропускает очевидные риски или одобряет код, который не проверял всерьёз.

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

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

Если нужна помощь с формулировкой роли или ужатием цикла, внешний технический лидер может помочь, не превращая найм в огромный проект. Oleg Sotnikov на oleg.is делает подобную работу как Fractional CTO и стартап‑советник, особенно для небольших команд, которые пытаются практично внедрять AI.