Всем привет, меня зовут Сергей Прощаев и в этой статье расскажу про шесть ошибок, из‑за которых кандидаты на DS/ML‑позиции получают отказ, хотя на все вопросы отвечают правильно.

Tech Lead и руководитель направления Java | Kotlin разработки в FinTech & E‑commerce, преподаю на курсах разработки и архитектуры в ОТУС.

Ситуация, которую вы наверняка узнаете. Вы прошли секцию, ответили на всё: bias‑variance, разница между precision и recall, оконная функция написана за минуту. Интервьюер кивал, вопросов без ответа не осталось. Через три дня приходит отказ с формулировкой «выбрали кандидата, более близкого к нашим задачам». Что именно было не так, вам не говорят, и подготовиться к следующему собеседованию не получается — вы же всё знали.

Я сижу на таких секциях с другой стороны стола. Сразу оговорюсь: я не дата‑сайентист. Я тот, к кому ML‑инженер приходит в сервисы, где модель живёт не в ноутбуке, а за REST‑эндпоинтом, с SLA, ретраями, откатом и дежурным, которого разбудят в три ночи. И на дебрифах последние полтора года всё чаще звучит одна и та же фраза: «Он ни разу не спросил, откуда данные».

Разберём шесть ошибок, которые прячутся за формально правильными ответами. По каждой — симптом, почему она возникает, что она ломает и как её чинить.

Что изменилось в воронке к 2026 году

Классическая воронка никуда не делась: скрининг, SQL, статистика и теория ML, финал с руководителем. Четыре‑пять этапов, и SQL спрашивают даже у дата‑сайентистов, чтобы убедиться, что человек соберёт данные без помощи аналитика.

Изменилось другое: сверху легли две новые секции — ML System Design и блок про LLM. Причём MLSD уехал вниз по грейдам, его теперь спрашивают и у джунов, просто с меньшей глубиной ожиданий. Мне как‑то попалась формулировка от рекрутеров, которая точно описывает сдвиг: раньше от джуна ждали, что он обучит модель и покажет метрику, теперь ждут, что он объяснит, зачем эта модель бизнесу и как её проверять в проде.

Перед следующей схемой одно пояснение. На Рис. 2 я собрал не идеальную воронку из гайдов по подготовке, а ту, которую вижу по факту у нас и у коллег из смежных компаний, с отметками, где кандидаты сыпятся чаще всего.

Главная мысль этой схемы: отсев сместился вправо. Раньше кандидат отваливался на теории. Теперь он проходит теорию, доходит до системного дизайна и финала — и там выясняется, что опыт заканчивается там же, где заканчивается ноутбук. Готовиться только к левой части воронки в 2026-м уже не работает.

Ошибка 1. Строить модель раньше, чем задан вопрос «а что изменилось»

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

• Почему возникает. Так учат готовиться. Вопрос воспринимается как экзамен на знание методов, и человек честно демонстрирует арсенал.

• Что ломает. Технически безупречно, а направление противоположное. Мне попадался разбор ровно такого случая от специалиста, который занимается DS‑подбором: кандидат выкатил этот план, а правильным первым ходом было спросить, менялся ли за период онбординг, канал привлечения или сам продукт. Не стоит запускать дорогой анализ, если изменение объясняется куда проще — например, строчкой в чейнджлоге продукта. На дебрифе нанимающий менеджер сказал прямо: он искал человека, который задаст очевидный вопрос до того, как начнёт считать. Отказ.

Меня эта история зацепила, потому что один в один повторяет то, что я вижу у бэкендеров. Помню, как однажды у нас неделю искали причину роста времени ответа сервиса. Причина была в том, что соседняя команда выкатила фичу и удвоила количество вызовов. Никто просто не открыл историю релизов.

Как чинить. Первые две‑три минуты любого кейса — вопросы, а не решения. Что менялось в продукте, в трафике, в разметке, в самом способе считать метрику. Для меня это самый быстрый сигнал: если человек начинает с проверки входных предположений, дальше разговор идёт совсем иначе, чем с тем, кто сразу побежал за инструментом.

Ошибка 2. Утечка данных и валидация без учёта времени

• Симптом. Кандидат показывает пайплайн: собрал признаки, отнормировал, разбил на train и test, получил метрику. Метрика высокая.

