Не AI Заметки AI Менеджера

📉МЛ, который тихо вредит бизнесу Давно не было постов — надо исправляться. Начну с истории, которая повторилась у меня уже в 3 компаниях) После одного из реоргов моей команде в наследство досталась куча ML-проектов — один из них price recommender (модель, рекомендующая среднюю «правильную» цену за ночь при регистрации апартаментов для их сдачи). Всё считалось рабочим, трогать не предполагалось. Но оказалось — мл-модель должным образом не обновлялась больше года, и никто за это время не перемерял её эффект на ключевую метрику. 📐Что сделали - построили распределения цены, спроса, от времени, и заметили подозрительную корреляцию между тем, как применяется/меняется цена, и целевой метрикой. Чтобы проверить более чисто, собрали offline-симуляцию и после запустили пару blackout экспериментов — выключили фичу для контрольной группы и в другой группе построили простой бейзлайн. Что вышло. МЛ-модель оказалась не нейтральной, а сильно негативной.📉 «Умная» мл-модель тихо делала хуже, чем её отсутствие. Мы её выключили — и, по словам комитета DS-ов, такого сильного движения в A/B давно не было ) Это и был импакт, без единой новой строчки кода.😀 Забавно, что в предыдущей и в следующей компании были очень похожие истории. Правда в последней —рекомендательная система прожила в проде всего 3–4 месяца с негативным эффектом. Но там дело было в другом: постоянно «менялись» инженеры-владельцы, и мониторинг постоянно перенастраивался. 🚀 Мораль: иногда самый большой импакт от унаследованного устоявшегося ML-решения в компании приносит кнопка «выключить это МЛ решение», построить честный baseline и уже от него отталкиваться к чему-то сложному, ну и настривать весь мл-опс пайплайн, устойчивым к изменениям)

Как подготовиться к behavioral interview? Так получилось, что последние пару лет я активно собеседовался на Manager/Staff позиции в крупный бигтех/FAANG(Google, Amazon, Whatsup, Microsoft) и много участвовал в поведенческих интервью. Плюс собеседовал сам на похожие должности и помогал готовиться к таким интервью. Как выглядит подготовка: 1) Нужно взять топ 30 популярных максимально разных вопросов для бихейв интервью, вот некоторые из моего списка: - How do you handle situations when you disagree with Senior Leadership? - Tell us about a time you made a difficult decision that was right for the business but difficult for your people - What was the last bit of feedback you received? - Tell me about a time you had to deliver unpleasant news to someone reporting to you. - What is about big fail or made mistake? 2) Вспомнить все свои истории хотя бы 20 за последние 3 года, и попытаться написать ответы на вопросы, используя истории из рабочей жизни. Лучше следовать STAR формату (situation, task, action, result) + добавить Lessons, которые получили и как в следующие разы это помогло вам избежать/быть лучше в похожих ситуациях. Получится банк историй с маппингом на список вопросов. И даже если будет новый вопрос - вы всегда сможете вспомнить подходящую историю из подготовленного списка. 3) После этого нужно будет много-много раз итерироваться над улучшением вашего банка вопросов-ответов: с собой, на мок интервью, на реальных интервью, пока не будет найден нужный баланс качества. Если на какую-то область нет историй - хороший сигнал о зоне для роста на текущем месте работы, чтобы получить новые истории) Несколько противоречивых моментов, но в нахождении правильного баланса между которыми, как раз и заключается подготовка и тренировка. - История должна быть достаточно детальной, чтобы раскрыть вас с разных сторон. - История должна быть не сильно детальной, чтобы рассказ следовал структуре и был понятен интервьюеру, не знающему весь контекст. 4) Затем перед самим интервью нужно будет прочитать про роль и компанию более подробно и потренироваться еще раз так, чтобы: - Истории показывали величину вашего ownership/responsibility со всех сторон в соответствии с уровнем, на который собеседуетесь. - Истории соответствовали ценностям компании, в которую идете и примерно совпадали с направлением позиции. В целом звучит просто, но это самые сложные интервью в FAANG/Bigtech компании, сильно влияющие на уровень инженера/менеджера, а качество и масштаб историй играет решающую роль здесь. Крутые посты для более детальной подготовки: пост1, пост2, популярные вопросы

