Как интервьюировать инженеров ИИ (роли LLM, RAG и инженерии подсказок)

"AI engineer" — это три разные роли в одном пальто

Прежде чем спроектировать процесс интервью, определитесь, кого из перечисленных вы на самом деле нанимаете:

1. Инженер прикладного ИИ — строит фичи продукта на основе foundation моделей. Отвечает за prompts, evals, retrieval, latency и стоимость. Работает в кодовой базе вашего приложения.
2. ML-инженер (на стороне модели) — обучает, fine-tuning'ит или distill'ит модели. Отвечает за датасеты, инфраструктуру обучения, evaluation suites. Работает в вашей обучающей инфраструктуре.
3. Инженер ИИ-инфраструктуры — управляет слоем inference, vector DB и observability. Отвечает за latency budgets, GPU utilization, deployment pipelines. Работает в вашей платформе.

Эти три роли не имеют ничего общего в повседневной работе. Интервью, спроектированное для одной, неправильно оценит две других. Остальая часть этого руководства сосредоточена на инженере прикладного ИИ, потому что это ровно то, что нужно 80% команд, нанимающих "AI engineers" в 2026 году.

Четыре сигнала, которые на самом деле предсказывают производительность на работе

После анализа десятков processes для найма инженеров прикладного ИИ, четыре сигнала последовательно отделяют инженеров, которые выпускают работающие LLM-фичи, от инженеров, которые выпускают правдоподобные демки:

1. Дисциплина итерации в промптинге. Могут ли они превратить неопределённое требование продукта в prompt, eval и измеримый цикл улучшений?
2. Рассуждение об отказных режимах. Предполагают ли они по умолчанию, что модель будет халлюцинировать, потеряет токены или выберет неправильный tool — и проектируют соответственно?
3. Проектирование eval. Могут ли они разработать evaluation, который ловит именно ту регрессию, которая их волнует, а не просто BLEU score?
4. Осведомленность о стоимости и latency. Рассуждают ли они о токенах, кешировании, выборе модели и batch shape — или тянутся за GPT-5 для каждого вызова?

Ни один из этих сигналов не проверяется вопросом типа LeetCode. Все четыре требуют разных форматов интервью.

Четырехраундовый process, который работает

Раунд 1: Асинхронный take-home (90 минут, оплачивается, если ваша культура это поддерживает)

Дайте кандидату небольшую, сломанную RAG систему и реальную жалобу пользователя. Например:

Наш бот поддержки клиентов уверенно ссылается на фичу продукта, которая не существует. Вот репо, prompt, retrieval pipeline и три примера отказов. Найдите root cause и предложите fix, который сможете защитить.

На что вы смотрите:

• Читают ли они retrieval results перед тем, как обвинить prompt?
• Определяют ли они, что embedding model вероятно неправильный для этого домена?
• Предлагают ли они eval для ловли регрессии в следующий раз?
• Различают ли они "исправить симптом" от "исправить систему"?

Take-home — единственный формат, который дает вам чистое понимание дисциплины debugging. Live coding раунды слишком короткие и имеют слишком высокое психологическое давление, чтобы увидеть, действительно ли кто-то читает данные. Дополните его live followup, чтобы AI-сгенерированные решения не ускользнули.

Раунд 2: Live сессия по инженерии подсказок (60 минут)

Спарьте кандидата с интервьюером и реальной задачей: превратить неопределённый product brief в работающий prompt с измеримыми evals за реальное время в вашем реальном tooling.

Полезные подзадачи:

• Написать первый draft prompt.
• Написать три eval cases — включая один, который должен упасть.
• Итерировать prompt до прохождения evals.
• Обсудить, что они будут измерять в production за пределами eval set.

Сигнал, на который вы смотрите: думают ли они в evals first, prompts second? Инженеры, которые выпустили LLM фичи, знают, что prompt идёт downstream от eval. Инженеры, которые только прототипировали, делают наоборот.

Комната для совместного кодирования с Monaco + Yjs работает для этого — кандидат пишет prompts и eval scaffolding в реальном времени, и интервьюер может вмешаться ровно когда это важно.

Раунд 3: System design — но в ИИ-стиле (60 минут)

Бросьте кандидата в реалистичный applied-AI design prompt:

Спроектируйте customer-facing встречу summarizer, которая принимает транскрипт на 60 минут и производит список action items. Это должно работать менее чем за 30 секунд, стоить менее $0.05 за вызов и отказываться summarize контент вне нашего product домена.

