Какова архитектура и состав команды

Что проверяют

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

Как отвечать

Рассказывайте про реальный проект, двигаясь по пути данных, а не перечисляя модные слова:

• источники и сбор: базы сервисов, события, внешние API; как забираете: пакетно по расписанию (Airflow, Dagster) или потоком через Kafka;
• хранение: хранилище для аналитики (ClickHouse, Greenplum, озеро на S3 с Parquet или Iceberg), где лежат сырые данные и где витрины;
• обработка и признаки: Spark, dbt, SQL; есть ли feature store или признаки считаются в каждом пайплайне заново;
• модели: где обучаются, как версионируются (MLflow, DVC), как выкатываются: пакетный скоринг раз в сутки или онлайн-сервис с ограничением по задержке;
• мониторинг: качество данных, дрейф признаков, бизнес-метрика модели.

Затем команда: сколько человек и какие роли (дата-инженеры, аналитики, ML-инженеры, продакт, MLOps), кому вы сдаёте результат и от кого зависите. Закончите своей зоной: что вы строили сами, какие решения принимали и какую цифру это сдвинуло. Цифры берите свои: объём данных в сутки, время пайплайна, число моделей в продакшене.

Если вопрос задаёте вы, уточните, кто владеет данными и пайплайнами, есть ли выделенный MLOps или модель в прод выкатывает её автор, и сколько моделей реально работает, а сколько лежит в ноутбуках.

Где спотыкаются

Рисуют учебную схему «сбор, хранение, модель, деплой» без единой детали своего проекта. Интервьюер слышит пересказ статьи и начинает копать, пока не найдёт границу знаний.

Не могут объяснить, почему выбран конкретный инструмент. «Так было до меня» звучит честно, но лучше добавить, какие ограничения этот выбор накладывает.

Смешивают «мы» и «я». По рассказу должно быть понятно, какой кусок схемы ваш, а какой вы видели со стороны.