Rectools - фреймворк для рекомендательных систем. В сентябре 2025 года Rectools была представлена на ACM RecSys в Праге(лучшая конференция про рекоменадетльные системы) : eSASRec: Enhancing Transformer-based Recommendations in a Modular Fashion. Приятно, что когда-то внутренний фреймворк (rectools), родившийся в команде рекомендательных систем в МТС в 2021 году превратился в большой международный независимый opensource проект благодаря людям, продолжающим заниматься фреймворком и по сей день. Тепло вспоминаю, как мы с командой в 2022 году выложили в открытый доступ нашу маленькую внутреннюю библиотеку для рекомендаций, которую протестировали всего на 3 внутренних проектах. С тех пор Даша(t.me/redrecsys) и Эмилий с командой развили библиотеку, трансформировали и вырастили до 430 звездочек. И даже когда полностью сменилась команда, менеджеры, компании, страны - проект развивается и становится лучше. За 2024-2025 вышло больше 10 релизов: ребята добавили SASRec, BERT4Rec, HSTU, двухуровневые пайплайны с CatBoost, debiased оценку и ещё кучу всего. Кстати, очень рекомендую для всех, кто хочет быстро построить рекомендательные системы из коробки. github

Performance review (PSC) в BigTech для ML-инженеров По нашумевшим новостям про изменения PSC следуюший пост: Performance and Skill Calibration (PSC) – так в Bigtech называют полугодовой/годовой цикл оценки работы, определяющий развитие инженера, бонусы и акции. Процесс более менее прозрачен: инженер пишет self-review документ с достижениями и док-вами, собирает отзывы от коллег (peer review), а менеджер готовит PSC в специфичном формате. Затем на калибровочной сессии менеджеры и Staff+ engineer уходят на 3 недели сравнивать результаты сотрудников, чтобы выровнять их по разным осям. Менеджер на такой сессии – играет роль адвоката, но зависит от него процентов 35 на мой взгляд: он презентует кейс, успехи, предлагает итоговый рейтинг, а дальше все его челенджат. 4 основные “оси” оценки инженера(меняются от компании к компании, но суть похожая): Impact – результаты работы и влияние на цели команды/продукта в $$$. Это главная ось: что было сделано и как это продвинуло бизнес/направление или технологию - от инженера ждут осязаемого эффекта от его работы. Суммарная польза для бизнеса: например, улучшили метрику качества рекомендации на X%, сэкономили $Y за счёт оптимизации модели, внедрили ML-фичу, которая принесла рост аудитории на Z% и т.п Импакт может быть не прямой, а через direction и тд на более высоких грейдах. Engineering Excellence – качество и эффективность технической работы в общем смысле – насколько ты продуктивен (скорость разработки), насколько качественно написан код, умеет ли инженер проектировать устойчивые системы и решать сложные технические проблемы. Для ML-инженера сюда относится также создание надёжных пайплайнов данных, МЛ дизайны, соблюдать best practices в экспериментах и т.д. От сеньора+ ожидается изменение продуктивности команды, другая глубина решения технических проблем, улучшение инженерных процессов (тесты, документацию, автоматизацию) в целом. Direction (самостоятельность и лидерство в определении курса) – умение задавать правильное направление работы. Если представить, что инженер – это вектор, то предыдущая ось (Excellence) отвечает за его величину (силу), а Direction – за направление этого вектора. Даже супер талантливый ML-инженер не принесет пользы, занимаясь не теми проблемами, не спрашивая вопросов почему и зачем. Direction включает сразу несколько аспектов. На личном уровне – это проактивность и организация своей работы: умение ставить цели, планировать проекты, доводить задачи до конца без постоянного контроля. На уровне команды/продукта – это лидерские качества: способность влиять на roadmap, предлагать новые инициативы, брать ответственность за большие проекты и вести за собой других. На сеньорных ступенях (E5+), чтобы расти дальше, инженеру необходимо показывать серьёзный прогресс именно по оси Direction – быть лидером, а не исполнителем задач. Мыслить стратегически,а не тактически - видеть большую картину. People (взаимодействие и вклад в команду) – коммуникация, сотрудничество, влияние на людей. Результаты создаются командами, поэтому успех отдельного инженера не может быть без навыков работы с другими, все-таки социальная сеть. People-ось на младших уровнях проявляется в умении эффективно работать в команде: помогать другим инженерам, делиться знаниями, вписываться в культуру. От ML-инженера ожидается, что он умеет обсуждать требования со всеми: продакт-менеджерами, вместе с дата-сайентистами анализировать данные, софтвер-инженерам ясно объяснять потребности ML-системы – словом, быть командным игроком. На более высоких уровнях People включает лидерство: наставничество менее опытных коллег, разрешение конфликтов, ведение кросс-функциональных обсуждений, влияние на культуру. Под People понимают весь организационный вклад инженера: помощь росту коллег (обучение, код-ревью, менторинг), участие в Hiring (собеседования, оценка кандидатов), поддержание командной культуры (например, технические доклады, инициативы по разнообразию). Вся информация собрана по открытым источникам) Больше про это здесь; здесь и здесь

