Какие признаки использовали в проектах
Что проверяют
Работали ли вы с признаками руками или знаете классификацию из учебника. По первому же проекту спросят, какой признак дал наибольший прирост, как вы это поняли и как проверяли, что в данных нет утечки целевой переменной.
Как отвечать
Возьмите один-два реальных проекта и рассказывайте от задачи, а не от типов признаков:
- постановка: что предсказывали, на каком горизонте, какая метрика и какой был бейзлайн;
- группы признаков: например, для оттока это поведение за окна 7, 30 и 90 дней, динамика (отношение последнего месяца к среднему), давность последнего действия, параметры тарифа и обращения в поддержку. Для каждой группы одна фраза, почему она должна работать;
- как строили: агрегаты в SQL или Spark, лаги и скользящие окна, кодирование категорий (one-hot для малого числа значений, target encoding с расчётом по фолдам для большого), обработка пропусков. Хорошо, если всё собрано в
PipelineиColumnTransformerиз scikit-learn или в feature store, чтобы на обучении и в проде признаки считались одинаково; - отбор и проверка: permutation importance, SHAP, абляция групп признаков на валидации с разбиением по времени;
- результат: прирост метрики относительно бейзлайна и что изменилось для бизнеса.
Цифры и примеры нужны свои. Если боевых проектов не было, так и скажите и расскажите про учебный проект или соревнование на Kaggle с той же детализацией: какие признаки придумали, какие не сработали и почему. Это ценится выше выдуманной истории.
Где спотыкаются
Перечисляют «категориальные, числовые, текстовые» вместо признаков конкретного проекта. Интервьюер спрашивал про ваш опыт, а не про определения.
Не замечают утечку. Число обращений в поддержку, посчитанное за весь период, включая время после ухода клиента, делает модель гениальной на валидации и бесполезной в проде.
Называют прирост без контекста: «модель стала точнее на столько-то процентов». Без метрики, бейзлайна и схемы валидации цифра ничего не значит, а accuracy на несбалансированном оттоке вообще плохой выбор.