Собеседование на ML Engineer

Проверь себя · 1/3разбор после ответа

Есть функция def profile(name, country='RU', city='Moscow'): return f'{name}:{country}:{city}'. Что вернёт вызов profile('Ann', city='Kazan')?

Что спрашивают на собесе ML Engineer

ML Engineer (MLE) — это инженер, который доводит модель до продакшена и держит её живой: разворачивает serving, строит пайплайны обучения, следит за дрейфом и латенси. Поэтому собеседование смещено не в сторону «обучи модель получше», а в сторону «как ты это всё запустишь, отмасштабируешь и не уронишь под нагрузкой». От Data Scientist роль отличается тем, что меньше про feature engineering и эксперименты, больше про инфраструктуру и инженерию; от Data Engineer — тем, что добавляется ML-специфика: serving, метрики модели, train/serve skew.

Набор тем у MLE широкий, но предсказуемый. Разберём по блокам — что именно спрашивают и какой вес у каждого.

ML-теория. Базовый минимум обязателен, даже если вы не претендуете на research-роль. Спрашивают bias-variance trade-off, регуляризацию, как работает градиентный спуск, что такое переобучение и как его ловить. Глубина меньше, чем у DS, но плавать здесь нельзя — это фундамент для всех последующих разговоров про прод. ML-теория на собесе.

Classical ML и deep learning. По классике — деревья, случайный лес, градиентный бустинг (CatBoost, XGBoost, LightGBM): чем отличаются, когда что брать, как настраивать. По DL — понимать архитектуры на уровне «как развернуть и ускорить»: эмбеддинги, трансформеры, инференс больших моделей. Реализовывать слой нейросети с нуля обычно не просят, но объяснить, как заквантовать и задистиллировать модель ради латенси — вполне. Классическая ML, Deep learning.

Алгоритмы и кодинг (LeetCode-стиль). MLE — инженерная роль, поэтому live-coding никто не отменял. Дают задачи medium-уровня: строки, хеш-таблицы, два указателя, иногда динамика. Реже — прикладная ML-задача вроде «напиши train-loop» или «посчитай метрику без библиотек». Главное — чистый код, обработка краевых случаев и проговаривание сложности по времени и памяти. Live-coding.

ML System Design — главный блок для MLE. Это секция, по которой реально отбирают. «Спроектируй рекомендательную систему», «свой serving для модели ранжирования», «как обеспечить low-latency inference под десятки тысяч запросов в секунду». Здесь нужно говорить про сбор данных, фичи, обучение, выкатку, A/B, мониторинг и фоллбэки — всё end-to-end, а не только про саму модель. Слабый system design топит даже сильных по теории кандидатов. ML system design.

MLOps: деплой, мониторинг, дрейф, фичестор. Сердце роли. Спрашивают про CI/CD моделей, версионирование через model registry, эксперимент-трекинг (MLflow, W&B), feature store (Feast, Tecton) и зачем он нужен, как ловить data drift и concept drift. Понимание train/serve skew и того, как его не допустить, — почти гарантированный вопрос. MLOps, Feature stores, Мониторинг и дрейф.

Production-инференс. Как модель отдаёт предсказания в проде: batch против online, model serving (TorchServe, Triton, BentoML, FastAPI), оптимизация латенси через квантизацию и батчинг, кэширование фичей, canary и shadow деплои. Тут же — trade-off «качество против скорости и стоимости»: GPU дорогие, и MLE должен думать про cost. Деплой моделей, Model serving.

Метрики качества модели. Нужно различать офлайн-метрики (precision, recall, ROC-AUC, RMSE) и онлайн-метрики (бизнес-KPI, конверсия, выручка), понимать, почему хорошая офлайн-модель может просесть в A/B, и как мерить деградацию в проде. Метрики модели.

Этапы собеседования

Цикл у MLE длиннее, чем у аналитика: обычно четыре-шесть этапов, потому что проверяют и инженерные, и ML-навыки.