LLM basic overview Недавно собирал полезные ссылки для подготовки к верхнеуровневому собеседованию на AI-инженера для перекатывающегося приятеля инженера из классики в LLM, показались весьма полезными и для Дата сайентистов и для всех инженеров . Полезные ссылки: - Красивые ответы на интересные вопросы из таких компаний как Deepmind - 500 кейсов LLM из разных компаний System Design overview - часть 1 - часть 2 RAG - Общее понимание работы и оценки RAG Interview - Как проходит интервью? - igotanoffer

Собеседования на менеджерские/руководящие роли в AI/ML/DS/Engineering/Applied Science. Так получилось, что за последние пару лет я активно собеседовался на разные менеджерские ML роли в Big Tech компаниях: Google (отказ), Amazon (оффер на Applied Science Manager), Uber (EM — 2 раза отказ), Facebook (AI EM — оффер), Spotify (отказ), Microsoft(отказ) и тд. Кроме того, несколько раз помогал готовиться другим кандидатам на похожие позиции. Так как вообще проходят собеседования на менеджерские роли в сфере AI/ML (команды примерно 5–20 человек) в FAANG+ компаниях? Как правило, процесс состоит из нескольких этапов. Отдельные этапы могут отсутствовать в некоторых компаниях, но в FAANG+ обычно присутствуют почти все перечисленные (в сумме выходит 7–10 интервью). Этап 1. Скрининг и первичный отбор. - Скрининг резюме: Резюме оценивает рекрутер, нанимающий менеджер и auto-screening. Часто помогает подача через реферал, известные компании в опыте, лучше убрать все намеки на возраст (даты выпуска с университета), фото и тд. - Созвон с hiring менеджером: behavioral interview на матч к позиции (cultural fit). Иногда такое интервью проводят ближе к финалу процесса, но нередко и в начале. - Интервью с HR (recruter): high-level обсуждение соответствия вас под вакансию, после чего HR передаёт свои заметки hiring менеджеру для принятия решения. Иногда этот этап недооценивают, хотя процент отказов на этом этапе не маленький. Этап 2. Предварительный технический и поведенческий скрининг. На этом этапе обычно проводят технические интервью и поведенческие интервью. Грубо говоря, это отборочный этап на допуск к основным собеседованиям 🙂Суммарно может быть 2-4 интервью. - Технические интервью: Например, для DS ролей это могут быть вопросы по Python + SQL и дизайн A/B теста (+ базовая статистика). Для EM — классический Coding(leetcode style), ML — ML System Design + могут попросить разобрать проект из вашего опыта. - Поведенческое интервью: фокус на каком-то одном или нескольких аспектах менеджерской работы. Основные темы — People Management, Stakeholder Management , Cultural Fit, Project Management. Иногда одно интервью покрывает все аспекты. Этап 3. Основной цикл интервью (Loop). Это серия углубленных интервью — обычно 5–6 раундов, покрывающие все вышеперечисленные темы с деталями. Иногда может быть два интервью на одну тему. - Behave: Отдельные поведенческие интервью с акцентом на тех же темах: People Management, Stakeholder Management, Cultural Fit, Project Management. Каждый из этих раундов проводится часто скип-менеджерами/менеджерами смежных команд. - Технические навыки: Глубокие технические интервью на ML System Design, System Design, Coding. Для некоторых ролей могут добавить (понимания ML-методов в глубину) или дополнительные вопросы по ML+ (ML в ширину), могут попросить разобрать статью на ресерч позиции. После прохождения основного цикла собирается команда интервьюеров, чтобы принять решение. В случае с бигтехом это делается отдельной дополнительной комиссией из директоров. Этап 4. Team Matching (выбор команды). В некоторых компаниях после общего loop начинается подбор конкретной команды. Этот этап может включать дополнительные собеседования, бывают отказы и на этом этапе - после всех пройденных 8 собеседований 😀 - Повторный cultural fit: Ещё одно поведенческое интервью c hiring менеджером и/или с skip manager. - Team interview / знакомство с командой: Неформальная встреча с командой, редко встречается. Этап 5. Рекомендации (опционально). Не во всех случаях, но иногда финальный шаг — это проверка/запрос по прошлым компаниям по деталям опыта, успешность проектов, стиль работы в команде и т.д. Этот этап служит дополнительной проверкой перед окончательным оффером. Каждый из описанных этапов может слегка различаться в зависимости от компании и конкретной роли, некоторые этапы могут объединяться, пропускаться и заменяться. Однако в целом процесс собеседования на менеджерские позиции в сфере ML/AI примерно такой.

