Собеседование Data Scientist и ML-аналитика: метрики, модели и кейсы

Коротко

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

• Зафиксируй единицу наблюдения и момент, в который доступен prediction.
• Проверь leakage: признак не должен содержать информацию из будущего.
• Выбирай метрику по бизнес-стоимости false positive и false negative.
• Разделяй discrimination, calibration и выбор рабочего threshold.
• После offline score обсуждай latency, drift, мониторинг и влияние на продукт.

Задача 1: как поставить ML-проблему

Промпт: “Нужно предсказать отток пользователей”. Не начинай с XGBoost. Уточни, что такое churn, на какой горизонт строится прогноз, когда формируется snapshot и какое действие предпримет команда. Пользователь, который не открывал продукт семь дней, может быть churned для ежедневного приложения и обычным для сервиса с месячным циклом.

Назови target и prediction time. Все признаки должны быть доступны на момент прогноза. Если ты берёшь количество платежей за следующие 30 дней, модель получит ответ заранее и будет выглядеть лучше только из-за утечки.

Задачи 2–4: train/test split и data leakage

Самый частый вопрос: почему нельзя случайно перемешать временные данные перед split? Потому что пользовательские события из будущего могут попасть в train, а прошлые — в test. Модель увидит структуру, которой не будет в реальном запуске. Для временного прогноза нужен time-based split, а для повторяющихся пользователей — защита от утечки одного человека между частями, если это меняет задачу.

Leakage бывает не только в явной колонке `future_revenue`. Нормализация, feature selection, imputation и target encoding, выполненные на всей таблице до split, тоже могут подсмотреть тест. На собеседовании скажи, где будет fit, а где только transform.

• Разделяй данные до вычисления статистик, которые зависят от выборки.
• Для временных данных тест должен быть позже train.
• Проверь, не повторяется ли один entity_id в разных частях.
• Сделай feature availability audit: когда поле реально появляется?
• Сравни baseline, например “предсказывать самый частый класс”.

Задача 5: ROC-AUC, precision, recall и threshold

ROC-AUC оценивает, насколько модель ранжирует положительные объекты выше отрицательных по всем порогам. Это не означает, что выбранный рабочий threshold даёт нужный precision или recall. При сильном дисбалансе полезно посмотреть PR-AUC и матрицу ошибок на пороге, который соответствует операции.

Если задача — не пропустить мошенничество, recall может быть важнее, но слишком много false positive перегрузит ручную проверку. Если задача — отправить ограниченное число предложений, precision и capacity команды могут быть главными. Не отвечай “AUC выше — модель лучше” без контекста действия.

Задача 6: calibration и выбор порога

Две модели могут иметь одинаковый ROC-AUC, но разную калибровку. Если модель говорит “0,8”, хочется, чтобы примерно 80% таких случаев действительно были positive. Для кредитного риска, рекомендаций и лимитированных операций это может быть важнее, чем небольшая разница в ранжировании.

Threshold выбирай на validation, а не на test. Построй кривую стоимости: сколько стоит false negative, false positive, ручная обработка и потерянная возможность. Если порог меняется по сегменту, это нужно обосновать данными, стабильностью и рисками, а не подгонкой под прошлый график.

Задачи 7–9: дисбаланс и baseline

При 1% positive-класса модель, которая всегда предсказывает negative, получит 99% accuracy и будет бесполезна. На собеседовании назови baseline, base rate и метрики для positive-класса. Затем обсуди sampling, class weights и порог, но не обещай, что oversampling автоматически исправит проблему.

Проверь, не изменился ли base rate между train и продом. Метрика, которая была хорошей при 1% мошенничества, может вести себя иначе при 4%. Поэтому мониторинг должен включать распределение score, долю positive, precision на размеченной выборке и задержку получения ground truth.

Задачи 10–12: offline score и продуктовый эффект

Если модель повышает AUC, это ещё не доказательство пользы. Решение может изменить нагрузку на операторов, fairness по сегментам, latency и конверсию. Для продуктового запуска нужна связка: offline качество → эксперимент или квазиэксперимент → бизнес-метрики → мониторинг после релиза.

Представь модель рекомендаций. Offline NDCG может вырасти, но клики — нет, потому что пользователи увидели менее разнообразные предложения. Для fraud-модели recall может вырасти ценой большого числа ручных проверок. На интервью покажи, что умеешь искать downstream effect.