• Почему возникает. Учебные датасеты почти всегда без временной структуры. Привычка train_test_split переносится на задачи, где время критично: отток, фрод, спрос, скоринг.

• Что ломает. Модель показывает 0.93 на валидации и разваливается в проде через две недели. В финтехе это не абстракция: скоринг, обученный с подсматриванием в будущее, начинает пропускать реальный фрод, и узнаёте вы об этом из отчёта по потерям, а не из мониторинга.

Сам я пишу на Kotlin, но эти две строчки различаю с полувзгляда — видел, чем такая ошибка заканчивается через месяц после выкатки (язык: Python):

# Как делает кандидат: утечка + случайный сплит на временных данных
from sklearn.model_selection import train_test_split
from sklearn.preprocessing import StandardScaler

scaler = StandardScaler().fit(X)               # 1) фит на всей выборке
X_scaled = scaler.transform(X)

X_tr, X_te, y_tr, y_te = train_test_split(     # 2) случайный сплит по времени
    X_scaled, y, test_size=0.2, random_state=42
)

# Как надо: разделение по времени + препроцессинг внутри пайплайна
from sklearn.model_selection import TimeSeriesSplit, cross_val_score
from sklearn.pipeline import Pipeline
from sklearn.preprocessing import StandardScaler
from sklearn.linear_model import LogisticRegression

pipe = Pipeline([
    ("scaler", StandardScaler()),
    ("clf", LogisticRegression(max_iter=1000)),
])

cv = TimeSeriesSplit(n_splits=5)
scores = cross_val_score(pipe, X, y, cv=cv, scoring="roc_auc")

Здесь важна не конкретная функция. Утечка возникает каждый раз, когда любое преобразование обучается на всей выборке: скейлер, импьютер, отбор признаков, PCA. Самый неприятный случай — target encoding, который тянет в признак сам таргет и потом красиво врёт на валидации.

И TimeSeriesSplit — не серебряная пуля, а самый простой вариант. В скоринге между обучением и применением нужен разрыв, потому что дефолт вы увидите только через несколько месяцев, и без gap модель учится на будущем. В антифроде чаще берут walk‑forward с переобучением на скользящем окне. Стратегия зависит от одной вещи: через какое время вы узнаёте правильный ответ.

Как чинить. Проговаривать вслух: здесь данные временные, поэтому валидация по времени с учётом задержки разметки, а препроцессинг только внутри пайплайна. Отдельно проверьте признаки на доступность в момент предсказания. Признак «сумма возвратов за месяц» звучит невинно ровно до вопроса, знаем ли мы её в момент подачи заявки.

Ошибка 3. Метрика вместо решения

• Симптом. «Мы получили ROC‑AUC 0.92». Вопрос «А какой порог и сколько это в деньгах?» вызывает паузу.

• Почему возникает. В обучении метрика — конечная цель. В работе она промежуточная.

• Что ломает. Без порога и цены ошибки модель нельзя внедрить. Решение, где резать, — это бизнес‑решение, и его почему‑то почти никто не готовит заранее.

Кстати, если кандидат сам говорит, что на дисбалансе один к тысяче ROC‑AUC льстит модели, и предлагает смотреть PR‑AUC или recall при фиксированной доле ложных срабатываний, — это плюс к разговору ещё до всякой таблицы.

Мой вариант, который я обычно использую на секции, — вытащить разговор на вот такую табличку. Она у меня в голове с той поры, когда мы сами выбирали порог для антифрода и три недели спорили не про модель, а про то, сколько людей посадить на ручную проверку:

Как чинить. Готовьте не метрику, а связку: метрика → порог → нагрузка на людей и системы → деньги. Я бы предпочёл кандидата с AUC 0.84 и понятной экономикой порога тому, у кого 0.92 и фраза «дальше решит бизнес».

Ошибка 4. В ML System Design начинать с архитектуры модели

• Симптом. Вопрос «спроектируйте систему рекомендаций» — и кандидат сразу рисует двухбашенную сеть.

• Почему возникает. Модель — самая интересная часть. Про неё и готовятся.

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

Перед схемой поясню: на Рис. 3 — тот порядок, который стоит держать в голове как каркас ответа. Тайминг ориентировочный, из открытых гайдов по MLSD, но полезен именно как бюджет времени.

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

