Как интервьюировать инженеров машинного обучения: Руководство на 2026 год

Почему интервью для ML-инженеров 2023 года больше не работают

Стандартное интервью для инженеров машинного обучения в 2023 году включало вопросы о смещении-дисперсии, выводе логистической регрессии, кодировании k-means и наброске архитектуры рекомендательной системы на доске. К июню 2026 года любая модель, открытая в соседней вкладке, решает все четыре задачи менее чем за тридцать секунд. Вопросы сами по себе хорошие — но полезная информация исчезла.

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

Что изменилось за последние 24 месяца

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

• LLM сделали основы товаром. Вопросы по определениям, классические выводы алгоритмов и стандартные анализы выбора модели теперь — базовый уровень. Каждый кандидат ответит правильно, потому что модель ответит правильно. Это ничего не говорит о кандидате.
• Продакшен — это основная часть работы. Обучение модели — это примерно 10% всей работы. Остальное — конвейеры данных, детектирование дрейфа, гигиена хранилища признаков, фреймворки оценки, дежурство для задержек вывода. Процесс интервью, который не проверяет работу в продакшене, нанимает исследователей на должности инженеров.
• «Инженер ML» теперь покрывает три разные профессии. Классическое ML с табличными данными, глубокое обучение для компьютерного зрения и обработки текста, и прикладное LLM/RAG/разработка агентов. Не используйте одинаковый процесс для всех трёх. Выберите направление перед написанием критериев оценки.

Процесс интервью: четыре этапа, ~5 часов в сумме

Процесс, который дает валидный сигнал в 2026 году:

1. Прикладное ML-кодирование (живой процесс, 60 мин). Маленькая, реальная ML-задача, которую кандидат решает с интервьюером.
2. Дизайн ML-системы (живой процесс, 60 мин). Комплексный дизайн production-системы с явным обсуждением стоимости, дрейфа и оценки.
3. Отладка в продакшене (асинхронно + живое обсуждение, 90 мин). Сломанный конвейер или деградирующая модель, которую кандидат должен диагностировать.
4. Поведенческое интервью / сотрудничество (живой процесс, 45 мин). Опыт ведения проектов, конфликты, дежурства.

Если вы можете провести только два этапа, выберите #2 и #3. Они имеют наивысшую предсказательную ценность для работы инженера ML и наименьший риск утечки информации в LLM.

Этап 1: Прикладное ML-кодирование — сделайте это конкретным, а не алгоритмическим

Замените классическую задачу «реализуйте логистическую регрессию с нуля» на 45-минутную практическую задачу: вот небольшой датасет, вот целевая переменная, постройте базовый вариант, обоснуйте метрику и отправьте ноутбук, который может проверить другой инженер. Кандидат использует настоящий редактор с установленными pandas, scikit-learn и PyTorch. Его поощряют использовать документацию. Можно ли ему вставлять готовые фрагменты из LLM — это ваш выбор, но будьте четко об этом (см. наш взгляд на использование AI в раундах кодирования).

Что вы оцениваете:

• Формулировка проблемы. Спросил ли кандидат, для чего нужен этот прогноз, перед тем как начать обучение?
• Выбор метрики оценки. Почему именно эта метрика? Как выглядит матрица ошибок при выбранном пороге?
• Дисциплина итераций. Проверил ли кандидат базовый вариант перед настройкой? Не было ли утечки тестового набора?
• Качество кода. Воспроизводимо ли? Другой инженер сможет запустить этот ноутбук? Логичны ли блоки?

Кандидат, который молча запустил восемь блоков настройки модели и получил 0.94 AUC, не показал вам ничего. Кандидат, который сформулировал проблему, построил простой базовый вариант и достиг 0.78 с четким обоснованием — это более сильный кандидат на наём.

Используйте структурированную шкалу оценки, чтобы два интервьюера, оценивающие одинаковый ноутбук, сошлись на одну оценку.

Этап 2: Дизайн ML-системы — самый информативный час, который вы проведете