• Определи primary outcome, а не только ML-метрику.
• Добавь guardrails: latency, complaints, cost, coverage, fairness.
• Выбери дизайн проверки влияния на продукт.
• Продумай, как быстро появится разметка для новых прогнозов.

Задачи 13–15: drift, missing values и explainability

Модель может деградировать без изменения кода: поменялся трафик, сезонность, продуктовый сценарий или источник данных. Смотри drift признаков, score distribution, base rate и качество на отложенной разметке. Missing value — не только техническая проблема: сам факт пропуска может быть сигналом поведения и его нельзя бесконтрольно заполнить средним.

Объяснимость зависит от решения. Для внутренней сортировки достаточно feature importance с осторожной интерпретацией. Для кредитного или рискованного решения нужны понятные причины, аудит и проверка сегментов. Не называй SHAP причинностью: это объяснение поведения модели при выбранном представлении данных.

Как отвечать на ML-кейс структурно

Удобный ответ занимает пять частей: постановка, данные, baseline, оценка и запуск. В постановке фиксируешь target и действие. В данных — snapshot и leakage. В baseline — простую модель. В оценке — метрики и threshold. В запуске — эксперимент, мониторинг и план отката.

Если данных не хватает, скажи, какой лог добавишь и почему. Если ground truth появляется через 90 дней, это ограничивает скорость обучения и мониторинга. Если модель влияет на человека, добавь privacy, fairness и ручной контроль. Эти вопросы часто отделяют модельного специалиста от человека, который умеет встроить модель в рабочий процесс.

Задачи по вероятности и статистике

ML-собеседование может выйти за пределы моделей. Повтори условную вероятность, Bayes, ожидание, дисперсию, доверительный интервал и разницу между correlation и causation. Важно не только назвать формулу, но и объяснить, как она влияет на решение. Например, высокий precision при редком классе может означать мало найденных случаев, а узкий интервал не гарантирует отсутствие смещения.

Подготовь короткие ответы на вопросы: почему среднее чувствительно к выбросам, когда медиана полезнее, что происходит с variance при увеличении выборки, почему multiple testing повышает риск ложного positive и чем offline evaluation отличается от A/B-эффекта.

Системный кейс: модель в продакшене

Промпт: “Поставь модель, которая определяет подозрительные транзакции”. Ответ должен включать поток данных, latency, признаки, решение, ручную очередь, обратную связь и мониторинг. Спроси, когда появляется ground truth, можно ли блокировать операцию автоматически и что произойдёт при недоступности модели.

Если у модели высокий recall, но очередь операторов выросла в пять раз, бизнес-эффект может быть отрицательным. Добавь capacity как guardrail и выбери threshold через стоимость ошибок. Для онлайн-сервиса отдельно назови fallback: правила, предыдущая версия или безопасный режим. Это показывает, что ты думаешь о системе, а не только о notebook score.

• Feature store или источник признаков и их freshness.
• Срок и качество разметки.
• Latency и fallback при сбое.
• Capacity ручной проверки.
• Мониторинг drift, score и бизнес-результата.

Fairness и экспериментальная проверка

Если модель влияет на доступ к продукту, деньги или безопасность, проверь качество по сегментам. Средний AUC может скрывать слабое recall у отдельной группы. Не ограничивайся красивым сравнением score: обсуди, какие признаки допустимы, как проверять proxy и кто утверждает риск.

После offline-проверки нужен дизайн запуска. Это может быть A/B, shadow mode, holdout или ограниченный rollout. Определи primary outcome, guardrails и длительность наблюдения. Для модели с медленной разметкой заранее укажи, какие ранние proxy допустимы, а какие решения нельзя принимать до появления фактического исхода.

Как готовиться к ML-собеседованию

Тренируй не только определения. Возьми три кейса: churn, fraud и recommendation. Для каждого за пять минут выпиши target, snapshot, leakage risks, baseline, metric, threshold и мониторинг. Затем объясни один кейс человеку без ML. Если смысл исчезает без терминов, постановка ещё не стала рабочей.

Отдельно повтори SQL и pandas: в прикладном Data Science интервью модель редко существует без подготовки данных. Умение быстро проверить выборку, соединить источники и найти leakage часто ценнее, чем перечисление десяти алгоритмов.