Начинается всё со скрининга с рекрутером на 20–30 минут — обсуждают опыт, стек, ожидания по деньгам и грейду. Дальше идёт алгоритмический кодинг: live-coding на medium-задачах, где оценивают не только итог, но и ход мысли, поэтому проговаривайте подход, сложность и краевые случаи. Затем секция ML-теории: базовая ML, бустинги, метрики, переобучение — не на глубину DS, но без провалов в фундаменте. Кульминация — ML system design на 60–90 минут, главная секция для MLE, где надо спроектировать ML-сервис end-to-end и показать, что вы думаете про прод, а не только про модель. Иногда отдельно выносят production/infra-секцию про Kubernetes, GPU, CI/CD и мониторинг. Завершает цикл поведенческое интервью по STAR: конфликты, факапы в проде, как чинили инциденты и договаривались с командой.

Почему проваливают

Главная причина отказа у MLE — слабый ML system design. Кандидат знает алгоритмы и теорию, но на «спроектируй serving» сыплется: не проговаривает сбор данных, забывает про мониторинг и фоллбэки, не думает про латенси и масштаб. Дизайн-секция требует структуры — если идти в неё без скелета ответа, разговор расползается и впечатление падает.

Вторая ловушка — позиция «я Data Scientist, MLOps подучу по ходу». Production-ML это отдельная дисциплина, и её не выучить за неделю до собеса. Без Docker и Kubernetes в 2026 году заявка выглядит слабо. Без понимания feature store и train/serve skew вопрос «как избежать рассинхрона фичей между обучением и продом» застаёт врасплох. И почти все забывают про cost: предлагают самое тяжёлое решение, не задумываясь, что GPU стоят денег, а бюджет латенси конечен.

Примеры вопросов с разбором

Попробуйте ответить сами, прежде чем читать разбор.

Как задеплоить модель в прод? Обернуть модель в сервис (FastAPI, BentoML, TorchServe или Triton), упаковать в Docker-контейнер и раскатить в Kubernetes с автоскейлингом. Веса берут из model registry, выкатывают через canary или shadow, чтобы не уронить продакшен, и закрывают мониторингом латенси и качества. Хороший ответ обязательно упоминает фоллбэк на предыдущую версию.
Как мониторить модель и ловить дрейф данных? Мониторят два слоя: технический (латенси, ошибки, RPS) и качественный (метрики модели и распределения входов). Data drift ловят сравнением распределений фичей в проде с обучающими — через PSI или KS-тест; concept drift виден по падению целевой метрики при стабильных входах. На отклонения вешают алерты и триггер на переобучение.
Online vs offline метрики — в чём разница? Офлайн-метрики (precision, recall, ROC-AUC, RMSE) считают на отложенной выборке до выката — они быстрые и дешёвые, но не гарантируют бизнес-эффект. Онлайн-метрики меряют в проде на живом трафике: конверсия, выручка, удержание. Классическая ловушка — модель лучше офлайн, но проигрывает в A/B, потому что офлайн-метрика не совпадает с бизнес-целью.
Как A/B-тестировать ML-модель? Делят трафик на контроль (старая модель) и тест (новая), фиксируют целевую бизнес-метрику и считают статистическую значимость. Важно следить за латенси и стоимостью новой модели, а не только за качеством, и учитывать сетевые эффекты в рекомендациях и ранжировании. Решение о выкате принимают по онлайн-метрике, а не по офлайн-AUC.
Зачем нужен feature store? Чтобы фичи считались одинаково при обучении и в проде и переиспользовались между командами. Он решает train/serve skew (рассинхрон логики фичей), хранит исторические значения для обучения и отдаёт свежие с низкой латенси для онлайн-инференса. Примеры — Feast, Tecton, Hopsworks.
Как ловить переобучение модели уже в проде? В проде нет «честного» теста, поэтому смотрят на разрыв: модель отлично предсказывает на знакомых паттернах и проседает на свежем трафике. Сигналы — расхождение офлайн и онлайн метрик, рост ошибки на новых сегментах, дрейф входных распределений. Лечат регуляризацией, более простой моделью и регулярным переобучением на свежих данных.
Latency против качества — как выбирать? От бизнес-требований: для онлайн-ранжирования под жёсткий SLA латенси важнее лишних долей AUC, для офлайн-скоринга — наоборот. Латенси режут квантизацией, дистилляцией, батчингом и кэшем фичей. Сильный кандидат называет конкретный бюджет латенси и показывает trade-off, а не просто «возьмём модель побольше».
Batch vs online inference — когда что? Batch считает предсказания пачкой по расписанию и складывает в хранилище — дёшево и просто, годится, когда свежесть не критична (рассылки, скоринг раз в день). Online считает на лету по запросу — нужен под персонализацию и реальное время, но дороже по инфраструктуре и требует низкой латенси. Выбор — по требованию к свежести и нагрузке.
Что такое train/serve skew и как его избежать? Это рассинхрон между тем, как фичи считаются при обучении и в проде: разные источники, разная логика, разное время агрегации. Из-за него модель в проде ведёт себя не так, как на обучении, и качество тихо падает. Избегают через единый код вычисления фичей и feature store как общий источник истины.
Зачем canary и shadow деплой? Canary раскатывает новую модель на маленькую долю трафика и смотрит метрики, прежде чем катить на всех, — снижает риск массового сбоя. Shadow гоняет новую модель параллельно со старой на том же трафике, но её ответы не отдают пользователю — так проверяют латенси и предсказания без риска. Оба дают безопасную выкатку с быстрым откатом.