Испытательный срок в FAANG Сегодня чуть больше полугода, как я работаю Engineering Manager ML(AI) команды в новой компании (FAANG) в лондонском офисе. Возможно, это были одни из самых сложных 6 месяцев за последние мои 8 лет карьеры в DS/ML (если брать в расчет только работу без совмещения с учебой). Как оказалось, в некоторых местах испытательный срок - это период, где не такой уж и маленький процент людей, особенно на более высоких грейдах - может вылететь. Так что, в текущей компании можно зачесть прохождение этого порога как мини-достижение. ☺️ Впечатления от первых 6 месяцев В целом, ожидания как от менеджера, так и от МЛ инженера в FAANG достаточно высокие, подробнее об этом здесь и здесь. Если суммаризировать в одно предложение, как сказал мой бывший ментор Mahmoud (очень классный парень ) в текущей компании (сейчас ушел на Старшего менеджера в Deepmind(M2/L7)) : ожидания от тебя как от директора инженеров в компании немного поменьше, но без возможности управлять менеджерами напрямую, а только командой МЛ-разработчиков. Соответственно от senior инженера - ожидания как от принципала и тд. Про ожидания от разработчиков в FAANG компаниях в ссылках ниже ))) Challenges Одно из самых сложных мест онбординга для менеджера - собрать весь контекст работы по кусочкам. Как оказалось, несмотря на LLM бум, нужно много собирать контекста именно по людям. Понятно, что первые месяцы в компании, в которой рекламе много лет, нужно прочитать кучу материалов, кода, дизайн доков, чтобы понять, чем вообще твоя команда занимается и как это матчится с окружением. 3 недели уходят только на понимание новых терминов и сленга. Но чтобы понять приоритеты, alignment между командами, что хотят разработчики, что хочет менеджмент, пообщаться и выстроить отношения со всеми горизонтальными командами - уходит еще пару месяцев. И единственный способ - выцеплять всех на 1-1 и пытаться дополнить инфу по кусочкам. Календарь был завален 1-1 со всеми пирами, моими инженерами, диагональными боссами и тд. Через них я узнавал, как всё работает на самом деле, кто негласный лидер команды, у кого какие сильные и слабые стороны в команде, какие недавние решения вызывают вопросы, какие метрики важны и тд. Другая сложность - это найти баланс между погружением в детали и пониманием общей картины - deep dive and wide. ("Don’t miss the forest for the trees") .Тут я решил воспользоваться обходом дерева в ширину, и только иногда в глубину) Слой за слоем пытался понять, как работает реклама, что делает команда и иногда возвращаясь на несколько уровней выше. И последнее - это постоянная приоритизация каждых 30 рабочих минут и задач, которые ты делаешь в момент времени, какие митинги ты пропустишь, а какие нет, что почитать, а что нет, в условиях неопределенности с переключением контекстов каждый час. Но тут пригодилась/вспомнилась учеба на ВМК со совмещением фул-тайм работы))) В общем, необычно, сложно, но интересно. Непрошеные советы: - Найти менторов, кто уже работает в компании давно на похожей или +1 позиции. - Плавно погружаться в контекст, слой за слоем. - Выстроить отношения с командой, peers, менеджером. - Откалиброваться по ожиданиям: понять, что, когда, почему от тебя ждут в компании как можно скорее. Текущие проекты. Про цели и задачи пока рассказывать не могу, кроме того, что удалось собрать команду для нового направления почти с 0. Интересные ссылки - Meta (Facebook): Engineering Manager Checklist, - Культура и уровни в Facebook(cсылка1, ссылка2) - Интервью и ожидания

