Кто является заказчиком и как формируются задачи
Что проверяют
Умеете ли вы превращать запрос бизнеса в постановку, которую можно решить и проверить, и понимаете ли, кому служит ваша работа. Вопрос задают и о прошлом опыте, и как повод рассказать о команде. Следом обычно просят пример задачи, которую пришлось переформулировать.
Как отвечать
Сначала назовите заказчиков по своему опыту. В data и ML это чаще внутренние команды: продукт, маркетинг, риски, операционный блок, аналитики, которым нужны витрины. Внешний заказчик бывает в консалтинге и аутсорсе.
Затем покажите, как запрос становится задачей:
- бизнес-цель: «снизить отток», а не «сделать модель». Уточните, какое решение примут по результату и сколько стоит ошибка;
- ML-постановка: целевая переменная, горизонт прогноза, единица объекта, какие признаки доступны на момент предсказания, чтобы не получить утечку;
- метрики: офлайн (ROC-AUC, PR-AUC, MAPE) и бизнесовая, по которой решат, что проект удался, обычно через A/B-тест;
- бейзлайн: простое правило или логистическая регрессия, с которыми сравнивают сложную модель;
- для дата-инженера: источники, частота обновления, SLA по свежести, контракт на схему данных, владелец витрины;
- приоритизация: задачи в Jira или YouTrack, оценка эффекта против трудозатрат, регулярные демо заказчику.
Расскажите на своём примере, как исходная просьба изменилась после уточнения. Если задачи вам ставил только тимлид, скажите это прямо и опишите, какие вопросы вы задавали сами, чтобы понять цель.
Где спотыкаются
Воспринимают заказчика как источник готового ТЗ и начинают с выбора алгоритма. Модель с отличным ROC-AUC, по которой бизнес не может принять решение, никому не нужна.
Не договариваются о метрике успеха заранее. После месяца работы выясняется, что заказчик ждал другого, и проект закрывают.
Называют модные методы приоритизации вроде MoSCoW, но не могут объяснить, как на деле решали, какую из двух задач делать первой.