Подробные разборы по подтемам

Как готовиться

План на 6–8 недель, если идёте с позиции Data Scientist или бэкенда.

Неделя 1–2 — алгоритмы и базовая ML. Прокачайте medium-задачи и освежите bias-variance, бустинги, метрики, переобучение. Короткие вопросы с моментальным разбором закрепляют паттерны лучше, чем один большой пет-проект — гонять их удобно в банке примеров вопросов.
Неделя 3 — Docker и Kubernetes. Поднимите модель в контейнере и раскатите в k8s с автоскейлингом — это база, без которой дальше говорить не о чем.
Неделя 4 — MLOps-инструменты. MLflow для трекинга и model registry, feature store на Feast, простой CI/CD для выката модели.
Неделя 5 — ML system design. Разберите 5–7 кейсов end-to-end: рекомендации, ранжирование, антифрод. Тренируйте структуру ответа: данные → фичи → модель → serving → A/B → мониторинг.
Неделя 6 — мониторинг и дрейф. Настройте алерты на латенси и data drift, продумайте триггер переобучения и фоллбэк.
Неделя 7–8 — моки и поведенческое. Прогоните system design вслух с таймером и подготовьте STAR-истории про инциденты в проде.

Частые ошибки

Главная ошибка на собесе MLE — кидаться рисовать архитектуру, не уточнив требования. Сначала спросите про нагрузку, бюджет латенси, требования к свежести и масштаб данных, и только потом проектируйте — иначе решаете не ту задачу. Вторая частая ошибка — отвечать про модель, когда спрашивают про прод: интервьюер ждёт разговора про serving, выкатку и мониторинг, а не про то, как поднять AUC ещё на процент. Третья — молчать про trade-off: любое решение в ML-инженерии это компромисс между качеством, латенси и стоимостью, и сильный кандидат проговаривает его сам. И последнее — забывать про мониторинг и фоллбэки в дизайне: модель без алертов на дрейф и без отката на старую версию выглядит так, будто человек никогда не дежурил по проду.

Другие темы

FAQ

MLE или DS — что выбрать?

Data Scientist — больше про модели, эксперименты и feature engineering. ML Engineer — больше про production, serving и инфраструктуру. Если вам ближе доводить модели до прода и держать их живыми, а не только обучать, — это MLE.

Нужен ли Kubernetes для ML Engineer?

В 2026 году — практически да. Деплой моделей идёт через контейнеры и оркестрацию, и вопрос «как ты раскатишь сервис под нагрузку» почти неизбежен. Без Docker и базового Kubernetes заявка на MLE выглядит слабо.

Нужен ли deep learning на собесе MLE?

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

Что главное на собесе ML Engineer?

ML system design. Это секция, по которой отбирают сильнее всего: надо спроектировать ML-сервис end-to-end, от сбора данных до мониторинга. Слабый дизайн топит даже кандидатов с хорошей теорией и алгоритмами.

Где практиковаться?

Поднимите простую модель в Docker и Kubernetes, добавьте MLflow и feature store, прогоните A/B на синтетических данных и настройте алерты на дрейф. Параллельно решайте короткие вопросы по ML и алгоритмам с разбором, чтобы закрепить теорию.

Какие компании в РФ нанимают ML Engineer?

Яндекс, Сбер, Тинькофф, VK, Авито, Wildberries и другие — везде, где ML работает в проде под нагрузкой. Чем серьёзнее ML-продукт, тем выше спрос на инженеров, которые умеют его деплоить и поддерживать.

Открыть Карьерник в Telegram