Telegram-каналы В недавнем видео (которое скоро выйдет на youtube) я обещал поделиться небольшим списком Telegram-каналов, которые рекомендую к прочтению (если сделать весь список, то выйдет больше, чем на два поста). Они охватывают новости ML, разработки рекомендательных систем, а также личный опыт людей из индустрии. 📢Общие каналы про индустрию - t.me/seeallochnaya — новости (с авторскими комментариями) из мира NLP, VR и космоса. - t.me/ai_newz — освещение важных (и не очень) новостей из мира ИИ. Ведёт канал экс-исследователь из Meta AI, ныне основатель AI-стартапа в Швейцарии. - t.me/deeplearning_ru — анонсы новых библиотек и препринтов в сфере AI/ML, особенно про Generative AI, LLM. - t.me/bdscience — англоязычный канал про DS индустрию. - t.me/llm_under_hood - канал про LLM и все, что около. - t.me/datarascals — про жизнь менеджеров, аналитиков и data scientists в корпорациях от Никиты Зеленского. - t.me/rybolos_channel — размышления о нейросетях, технологиях и искусстве. Таня Шаврина лидит LLM команды в соседней с моей организации. 🤖 Рекомендательные системы - t.me/ods_recommender_systems — открытый чат сообщества Open Data Science, посвящённый рекомендательным системам. - t.me/YourFirstRecsys — ещё один чат для обсуждения рекомендательных систем и всего, что с ними связано. Изначально создан как площадка поддержки курсов Your First RecSys / Your Second RecSys (командой рексис МТС, которой я руководил 4 года назад, и библиотеки RecTools), сейчас он вырос в сообщество, где обсуждаются любые темы RecSys. - t.me/redrecsys — авторский канал о рекомендательных системах и смежных темах от Даши, которая сделала невероятно быструю карьеру от джуниора до стаффа меньше, чем за 4 года. Когда-то Даша выиграла конкурс от МТС по рекомендашкам и устроилась к нам в команду. - t.me/inforetriever — канал Кирилла Хрыльченко, бывшего лида R&D-группы по RecSys в Яндексе. - t.me/WazowskiRecommends — канал Michael Roizner, где он пишет о рекомендательных системах и не только. С недавних пор мы работаем в одном департаменте. 🧑‍💻 Личные блоги - t.me/kantor_ai - канал Виктора Кантора, с курсов которого я начал свой путь в ML/AI 9 лет назад и под руководством и менторством которого получилось сделать относительно быстрый карьерный рост в индустрии. Думаю, в представлении Витя не нуждается) - t.me/new_yorko_times — Юрий Кашницкий, мой приятель, (Yorko, в TG: @yurycorn) делится заметками про машинное обучение, науку, «галеры», матан, карьеру и другими интересностями. Не обходится и без историй о рабочих буднях. Скорее всего, вы не можете его не знать. - t.me/cryptovalerii — личный канал Валерия Бабушкина, думаю в представлении тоже не нуждается) - t.me/zborovskiy_x — персональный блог Димы про опыт работы в данных и аналитике на топ-менеджерских ролях. - t.me/SecretOfNoodleSoup — мысли и опыт Евгения Козлова. Евгений был Yandex Fellow и руководителем аналитики в Яндекс.Такси, а сейчас — CDO сразу в двух компаниях (Dwelly в Великобритании и Rhino в Бразилии).