Выберите задачу, которая соответствует вашей реальной продакшен-системе: «спроектируйте конвейер предсказания оттока, который работает ежедневно и питает систему маркетинга на основе жизненного цикла». Или для ML-ролей: «спроектируйте RAG-систему для заявок в поддержку с бюджетом задержки 200ms p95».

Кандидат должен обсудить:

• Источники данных, требования к актуальности, эволюция схемы
• Инженерия признаков, защита от утечек, выбор хранилища признаков (или отсутствие и почему)
• Выбор модели с явными компромиссами стоимость / задержка / точность
• Фреймворк оценки: оффлайн-метрики, онлайн-метрики, разрыв между ними
• Развертывание: shadow mode, canary-развертывание, критерии отката
• Мониторинг: дрейф данных, дрейф предсказаний, дрейф бизнес-метрик, пороги оповещений
• Дежурство: что разбудит кого-то, какой runbook они будут следовать

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

Этот этап максимально приближен к реальной работе инженера. Приоритизируйте его в вашей оценке.

Этап 3: Отладка в продакшене — то, что LLM не может подделать

Отправьте кандидату take-home: вот ноутбук + небольшой датасет + артефакт модели. Метрика оценки модели на holdout-наборе выглядит отлично. Метрика модели в продакшене молча деградирует уже шесть недель. Найдите баг.

Поместите реальный сбой: признак, который раньше заполнялся в 99% случаев, теперь заполняется в 60%, а пропущенные значения молча заполняются средним значением столбца (и среднее неправильное). Или данные тренировки пролили метку через почти дублированный признак. Или встраивающая модель, которую использует команда, была заменена на новую версию, и индекс не был перестроен.

Кандидат отправляет письменный диагноз и предложенное исправление, затем защищает его в 30-минутном обсуждении. Это раунд, где вы узнаете, действительно ли они когда-то владели production-системой. Это также раунд, где помощь LLM наименее полезна — баг не в коде, а в данных и истории развертывания. Кандидат должен рассуждать о системе, а не повторять определение.

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

Этап 4: Поведенческое интервью — выбирайте истории о сотрудничестве и инцидентах

Пропустите «расскажите о времени, когда вы вели проект». Спросите:

• «Расскажите о последнем production-инциденте, который вы курировали. Что сломалось, что вы отправили, что вы изменили в процессе потом?»
• «Расскажите о времени, когда вы решили НЕ использовать машинное обучение для задачи. Что вы отправили вместо этого?»
• «Когда в последний раз вы убили модель в продакшене? Почему?»

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

Поддержание честности: где индикаторы честности важны больше всего

Раунд по основам исчез, потому что LLM его освоили; это оставляет этапы 1 и 3 как раунды, где помощь AI материально искажает сигнал. Два вещи:

• Запустите биометрию клавиатуры и анализ когерентности кода на раунде прикладного кодирования. События burst-paste, смещение авторства внутри ноутбука и несоответствия беглости комментарий-код — все это появляется в отчете о честности.
• Используйте обсуждение production-отладки как реальную проверку. Кандидат, который вставил свой диагноз из LLM, не сможет его защитить, когда вы спросите «какой следующий эксперимент вы бы запустили?». Обсуждение более надежнее, чем любой классификатор.

Цель не запретить помощь AI — инженеры используют её на работе. Цель подтвердить, что человек, которого вы нанимаете, может выполнить работу.

Что пропустить

• «Закодируйте линейную регрессию с нуля.» Любой может это вставить. Это ничего не говорит.
• «В чем разница между регуляризацией L1 и L2?» То же самое.
• Алгоритмические головоломки в стиле LeetCode. ML-инженерам иногда нужны структуры данных, но ежедневная гимнастика LeetCode не предсказывает ML-инженерию. Если вам нужен раунд кодирования, используйте маленькую задачу манипуляции данными с pandas.
• 2-часовые take-home без обсуждения. Обсуждение — это то, что делает take-home работающим.

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

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

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