Схема намеренно упрощена, это минимальный каркас ответа, а не референсная архитектура ML‑платформы. В боевом контуре сюда добавятся feature store, реестр моделей, трекинг экспериментов, CI/CD и раскатка через shadow и canary. Если кандидат называет их сам — прекрасно, но разворачивать ответ всё равно лучше от каркаса, иначе за 50 минут вы утонете в деталях и не дойдёте до отката.

Ошибка 5. Рассказывать про RAG и агентов, но не уметь их измерять

• Симптом. Кандидат уверенно описывает RAG: векторный поиск, топ‑k чанков, промпт, ответ. Вопрос «как вы поймёте, что стало лучше» — тишина или «смотрели глазами».

• Почему возникает. Материалов о том, как собрать RAG, много. О том, как его оценивать, заметно меньше, и это скучнее.

• Что ломает. Без оценки система деградирует молча, пока не придёт эскалация от пользователя. Причём корень проблемы обычно не в модели: когда агент «поглупел», виновата не слабость рассуждения, а мусор в контексте — устаревшие документы, забитая память, где нужный факт похоронен под лишним.

Здесь скажу аккуратнее, чем принято. Тезис «разный ответ на одинаковый вход — это норма» верен не всегда: при temperature=0 ответ часто воспроизводится. Но воспроизводимость ломают вещи вне вашего кода — обновление версии модели у провайдера, батчинг на его стороне, порядок документов в выдаче ретрива. Поэтому проверка «прогнали дважды, совпало» ничего не доказывает, а регресс на наборе кейсов доказывает.

Вот как выглядит объект, который я жду вместо слов «смотрели глазами». Это фрагмент регресс‑набора для справочного бота по тарифам — бот не мой, но крутится он в моём контуре, и разбудят при отказе меня (язык: YAML):

# 1 кейс = вопрос + эталонный документ + проверяемые критерии
- id: rag-014
  question: "Вернут ли комиссию за перевод, если операция отменена?"
  expected_doc_id: "tariffs-2026-07#p12"        # метрика ретрива: документ попал в top-k
  must_contain:
    - "30 дней"
    - "заявление через приложение"
  must_not_contain:
    - "наличными в отделении"                   # ловим устаревший регламент 2024 года
  judge_criteria: "ответ ссылается на пункт тарифов и не выдумывает срок"

Полсотни таких кейсов и прогон перед каждым изменением промпта. Две раздельные метрики — попал ли нужный документ в выдачу и корректен ли ответ — это минимум. Дальше идут faithfulness (ответ следует из найденных документов, а не из памяти модели), context precision и recall (сколько мусора приехало в контекст и не потеряли ли нужное) и точность цитирования. Звучит занудно ровно до первого раза, когда правка промпта чинит один сценарий и ломает три соседних.

Как чинить. На секции говорить конкретикой: размер набора, метрика ретрива отдельно от метрики ответа, судья‑модель с ручной перепроверкой части выборки, регресс перед выкаткой. Могу себе представить, как это смотрится бледно на фоне рассказа про мультиагентную архитектуру. Но именно это отличает человека, который систему эксплуатировал, от того, кто её один раз собрал.

Ошибка 6. Прийти на живую секцию с невидимым суфлёром

• Симптом. Ответы приходят с одинаковой задержкой, слишком гладкие и структурированные. А на уточняющий вопрос «почему именно так» человек плывёт.

• Почему возникает. Соблазн понятный, и аргумент логичный: на работе я всё равно пишу код с ассистентом, почему на интервью нельзя?

• Что ломает. Масштаб уже такой, что ломается сам формат найма. Fabric по выборке более 50 тысяч кандидатов зафиксировала рост доли пользователей таких инструментов с 15% в июне 2025-го до 35% к декабрю. В сводной аналитике по 19 368 интервью за июль 2025 — январь 2026 флаг срабатывал у 38,5% кандидатов, а на технических ролях — у 48%.

Оговорюсь: Fabric продаёт сервис контроля честности интервью, то есть измеряет проблему и торгует решением от неё, а выборка у неё своя. Порядок величин это не отменяет, но источник заинтересованный.

Самая показательная история случилась в январе 2026-го, и она про компанию, которая сама делает модели. Тимлид перформанс‑команды в Anthropic Тристан Хьюм рассказал, что их take‑home задание приходится переписывать с 2024 года после каждого релиза Claude: сначала модель обошла большинство кандидатов при том же лимите времени, а следующая версия сравнялась с лучшими. По этому тесту компания просто перестала отличать сильного человека от собственной модели.

