Как проводить интервью с инженерами LLM приложений (не ML инженерами)

Должность, которую вы на самом деле нанимаете

«Инженер LLM» или «инженер AI приложений» — это должность, которая три года назад практически не существовала, а сейчас встречается в каждой продакт-команде. Это не то же самое, что инженер машинного обучения. Навыки пересекаются примерно на 30%.

ML инженер тренирует и развёртывает модели. Инженер LLM приложений берёт готовые модели и трансформирует их в функции продукта: проектирование промптов, фреймворки оценки качества, pipeline поиска, интеграция инструментов, оптимизация latency и стоимости, корректная обработка ошибок, когда модель выходит за пределы скрипта. Самые опытные специалисты большую часть времени посвящают скучной половине работы — тестированию качества, мониторингу, защитным механизмам — а не изобретательности промптов.

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

Пять компетенций, которые стоит тестировать

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

1. Проектирование и итерация промптов. Могут ли они написать промпт, который стабильно выдаёт структурированный результат, и способны ли они итерировать, когда это не получается?
2. Мышление в контексте оценки качества. Могут ли они спроектировать систему оценки, которая поймёт регрессию, которую пропустила бы субъективная проверка?
3. Анализ сценариев отказа. Когда модель выдаёт бред, имеют ли они понимание почему и план исправления?
4. Интеграция в систему. Могут ли они интегрировать модель в настоящий продукт — retrieval, tool calls, streaming, retries, caching — без падений в production?
5. Понимание стоимости и latency. Знают ли они, во что их выбор обойдётся? Знают ли они, как 30-секундное ожидание влияет на доверие пользователя?

Когнитивные способности и общее знание software engineering по-прежнему важны. Рассматривайте их как базовые требования, а не как фокус LLM-специфичных раундов.

Четырёхэтапный интервью-цикл, который работает

Это интервью-цикл, который мы рекомендуем для должности mid-to-senior инженера LLM приложений.

Этап 1: Асинхронное практическое задание по проектированию промптов (90 минут)

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

Их задача: написать промпт (или короткий pipeline из промпта и кода), который выдаёт нужный результат для набора данных, плюс абзац заметок о том, где он всё ещё не справляется и почему.

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

Оценивайте по:

• Надёжность результата на всём наборе данных
• Качество анализа сценариев отказа (абзац более информативен, чем сам промпт)
• Использовали ли они систематическую оценку качества, или просто визуально проверили результаты

Этап 2: Проектирование систем оценки в реальном времени (45 минут)

Покажите им промпт из Этапа 1 и специально сломанную версию. Попросите их спроектировать систему оценки, которая поймёт регрессию — не просто устно, а написав код тестов в настоящем редакторе.

Это самый информативный раунд в цикле. Сильные кандидаты будут:

• Различать стили оценки exact-match, semantic similarity и rubric-graded, и выбирать правильный для задачи
• Включать чёткие позитивные примеры, граничные случаи и adversarial случаи
• Говорить о том, как набор тестов будет запускаться в CI, какой должен быть порог отказа и как они будут его обновлять со временем

Слабые кандидаты напишут три assert для happy path и считают это сделанным.

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

Этап 3: Проектирование системы — создание с использованием модели (60 минут)

Дайте им краткое описание: «Спроектируйте backend для функции, которая позволяет менеджеру продаж вставить тикеты поддержки клиента за последние 90 дней и получить однопaragraph анализ 'стоит ли нам опасаться оттока клиентов', который можно поделить с менеджером аккаунта.»

Уточняйте по следующим пунктам:

• Как бы они структурировали промпт (system, user, tool calls?)
• Как бы они обработали cost и latency (синхронно? асинхронно с webhook? streamed?)
• Как бы они это тестировали (golden examples, A/B тест против baseline, human-in-the-loop?)
• Как бы они поймали регрессию после обновления модели
• Что бы они делали, если модель галлюцинирует конкретное имя аккаунта

Главный результат — разговор, а не диаграмма. Посмотрите наше руководство по оценке system design для рекомендаций по оцениванию.

Этап 4: Разбор практической работы + структурированные поведенческие вопросы (45 минут)

Один раунд, разбитый на две части. Сначала 25 минут обсуждения работы из Этапа 1 с использованием шаблона дополнительных вопросов. Затем 20 минут структурированных поведенческих вопросов о взаимодействии с non-engineering стейкхолдерами — продакт, дизайн, поддержка — так как большинство сбоев в LLM функциях обнаруживаются людьми, которые не пишут код.

Шаблоны вопросов, которые дают реальный результат

Три шаблона вопросов, которые стоит позаимствовать для любого раунда интервьюирования LLM инженеров.

«Покажите мне промпт, который вы написали и который упал в production. Что вы изменили?» Это лучший вопрос в наборе. Сильные кандидаты приносят конкретные примеры с конкретными исправлениями. Слабые кандидаты говорят о промптировании в абстрактном смысле.

«Какую самую дешёвую модель вы бы использовали для этой функции? Почему вы её не используете?» Проверяет понимание стоимости и заставляет их артикулировать trade-off качества-стоимости, который они неявно выбрали. Ответ «я всегда использую самую большую модель» вызывает беспокойство на любом уровне опытности.

«Как вы знаете, что ваш промпт лучше, чем предыдущая версия?» Проверяет, действительно ли они проводят оценку качества или просто полагаются на интуицию. Удивительное количество кандидатов выпустили LLM функции в production, никогда не измеряя качество.

Что не работает

Несколько подходов, которые мы видели, как команды пробовали и потом отказались.

• Интервью по типу LeetCode с алгоритмами. Почти никакая LLM работа не требует решения алгоритмических задач. Сигнал, который вы получаете, некоррелирован с должностью. См. отбор разработчиков без LeetCode для более широкого аргумента.
• «Напишите chatbot с нуля за 90 минут.» Это тест на скорость, не на инженерию. Интересные решения находятся в проектировании систем оценки и обработке ошибок, а не в интеграции API вызовов.
• Вопросы-мелочи о промптах. «Что такое temperature?» проверяет словарный запас, не суждение. Проверяйте суждение напрямую.
• Математические доски для трансформеров. Полезно, если вы нанимаете исследователя моделей. Бесполезно для того, кто будет неделю писать retrieval pipeline и eval suite.

Вопрос честности для должности, использующей AI

Это вопрос, который возникает у каждой команды: если кандидату разрешено использовать Claude или ChatGPT во время практического задания, что мешает ему просто поручить модели всю работу?

Три вещи, в совокупности:

1. Разбор Этапа 4. Кандидат, который не может защитить свой собственный промпт, систему оценки или проектирование системы, не делал работу на самом деле — несмотря на то, что говорит артефакт.
2. Проектирование систем оценки на Этапе 2. Этот раунд проходит в контролируемом редакторе без chat инструментов, за 45 минут. Сложно подделать.
3. Анализ когерентности кода для Stage 1 submission. AI-сгенерированный код имеет структурные маркеры даже когда кандидат пытался скрыть это с помощью AI.

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

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

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

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