⚡️ Укорачивай цикл. Чем быстрее гипотеза проверится на пользователях, тем меньше шанс, что за это время изменятся сами пользователи или контент. Минимизируйте задержку между оффлайн-экспериментом и онлайн-тестом. Один из подходов – off-policy оценка новых моделей: методы типа Inverse Propensity Scoring или Doubly Robust позволяют прикинуть эффект модели на основе собранных логов, без мгновенного выпуска в продакшен. Это активно исследуется и даёт возможность оценивать ранжирующие алгоритмы по логам с приемлемой точностью. Да, приходится вводить допущения и бороться с дисперсией оценок, но для некоторых задач (например, рекомендаций с явным фидбеком) это работает. А в онлайне для ускорения итераций можно вместо классического 50/50 A/B-теста использовать метод многорукого бандита (Bandit) – динамически перераспределяя трафик к лучшему варианту. Если риск от неудачного варианта невелик, бандиты позволяют быстрее подтвердить преимущество новой модели. 📊 Копи и анализируй эксперименты. Не пренебрегайте кропотливым сбором статистики по множеству запусков. Со временем можно выявить, какие именно оффлайн-метрики хоть как-то предсказывают успех по ключевой онлайн-метрике в вашем продукте. Иногда это не одна метрика, а комбинация показателей. Например, на платформе OTTO (крупный европейский e-commerce) провели масштабный эксперимент: одновременно протестировали группы рекомендаций, оптимизированные под разные оффлайн-метрики, и потом замерили их онлайн-результаты. Итогом стала идентификация стабильных соответствий между определёнными оффлайн метриками и реальными метриками кликов и конверсий пользователей. Проще говоря, удалось найти наборы оффлайн-метрик, рост которых практически гарантирует улучшение CTR и Post-Click конверсии онлайн – ценнейшая информация для команды. 🤖 Построй мета-модель. Если у вас накопилось достаточно данных по прошлым экспериментам, можно попробовать обучить простую модель или вывести эвристику, которая будет предсказывать шанс успеха нового алгоритма. Идея в том, чтобы по fingerprint оффлайн-результатов (например, разнице в precision, diversity, novelty по сравнению с текущим продакшеном) прикидывать, “выстрелит” ли модель онлайн. Такой себе внутренний оракул: «Если оффлайн precision вырос на +5%, новизна упала на -2%, а покрытие увеличилось на +10%, то вероятность выигрыша по CTR ~80%». В индустрии рассказывают, что подобные мета-модели помогают фильтровать заведомо бесперспективные запуски. 💬 Мой опыт В Booking.com проблему разрыва метрик пытались решить системно: построили платформу для экспериментов, где каждый запуск логировался и сохранялся в MLflow. Для каждой модели хранились все рассчитанные оффлайн-метрики, а после A/B-теста туда же добавлялся результат онлайн. Со временем накопился датасет экспериментов, из которого стало понятно, какие алгоритмы переобучаются (оффлайн хорошие метрики, но стабильно “красные” тесты), а какие действительно дают прирост. Во многом благодаря этому мы начали доверять некоторым оффлайн-показателям и ускорили цикл разработки. В другой компании мы даже пробовали собрать небольшой мета-ранкер на базе прошлых запусков. Он оценивал новую модель по совокупности характеристик (метрики точности, разнообразия, новизны и т.п. относительно текущей версии) и выдавал score приоритетности для онлайна. Конечно, это не заменяет живой A/B, но как дополнительный сигнал – весьма полезно, особенно когда ресурсов на эксперименты ограничено. 📎 Материалы, которые советую: - Identifying Offline Metrics that Predict Online Impact (RecSys 2025) - Handling Online-Offline Discrepancy in Ads Ranking (Pinterest Engineering) - Offline vs online vs business metrics - Doubly Robust Off-Policy Evaluation - Валидация в RecSys для корреляции в А/Б - Mastering Recommendation Systems Evaluation: An A/B Testing Approach with Insights from the Industry