Это system design интервью с ИИ-специфичными constraints. Оценивайте это с теми же dimensions — clarification, tradeoffs, failure modes, cost — но наблюдайте за ИИ-специфичными ходами:

• Рассматривают ли они chunking и map-reduce vs single-shot?
• Рассуждают ли они о выборе модели (меньшая модель + лучший prompt vs большая модель)?
• Предлагают ли они guardrail для off-domain контента (classifier? prompt? rejection eval?)?
• Проектируют ли они observability для hallucination rate, а не просто latency?

Плохие кандидаты по умолчанию выбирают "используй GPT-5, заprompti её, верни ответ". Хорошие кандидаты тратят 10 минут на cost/latency budget перед тем, как нарисовать единый box.

Раунд 4: Behavioral на shipped AI фиче (45 минут)

Структурированный behavioral раунд привязанный к конкретной фиче, которую они выпустили. Вопросы, которые работают:

• "Расскажите о eval suite, которую вы построили. Как она менялась со временем?"
• "Расскажите мне о регрессии, которая попала в production. Как вы её нашли?"
• "Опишите время, когда вы использовали меньшую модель, когда большая была бы проще. Почему?"
• "Расскажите о фиче, где LLM был неправильным инструментом. Что вы вместо этого выпустили?"

Последний вопрос — самый high-signal в процессе. Инженеры, которые использовали LLMs только как молоток, не смогут на него ответить. Инженеры, которые выпустили реальный продукт, обычно могут рассказать вам о трёх таких случаях.

Вопросы, которые выглядят умно, но таковыми не являются

Эти вопросы постоянно всплывают в гайдах по интервьюированию AI-инженеров и в основном являются шумом:

• "Объясните, как работают трансформеры." Тривия. Каждый кандидат читал один и тот же блог-пост. Ничего не говорит о том, смогут ли они выпустить фичу.
• "В чём разница между RAG и fine-tuning?" Уже в каждом training set. Используйте вместо этого followup паттерн: "расскажите о времени, когда вы выбирали одно из них и почему."
• "Напишите трансформер с нуля." Релевантно только для роли model-side ML-инженера. Для прикладного ИИ это сигнал академического бэкграунда, не shipping способности.
• Whiteboard prompt-engineering ("напишите prompt, который делает X" без eval и без iteration). Оторвано от того, как работа на самом деле происходит. Prompt в изоляции, без eval, — это театр.

Калибровка по уровню сениорности

Один и тот же process работает на всех уровнях — что меняется, это на что вы делаете упор.

Staff applied-AI инженер должен оцениваться в основном по system design и behavioral — на этом уровне вы покупаете judgment, а не скорость реализации. Mid-level инженер должен оцениваться в основном по take-home и prompt сессии — там находится их ценность. См. senior engineer интервью loop для эквивалентного breakdown на general engineering ролях.

Integrity, но умнее

Для applied-AI ролей специфично, запрет на AI помощь во время интервью некогерентен. Работа — это хорошее использование ИИ. Интервью должно это отражать.

Вместо этого мы рекомендуем:

• Разрешите AI помощь открыто в take-home. Оценивайте использование ИИ, а не его присутствие. Кандидат, который использует Claude для изучения кодовой базы, а затем пишет вдумчивый root-cause анализ — это ровно кандидат, которого вы хотите.
• Запретите ИИ в live prompt сессии. Дело в том, чтобы смотреть на их итерацию. Используйте keystroke и screen сигналы для ловли скрытого ИИ использования.
• Требуйте live followup для каждого take-home. Это самое high-signal интервью, которое пропускает большинство команд. Спарьте LLM-coherence pass с 30-минутным live walkthrough.

Кандидат, который может защитить свой take-home 30 минут, его написал. Тот, кто не может, — нет, независимо от того, что говорят keystroke сигналы.

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

Если вы настраиваете процесс найма для прикладного ИИ-инженера с нуля:

1. Выберите одно из трёх определений ролей и напишите job description, который соответствует.
2. Постройте (или переиспользуйте) один broken-RAG take-home. Итерируйте его на внутренних инженерах сначала.
3. Настройте live prompt сессию в collaborative editor с shared eval scaffolding.
4. Обучите интервьюеров четырём сигналам выше перед тем, как они проведут единый раунд.

Команды, которые хорошо нанимают AI-инженеров в 2026 году — это не команды с самыми умными вопросами. Это команды, чьи processes отражают реальную работу — итерация, eval, debugging, shipping — и которые оценивают judgment, который занимает годы для построения.