Работодатели отвечают двумя способами.

1. Первый — возвращать очные встречи: по данным Computerworld со ссылкой на опрос Gartner, ещё осенью 2025-го около 72% рекрутинговых руководителей проводили интервью очно ради борьбы с подменой кандидата, среди них Google, Cisco и McKinsey.

2. Второй, на мой взгляд, более интересный: Canva перестроила технические интервью так, что использовать ИИ обязательно, а задачи подобраны так, чтобы одним промптом их не закрыть. Оценивают, как кандидат ведёт инструмент и где отказывается от его варианта.

Как чинить. Спросить правила до секции и следовать им буквально. Если ИИ разрешён — показывать, как вы его ведёте: какой контекст даёте, что перепроверяете, где не согласились. Если запрещён — не рисковать. Скрытый оверлей не оправдать привычкой к инструментам: он не про инструменты, а про обман интервьюера. Как и предполагал, итогом гонки стала не борьба детекторов, а перепроектирование интервью. Пока формат остаётся «решите алгоритм в общей IDE», процент суфлирования будет расти.

Где этот разбор не сработает

Я описал воронку продуктовой компании, где модель едет в прод. Есть места, где половина советов не применима.

• Research‑позиции. Там спросят про статьи, вывод формул и эксперименты, а не про откат модели. Разговор про сервинг может даже насторожить.

• Небольшой стартап. Иногда нужен человек, который за неделю соберёт витрину и обучит baseline. Экономика порога там ещё никого не волнует, потому что продукта ещё нет.

• Компании, где DS — это аналитика. SQL, A/B, дашборды. MLSD там не спросят вовсе, а вот про мощность теста и подглядывание в эксперимент спросят подробно.

• Если прода у вас в опыте не было. Тогда честная фраза «я это не эксплуатировал, но понимаю, где сломается» работает лучше, чем пересказ чужой архитектуры. Проверяется это одним уточняющим вопросом.

Сводная таблица

Чек‑лист перед собеседованием

• Готов один свой проект, который я проведу от постановки задачи до мониторинга, а не до метрики.

• Для каждого проекта помню, какое бизнес‑решение принималось по результату модели и в чём измерялся эффект.

• Могу за минуту нарисовать каркас MLSD из шести блоков и объяснить, что происходит при откате.

• Умею назвать три способа получить утечку данных и показать, как их поймать.

• Знаю, через какое время в моей задаче становится известен правильный ответ, и умею объяснить, как из этого следует схема валидации.

• Для LLM‑части готов рассказать не архитектуру, а процедуру оценки.

• Уточнил у рекрутера политику по использованию ИИ на секции.

Если хотите проверить себя не только по этому чек‑листу, можно пройти короткий тест по машинному обучению. Он поможет понять, какие темы уже закрыты уверенно, а что стоит повторить перед следующим собеседованием.

Что на самом деле проверяет эта группа ошибок

Все шесть — про одно: про умение думать о системе, а не о модели. Знание алгоритмов в 2026-м проверяется за десять минут и стоит недорого, в том числе потому, что его научился имитировать любой ассистент. А привычка спросить «что изменилось» до анализа, посчитать цену порога и подумать про откат — это то, чему нельзя подсказать через оверлей. Собственно, поэтому интервью туда и переехали.

Если по ходу текста вы поймали пару узнаваний, это нормально. Я сам разбирал у себя половину списка, просто на другом стеке.

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

Важно научиться видеть всю систему целиком: от подготовки данных и валидации до архитектуры, мониторинга и эксплуатации модели. Именно здесь и происходит переход от «я знаю ML» к «я умею решать реальные ML‑задачи» — и именно это сегодня всё чаще отличает сильного кандидата.

Разобрать эти навыки на практике можно на бесплатных открытых уроках:

• 7 сентября, 18:00. «Учимся готовить данные для ML‑моделей». Записаться

• 7 сентября, 20:00. «Почему 90% ML‑проектов не доходят до продакшена? Разбираем архитектуру настоящей ML‑системы». Записаться

• 9 сентября, 18:00. «Оптимизируем построение модели через Pipeline». Записаться

Весь список бесплатных уроков августа можно найти в дайджесте.