⚖️ Offline vs Online Evaluation Gap in RecSys: Why an Offline Leader Can Fail an A/B Test Немного более технический пост. Во всех компаниях, где я работал (или слышал от друзей из FAANG+ компаний), рано или поздно возникал один и тот же вопрос: как предсказать, что алгоритм, хорошо показавший себя на исторических данных, действительно улучшит метрики пользователей в продакшене? Это распространённая проблема в индустрии рекомендаций. Например, мы строим рекомендательную систему фильмов: есть 4 модели, каждая показывает высокий precision@10 оффлайн. Но нам-то важно улучшить реальное поведение — скажем, среднюю длительность просмотра. А между этими двумя видами метрик зевает разрыв 🧠 Почему оффлайн ≠ онлайн? Данные оффлайн vs онлайн: Оффлайн-оценка идёт на залогированных исторических данных (часто полученных под старой моделью), а онлайн – это реальное поведение пользователей при работе новой модели. Онлайн взаимодействия включают эффект новизны рекомендаций, актуальный контекст и особенности интерфейса, чего нет в оффлайне. В результате offline метрики и online метрики могут не совпадать. Метрики точности vs бизнес-метрики: Метрики типа Precision@K, NDCG@K, Recall@K и прочие оценивают точность ранжирования, но не всегда коррелируют с конечными метриками вроде CTR, watch time или retention. Например, один пользователь может кликнуть только самый первый рекомендованный элемент, а другой – два элемента из списка, но не с самых топовых позиций. У первого будет выше NDCG, у второго – больше кликов. Если бизнес-цель – количество кликов, то второй случай лучше, хотя оффлайн-метрика ранжирования этого не отразить. Изменение поведения пользователей: Деплой новой модели сам по себе меняет поведение аудитории, и это не учитывается в оффлайновой оценке. Пользователи адаптируются к новым рекомендациям: могут начать по-другому реагировать на контент, иначе проводить время на сервисе. Более того, в A/B-тесте контрольная группа (старая модель) тоже не остаётся в вакууме – она обучалась на прошлых данных, а в онлайне сталкивается с изменением среды из-за присутствия новой модели. В Pinterest, например, заметили, что во время онлайн-эксперимента продакшн-модель пытается учиться от трафика, уходящего на тестовую модель, снижая разницу в результатах Несоответствие целей оптимизации: Часто оффлайн-метрика – это proxy, который не напрямую оптимизирует то, что нам нужно онлайн. Например, рост ROC-AUC оффлайн не гарантирует снижение Cost-per-Acquisition онлайн, потому что AUC и CPA измеряют разное. В Pinterest выяснили, что даже при материальном улучшении AUC оффлайн невозможно с высокой уверенностью предсказать значимый выигрыш по CPA онлайн – разброс результатов слишком велик. Иными словами, выиграть по оффлайн-метрике не значит выиграть A/B-тест. 🔍 Что делать? 🗃 Логируй всё. Стабильно работающее продуктовое логирование – фундамент. Нужно сохранять оффлайн и онлайн-метрики, предсказания моделей, фичи и реальные реакции пользователей. Потом это позволит сопоставлять оффлайн-оценки с онлайном и учиться на каждом эксперименте. Для каждой модели нужно сохранять признаки и результаты, а затем любой чекпоинт модели можно прогнать на залогированных данных, воспроизводя трафик, чтобы выявить расхождения оффлайн vs онлайн. Кроме того, строить сервис, сравнивающий фичи, используемые при выводе рекомендаций и при логировании, чтобы сразу отловить рассинхрон и баги в данных. Такая система значительно ускоряет отладку и анализ результатов A/B тестов.

Как понять, что твой будущий руководитель не м...к (адекватный в people management) ? Мы очень много говорим о том, как проходить собеседования в разные компании и что спрашивают в том же FAANG. Но не менее важно — как понять, что команда, компания и особенно твой будущий руководитель — адекватный человек. Ведь хороший рук-ль сильно не улучшит жизнь, но плохой сильно может испортить :) Мы с друзьями часто обсуждали эту проблему, но ответа так и не нашли. По сути, у компании есть 4–10 раундов интервью, чтобы прособеседовать тебя. А у тебя — только 30, иногда 45 минут, чтобы понять, насколько команда и руководитель вообще ок. (Опять тут маленькая оговорка, что это доступно, только при условии выбора из больше, чем одной команды) Так как это сделать - честно не знаю, но есть несколько моментов/вопросов которые я и некоторые мои друзья из tech пытаются понять о менеджере: ▪️ Процессы или люди? Можно не напрямую, но аккуратно понять, что для менеджера важнее — процессы или люди. Насколько для него важно «следовать правилам», и насколько он гибок по отношению к людям. Трюк: спросить, как у них с офисом или временем работы и/или во сколько приходить на работу и как строго это. 📛 Red flag: «У нас стало строго. Недавно сделал выговор человеку за то, что он в среднем был в офисе 2.9 дня в неделю вместо 3.» ✅ Green flag: «Главное — в целом держаться в норме, мне ок, если кто-то иногда плюс-минус отклоняется.» Да, это реальные ответы с тим-матчингов в FAANG+ компаниях. ▪️ Проверка на рефлексию Задайте что-то вроде: «Приведи пример недавнего провала/неудачного эксперимента за последний год. Чему вы научились?» 📛 Red flag: «У нас таких нет. Или ну… один Петя, департамент, компания — всё испортили.» ✅ Green flag: честный рассказ о том, что не сработало и какие выводы из этого сделали. ▪️ Проверка на эмпатию Можно пообщаться на более личные темы: релокация, бэкграунд, дети, образование. Понять, есть ли у человека интерес к вам — как к личности, а не только как к ресурсу. ▪️ Проверка на эрудицию Понять, живёт ли человек чем-то, кроме работы. Чем увлекается, что его вдохновляет. Просто почувствовать, есть ли баланс в жизни. Понятно, что всё субъективно. Но мне кажется, даже за 30 минут можно уловить какие-то сигналы — и понять, что перед тобой чуть более эмпатичный, рефлексирующий, живой человек, для которого люди всё-таки важнее процессов. А это уже немало.

