Загрузка…
Загрузка…
ml / middle / tech_deep
Формат
online
Стадия
tech_deep
Когда
within_week
Длительность
60 мин
01
Поведенческий
Расскажи, чем ты в целом занимался в последнее время — что самое интересное, сложное или полезное ты сделал за последние год-два-три?
Кандидат рассказал про работу в Яндекс Картах: UGC-контент, пуши с просьбой оставить отзыв, улучшение геолокации без GPS
02
Кейс
Как ты думаешь, применим ли твой опыт с задачей геолокации к рекомендательным системам?
Кандидат переформулировал задачу геолокации в терминах рекомендательных систем (кандидат-генерация, ретривал, ранжирование), но отметил ограничения по RPS
03
Теория
Расскажи, как формулировалась задача отправки пушей как задача машинного обучения: какие были ограничения, какие метрики выбирали?
Кандидат описал задачу как смесь ранжирования и классификации с обучением на логлосс
04
Заметки
Публичное (мок) собеседование Хабр Карьеры с компанией X5 Tech (в тексте название встречается как «истотех», «экспертех», «икс пять тех»). Кандидат Борис — ML-инженер из Яндекса (Яндекс Карты, 3,5 года), интервьюер Максим — руководитель направления развития ИИ в X5 Tech. Вакансия — рекомендательные системы (индивидуальный контрибьютор, позиции от джуна до тимлида). Кодинга и behavioral-секции не было — заявлено, что они могли бы быть на следующих этапах. Итог: интервьюеру в целом ответы понравились, отмечена нехватка детального погружения в механику (лосс, тюнинг катбуста) и смещённость опыта на инфраструктуру Яндекса; вопрос о продолжении общения с кандидатом прозвучал, но явного решения в транскрипте нет.
Подготовка
Интервьюер отметил: нужно детально понимать механику используемых лоссов (не только концептуально), уметь тюнить гиперпараметры бустингов и объяснять их влияние, знать Spark и типовые проблемы джойнов (data skew) без опоры на автоматику внутренней инфраструктуры, уметь объяснять вещи людям не из ML. Сам кандидат признал, что стоило лучше подготовиться по лоссам.
Стиль интервьюера
Интервьюер активно копает вглубь follow-up'ами, оспаривает утверждения кандидата (например, «катбуст не переобучается»), моделирует практические сценарии («пришла промо-акция», «в городе X пуши не работают»), готов спорить и обмениваться опытом. Большой акцент на продакшен и инфраструктуру (деплой, базы, масштабирование, A/B), а не только на ML-теорию. Дружелюбная атмосфера, развёрнутый честный фидбэк в конце.
Теория
Что подаётся модели на вход — это просто пользователь или ещё что-то? Это модель внутри бэкенда? Вы создавали её с нуля или улучшали существующую?
Фичи про пользователя, про организацию и контекстные фичи; модель создавалась с нуля
05
Теория
Какие у вас были метрики и какие модели вы решили использовать?
Обсуждались top-k метрики на рандомном своде (1% пользователей получают рандомные пуши), precision/recall, отличие обучения с нуля от переобучения против модели в продакшене
06
Теория
Почему вы использовали логлосс, а не что-то другое?
Follow-up к вопросу о метриках; кандидат упомянул query-wise вариант логлосса (агрегация по запросу/пользователю, а не по документам)
07
Теория
Можешь рассказать, как работает этот модифицированный (query-wise) логлосс — за счёт чего происходит поправка?
Кандидат не смог детально объяснить механику лосса — интервьюер отметил это в фидбэке
08
Теория
Почему катбуст — почему это стандартное решение для задачи такого типа?
09
Теория
Почему не обучили нейронку или не воспользовались алгоритмами линейной оптимизации, которые тоже могут решать эту задачу?
Кандидат сослался на худшую интерпретируемость нейронок и негативный опыт интерпретации feature importance в большой модели
10
Теория
Расскажи, как ты тюнил катбуст и как определял, что он не переобучается?
Интервьюер оспорил тезис кандидата, что катбуст редко переобучается
11
Теория
Назови три важных гиперпараметра, которые могут сильно влиять на качество работы катбуста (или других бустингов)?
Кандидат назвал learning rate, overfitting detector, l2-регуляризацию, количество семплов в листе, глубину дерева; интервьюер посчитал ответ недостаточно глубоким
12
Теория
Что будет, если глубины дерева не хватает, и как ты поймёшь, что её не хватает?
Follow-up к вопросу о гиперпараметрах; обсуждали взаимодействие фичей, добавление отношений/разностей фичей вместо увеличения глубины, зависимость рекомендуемой глубины от числа фичей
13
Теория
У вас очень много данных — как вы обучаете модель на таком большом количестве данных, если они не влезают в одну машину? Используется ли распределённое обучение?
Follow-up: будет ли качество лучше или хуже при разбиении датасета по GPU
14
Кейс
Если данные сильно неоднородны (поведение пользователей в Москве отличается от Санкт-Петербурга) — ты бы всё ещё использовал рандомное разбиение? Стоит ли обучать отдельные модели для разных городов?
Обсуждали добавление категориальной фичи «город» vs отдельные модели, смещение фичей, трейд-офф с размером моделей; кандидат привёл пример отдельной модели для Турции
15
Кейс
Задача про Spark: есть таблица данных, её нужно поджойнить с витриной по ключу. Ты запускаешь джойн, и все вычисления падают — не хватает памяти. На что смотреть в первую очередь, где искать проблему и как решать?
Серия follow-up'ов: ключи уникальны в обеих таблицах, таблица партиционирована по ключам — что ещё может ломаться (размер строк, количество партиций)
16
Кейс
Мы знаем, что распределение данных по партициям неравномерно — одна партиция в 10–100 раз больше остальных. Как можно полечить такой перекос данных при джойне?
Follow-up: проблема остаётся, даже при merge join воркер падает; кандидат затруднился — в Яндексе эти проблемы решены автоматически
17
Теория
В чём разница между реплицированием и шардированием?
Задан внутри system design секции; обсуждали географическое шардирование и нюансы балансировки
18
System design
System design: у нас есть мобильное приложение, в котором мы хотим сделать рекомендательную ленту товаров — бизнес хочет нарастить товарооборот. Что бы ты спросил и как бы приступил к задаче?
Кандидат уточнял: контекст показа, частота обновления (раз в день), количество рекомендаций, товары vs категории, метрики (товарооборот vs маржа), регистрация пользователей, холодный старт
19
System design
Какие компоненты ты видишь у такого решения, если такой системы нет и её надо создать с нуля?
Обсуждали key-value хранилище для пользователей и рекомендаций, сервис для запросов, взаимодействие фронта и бэка
20
System design
Какая база данных подходит для in-memory хранения топ-10 рекомендаций на пользователя — например, подходит ли ClickHouse, и почему Redis?
Follow-up внутри кейса; кандидат предложил Redis, обсуждали его шардируемость
21
System design
Как проводить A/B-эксперименты с новой версией модели — кто должен владеть экспериментом и как разделить ответственность между бэкендом и системой экспериментов?
Обсуждали варианты: две базы и роутинг по сплиту vs одна база с заливкой на стороне бэкенда; кто раздаёт айдишники тестов
22
System design
Внезапно пришла промо-акция и нагрузка резко выросла — база не успевает отскейлиться, запросы пропадают или их надо ретраить. Как сделать систему устойчивее к такому всплеску нагрузки?
Обсуждали балансировщик, очереди запросов, ретраи, таймауты, предзагрузку рекомендаций, кэширование на сутки
23
System design
Как такая система должна масштабироваться — допустим, ты знаешь, что у тебя будет тысяча или десять тысяч RPS?
Follow-up'ы: что ты подразумеваешь под шардированием, рандомное шардирование, подключение реплик в моменты высокой нагрузки
24
System design
Как бы ты предложил перейти от ежедневного батч-расчёта рекомендаций к онлайн-прогнозированию?
Кандидат описал двухбашенную модель, многоэтапный каскад (кандидат-генерация → лёгкое ранжирование → тяжёлое ранжирование по эмбеддингам), онлайн-фичи (корзина), географическую доступность товаров
25
Поведенческий
Был ли у тебя реальный опыт, когда бустинг работал не очень, ты покрутил гиперпараметры и он заработал хорошо?
Задан в секции обратной связи в ходе спора об итеративном улучшении моделей; у кандидата был такой опыт с LightGBM