Мок-интервью ML-инженера — практика с AI

Интервью ML-инженера находятся где-то между data science и бэкендом, и лучше всех проходят те кандидаты, которые перестают притворяться одним или другим. Нанимающие менеджеры хотят человека, который возьмёт Jupyter-ноутбук, выкатит его как сервис и заметит, когда офлайн-AUC перестаёт предсказывать онлайн-поведение. Это руководство показывает, как использовать AI мок-интервью, чтобы отрепетировать именно те ML-циклы, что приводят к офферам — не FAANG-марафон по алгоритмам, а практический разговор «можете ли вы реально выкатить модель».

Типичные раунды интервью для ML-инженеров

Цикл ML-инженера сильно различается от компании к компании. В ML-ориентированных компаниях (исследовательские лаборатории, AI-стартапы) ждите 5–6 раундов: телефонный скрининг по фундаменту, интервью по коду (Python плюс NumPy/PyTorch), раунд ML system design, раунд по обсуждению статей или соответствию исследованиям, behavioral и беседу с нанимающим менеджером. В продуктовых компаниях (большая часть рынка) цикл сжимается до 4 раундов: телефонный скрининг, интервью по коду, ML system design и кейс-стади, behavioral. Суммарное время: 5–7 часов разговоров за 1–2 дня.

Раунд с наибольшим рычагом для практики AI-мока — это ML system design. Он почти идеально ложится на формат мока: открытый вопрос («спроектируйте рекомендательную систему для коротких видео»), обмен репликами о компромиссах, оценка за структуру и глубину. Раунд кейс-стади — вторая по приоритету цель: «точность нашей churn-модели упала с 0.84 до 0.71 на прошлой неделе, что вы делаете?» — именно такое разворачивающееся расследование, которое AI-моки хорошо отрабатывают.

Главные технические темы

Feature engineering и пайплайны данных

Планка сместилась с «можете ли вы написать SQL оконную функцию» к «можете ли вы спроектировать feature store». Ждите вопросов о training-serving skew, point-in-time корректности, онлайн- против batch-фич и о том, когда материализовать против вычисления по запросу. Инструменты: Feast, Tecton, собственная DIY-разработка — знайте компромиссы. Любимый вопрос: «ваша модель хорошо предсказывает офлайн, но деградирует онлайн — разберите со мной расследование». Сильные ответы выстраивают цепочку из свежести фич, утечки меток, сдвига распределения и багов на этапе serving.

Обучение и моделирование

Большинство продуктовых ML-ролей не требует изобретать новые архитектуры. Они требуют выбрать правильный класс модели, отладить обучение и объяснить компромиссы. Будьте готовы обсуждать: gradient boosting против нейросетей для табличных данных, когда трансформеры — это перебор, регуляризацию помимо L2 (dropout, early stopping, аугментация данных), компромисс bias-variance в конкретных терминах и то, как «эта модель переобучена» реально выглядит на кривых лосса. Поднимайте дисбаланс классов, калибровку и разницу между accuracy и AUC без напоминаний — интервьюеры любят, когда вы предугадываете следующий вопрос.

Serving моделей и MLOps

Здесь ML-инженер отличается от дата-сайентиста. Будьте готовы говорить о: batch против real-time serving, бюджетах задержки (что реально значат 50 мс p99 для модели размером с XGBoost против LLM на 7B), версионировании моделей, инфраструктуре A/B-тестов для ML (а не только для кнопок), shadow deployment, стратегии отката при регрессии модели и паттернах feature flag для ML. Инструменты: BentoML, KServe, Triton, Ray Serve, vLLM. Знать один хорошо лучше, чем знать пять названий.

Оценка и метрики

Онлайн-метрики редко двигаются так же, как офлайн. Будьте готовы объяснить, почему, и что вы с этим сделаете. Темы: корреляция офлайн-онлайн, прокси-метрики, контрфактическая оценка, off-policy estimation для ранжирования, holdout-популяции и специфические ловушки в CTR-моделировании (selection bias, position bias). Частый вопрос: «команда хочет выкатить модель, которая улучшает NDCG на 2% офлайн — что вы скажете?». Ответы, ставящие под сомнение фреймворк оценки, оцениваются выше тех, что просто доверяют числу.

LLM и новый стек

Половина ML-вакансий в 2026 упоминает LLM, даже если роль не LLM-специфична. Будьте готовы: prompt engineering против fine-tuning против RAG (когда что выбирать), оценка эмбеддингов, выбор векторной БД (Qdrant против pgvector против Pinecone), экономика задержки и стоимости на масштабе, снижение галлюцинаций. Если роль LLM-специфична, добавьте: курирование обучающих данных, проектирование eval harness (своего, а не только MMLU), дистилляцию, компромиссы квантизации.

Частые сценарные вопросы

• «Спроектируйте рекомендательную систему для приложения коротких видео в стиле TikTok, 100M DAU.» (Генерация кандидатов, ранжирование, разнообразие, cold start, петли обратной связи.)
• «Precision вашей fraud-модели упал с 0.91 до 0.74 за ночь. Что вы делаете?» (Сдвиг распределения, задержка меток, изменение feature-пайплайна, adversarial drift.)
• «Постройте LLM-копилота для поддержки клиентов. Каков ваш фреймворк оценки?» (Офлайн eval-набор, онлайн-оценки людьми, регрессионный набор, тесты на галлюцинации.)
• «Команда хочет дообучить Llama для code review. Стоит ли?» (Стоимость против prompt engineering против RAG, доступность данных, оценка, дрейф со временем.)
• «У вас бинарный классификатор с точностью 99.5%. Стоит ли его выкатывать?» (Дисбаланс классов, base rate, бизнес-стоимость false positive против false negative, калибровка.)

Behavioral-фокус — что ищут нанимающие менеджеры

ML-менеджеры по найму ищут три менее очевидных сигнала. Первый — калиброванная уверенность: ML — это дисциплина, где переоценка собственных слов раскрывается данными. Сильные кандидаты спокойно говорят «я не уверен, вот как бы я это выяснил». Второй — бизнес-чутьё: ML-инженеры, способные связать прирост в 0.03 офлайн-NDCG с денежной ценностью, получают senior-офферы быстрее тех, кто умеет говорить только о математике. Третий — сотрудничество с не-ML-людьми: большая часть ML-работы проваливается из-за коммуникации с PM, data engineering или ops, а не из-за архитектуры модели. Ждите вопросов о проваленном проекте и отвечайте через кросс-функциональное трение, а не алгоритмическое.

Как использовать практику AI-мока для этой роли

Установите тип интервью «ML System Design» и честно выберите свой уровень. Senior ML-циклы ждут, что вы ведёте разговор; middle ждёт хорошей реакции на вопросы; junior ждёт чистого фундамента. Вставьте вакансию, если она есть — AI смещает вопросы в сторону стека компании (recsys-компании получают больше глубины по ранжированию, LLM-компании — больше глубины по оценке и serving).

Для практики кода используйте мок для устного разбора ML-пайплайна («как бы вы реализовали leave-one-out кросс-валидацию для прогноза временных рядов?») и сочетайте его с настоящим ноутбуком. Не используйте его как замену реальному написанию PyTorch.

Один приём, который окупается быстро: сделайте пять подряд кейс-стади, где вы триажите деградировавшую модель. Распознавание паттернов «это утечка меток, сдвиг распределения или баг пайплайна» — самый переносимый навык интервью в ML.

Частые вопросы