💼 Как я попал в FAANG на позицию Engineering Manager в AI-команду Мысли о FAANG впервые появились у меня лет 8 назад. Тогда я посмотрел пару интервью русскоязычных ребят из Долины — и что-то щелкнуло. В это же время мои одногруппники‑олимпиадники с ВМК МГУ начали ездить на стажировки в Google. Я тогда был далеко не самый сильный из них (скорее наоборот), но очень было интересно, каково там работать. В 2020-2021 годах, став около Senior, а потом и ML Manager в российском бигтехе, казалось до работы мечты еще очень далеко и идея подзабылась. Но в 2022 году начал активно готовиться к интервью, имея A2/B1 английский в запасе (долгая история почему так), мне в основном отказывали на резюме или hr скрининге на любые позиции около Data Scientist/MLE/ML Manager в FAANG, но смог попасть в Booking спустя 6 месяцев подготовки. (Пишите в коментах, если интересно подробнее) В 2023 — собеседовался, но в основном вылетал на алгоритмах, не любил никогда литкод, но вынужден был переботать. (пишите в коментах, если интересно подробнее) Всё поменялось в 2024 году. После ~10 интервью (и 40+ отказов до этого), я получил два оффера — один от Amazon, другой от Meta, оба на L6, но по менеджреской ветке (до Гугла не хватило немного на литкоде - видимо не дожал в подгтовке) Сейчас я работаю AI/ML Engineering Manager в Лондоне, в одной из ключевых команд Core Ads. Что возможно помогло: - Принципиально перестроил подход к собесам. Вместо “всё про алгоритмы” — упор на behavioral-интервью. - На уровне L6+ (менеджеры, старшие инженеры) умение рассказывать истории, убеждать, объяснять impact — решает больше, чем все остальное в совокупности с ML System Design интервью. - Каждый отказ - learning как обучаться для следующих интервью: сохранял фидбэк, переписывал истории, просил примеры у знакомых, получал необходимый опыт и scope на текущей работе. Что я понял - FAANG — это не история про гениев с дипломами MIT. Это история про тех, кто не сдаётся, учится на ошибках и вкладывается в подготовку. Сейчас я сам провожу мок-интервью и могу точно сказать — у многих отличных кандидатов есть скиллы, но нет структуры и уверенности, особенно в поведенческих интервью. В следующих постах могу поделиться фреймворком подготовки к поведенческому интервью, как отвечать на "tell me about a time..." и не теряться на вопросе про big failed на L6+ уровне.

Не AI Заметки AI Менеджера pinned a photo

Channel photo updated

👋 Привет! Это «не AI Заметки AI-менеджера» — место, где я делюсь опытом руководства ML-командами, построения рекомендательных/ранжирующих систем, управлением ML-продуктами и просто мыслями о жизни в Амстердаме, Лондоне и Москве. Меня зовут Ильдар, мне 27 лет. Сейчас работаю AI/ML Manager в одной из FAANG+ компаний (Лондон), до этого — в Booking.com (Амстердам), а ещё раньше — в Москве. Люблю путешествовать, преподавать, спорт и вино. Здесь я буду писать о том, как: - строятся ML‑системы в больших ( и не очень) компаниях (LLM, рекомендашки, ранжирование, эксперименты, метрики) - развиваются ML-команды (0 -> 1), рост, 1:1, культура FAANG, фреймворки. - меняется жизнь и мышление, когда живёшь и работаешь в Лондоне, Амстердаме и Москве. Что между этими городами общего, а что разное. - а также рандомные мысли про философию, AI, интересные события и путешествия. Попробую сделать коротко, честно, опираясь на свой очень субьективный опыт. Если интересно — оставайтесь 🙌 — Ильдар

Channel created