Почему мне отказал Сбер, или что не так с рекомендательными системами в найме

Отказ по вакансии продукт-менеджера рекомендательных систем — повод не для обиды, а для анализа. Потому что ровно те проблемы, которые я решал в своих продуктах, и сработали против меня.

Что требовалось

Вакансия: управление ML-продуктами, A/B-тесты, метрики retention и CTR, приоритизация фичей, работа с кросс-функциональными командами. Стандартный набор для продакта в big tech.

Что я показал

Кейс Chess Legends Engine: шахматный движок, обученный на одном ядре CPU. Свёрточная сеть с жёсткой обрезкой связей (в 7 раз легче без потери качества). Оценочная функция, настроенная не на силу игры, а на имитацию стиля конкретных гроссмейстеров. Результат: 1800 ELO, работает на смартфоне, живые пользователи.

Где система дала сбой

1. Конфликт масштабов. Я показал продукт, запущенный на минимальных ресурсах. Сберу нужен тот, кто управляет кластерами GPU и командами из 30 человек. Рекрутер (и нанимающий менеджер) не увидели перехода: как опыт оптимизации одного ядра масштабируется на enterprise-уровень. И зря. Принцип одинаков: ты управляешь компромиссом между точностью модели и стоимостью её обслуживания. Но я говорил о технологии, а не о продукте — и проиграл. 2. Нет keyword matching. В моём рассказе не прозвучало «A/B-тест», «CTR», «retention». Хотя по сути: обрезка связей — это A/B-тест архитектур. Выбор между точностью эндшпиля и скоростью на смартфоне — это конфликт метрик retention vs latency. Настройка на стиль игрока — это персонализация. Всё это там было, но на другом языке. Система найма (как плохая рекомендательная модель) ищет точные вхождения ключевых слов, а не семантическую близость. 3. Стартап-бэкграунд против корпорации. Это расхождение по оси «субъектность». Я принимал архитектурные решения сам, без согласований с 5 департаментами. Сберу нужен тот, кто умеет работать в иерархии. Мой кейс прочитался как «не встроится в процессы», а не как «умеет доводить продукт до результата при любых вводных».

О чём это говорит

Рекомендательные системы в найме работают так же, как ранние коллаборативные фильтры: ищут похожих на уже успешных. Если в выборке Сбера успешный продакт — это ex-Yandex, ex-VK, с опытом управления командами от 10 человек и рекомендательными системами на миллионах пользователей, то любой выброс за пределы кластера — отказ.

Проблема в том, что такие модели не умеют находить неочевидные совпадения. Они переобучены на исторических данных. А настоящий продуктовый подход требует задавать вопрос: «Что на самом деле делает кандидата успешным на этой роли, и как это измерить не по резюме, а по решённым задачам?»

Что я мог бы сделать иначе

Переупаковать тот же опыт в другие формулировки. Не «обрезали связи», а «провели серию A/B-тестов архитектуры, выбрав конфигурацию с оптимальным балансом latency и accuracy». Не «движок на одном ядре», а «управлял ML-продуктом с жёсткими ресурсными ограничениями, принимая решения о trade-off между метриками».

Суть та же. Восприятие — другое.

Вывод

Отказ не в компетенциях. Отказ — в несовпадении форматов презентации опыта и ожидаемой рамки. Это классическая проблема рекомендательных систем: хороший контент не находит пользователя, потому что плохо векторизован.

P.S. Если вы нанимаете продактов — попробуйте проверять гипотезу не анкетой, а кейсом. Дайте кандидату реальную задачу и посмотрите, как он принимает решения. Это и есть проективная игра. В игре люди не врут. В резюме — врут. Или, как в моём случае, просто говорят на другом языке. P.P.S https://set.ki/post/MfkDMT3 — решение по рекомендательным системам