OLX2026-03-04
Разбор технического собеседования: OLX: Техническое собеседование
Technical marketplace ML case: бизнес-метрики, признаки цены объявления, temporal validation, модель и A/B новой поверхности.
Этапы
6
Вопросы
12
Практика
13
Кейс простыми словами
OLX - это двусторонний маркетплейс. У модели почти всегда есть три группы последствий: покупатель быстрее находит подходящее объявление, продавец получает честный шанс продать, платформа зарабатывает и не портит доверие к рынку.
Кейс был не про “выбрать модель получше”. Сначала нужно понять продуктовое действие: подсказка цены, скидка, место в карусели, тег или ранжирование. Потом модель оценивает последствия этого действия, а отдельное правило решает, что показать пользователю.
Разбор держится на пяти опорах: метрики сторон маркетплейса, признаки цены, проверка на исторических данных без утечки будущего, разделение оценки модели и продуктового действия, затем A/B, где эффект новой поверхности отделен от эффекта ML-ранжирования.
Карта разбора
6
этапов с вопросами, просадками и сильной структурой ответа.
Быстро подтянуть
4
повторяющихся слабых мест вынесены наверх перед деталями.
Практика
12
связанных вопросов открываются прямо из этапов разбора.
Главные просадки
- Нужно было сразу разложить стороны рынка. Покупатель, продавец и платформа могут выиграть или проиграть по-разному.
- Не хватило конкретных ограничений: не ухудшать честность показов продавцов, качество контакта, жалобы, скрытия объявлений и разнообразие категорий.
- Нужно было точнее отделить прогноз от решения. Прогноз: вероятность контакта, сделки, продажи в срок, жалобы или полезность. Решение: какую цену предложить, какой тег поставить, какое объявление поднять.
- Если учить модель повторять исторические теги или скидки, она научится старой политике, а не эффекту действия.
Этап 1
Метрики покупателя, продавца и платформы
Что спрашивали
- Интервьюер начал со стейкхолдера: какие метрики обсуждать до выбора модели для цены, рекомендации или промо-блока.
- Проверялась способность не свести рынок к одной метрике выручки или кликов.
Что было хорошо
- Кандидат говорил про бизнес-интерес и переход от продуктовой цели к измеримым метрикам.
- Появилось понимание, что метрика на исторических данных не равна итоговой бизнес-метрике.
Где просело
- Нужно было сразу разложить стороны рынка. Покупатель, продавец и платформа могут выиграть или проиграть по-разному.
- Не хватило конкретных ограничений: не ухудшать честность показов продавцов, качество контакта, жалобы, скрытия объявлений и разнообразие категорий.
Сильная структура ответа
- 1Сильнее было бы начать так: “Для покупателя смотрю релевантность, контакт и качество сделки; для продавца - просмотры, контакты, время до продажи и справедливость показов; для платформы - сделки, выручку, удержание и жалобы”.
- 2После этого выбрать основную метрику под конкретное действие и рядом поставить ограничения: честность показов продавцов, жалобы, скрытия, разнообразие, задержка ответа сервиса и перекос в пользу платных или крупных продавцов.
Этап 2
Модель оценивает, продукт выбирает действие
Что спрашивали
- Интервьюер подводил к тому, что выход модели должен быть связан с действием продукта: цена, скидка, тег, место в блоке или порядок объявлений.
- Главная проверка: не считает ли кандидат историческую цену или наличие тега готовой целевой переменной без понимания, почему это действие было выбрано.
Что было хорошо
- Кандидат пытался сформулировать оценку для скидки или ценового действия.
- Было видно, что финальное решение должно влиять на продукт, а не жить отдельной ML-таблицей.
Где просело
- Нужно было точнее отделить прогноз от решения. Прогноз: вероятность контакта, сделки, продажи в срок, жалобы или полезность. Решение: какую цену предложить, какой тег поставить, какое объявление поднять.
- Если учить модель повторять исторические теги или скидки, она научится старой политике, а не эффекту действия.
Сильная структура ответа
- 1Сильнее было бы сказать: “Для каждого допустимого действия оцениваю последствия: контакт, сделку, время до продажи, выручку и риск жалобы. Потом правило выбора принимает действие с ограничениями по честности и бизнес-правилам”.
- 2Для цены это может быть не одна точка, а диапазон “справедливая, низкая, высокая” с уверенностью. Для карусели - оценка полезности показа конкретного объявления в конкретной позиции.
Практика по просадкам
Этап 3
Признаки цены объявления
Что спрашивали
- Интервьюер просил собрать признаки для модели цены: что брать из объявления, продавца, локации, фото и рынка похожих товаров.
- Отдельно уточнялось, зачем нужны seller features и как не смешать качество товара с качеством объявления.
Что было хорошо
- Кандидат называл категории признаков и не ограничивался только текстом объявления.
- В ответе появились продавец, локация и изображения как источники сигнала.
Где просело
- Признаки нужно было разложить по группам и объяснить, что каждый дает. “Location” без объяснения мало помогает: город меняет спрос, конкуренцию, доставку и сравнимые цены.
- Качество фото и качество товара - разные вещи. Размытое фото снижает доверие, но само по себе не доказывает плохое состояние товара.
Сильная структура ответа
- 1Сильнее было бы начать с простого ориентира: медиана или квантили цены похожих объявлений по категории, бренду, модели, состоянию и региону. Это дает проверку здравого смысла до сложной модели.
- 2Дальше добавить группы признаков: объявление, продавец, локальный рынок, спрос и предложение, текст, фото, качество заполнения и свежие похожие объявления, посчитанные только из прошлого.
Этап 4
Проверка на исторических данных без красивой самообманки
Что спрашивали
- После признаков интервьюер спросил про следующий шаг: цель обучения, разбиение данных, простое правило, модель и критерий перехода к продуктовой проверке.
- Затем обсуждалось, как выбрать модель для продукта не только по красивой метрике на исторических данных.
Что было хорошо
- Кандидат дошел до разбиения на обучение и проверку, выбора модели и необходимости сравнивать качество.
- В ответе появилась мысль, что запуск требует учитывать стоимость и скорость модели.
Где просело
- Случайное разбиение по строкам здесь почти наверняка завысит качество: похожие объявления, агрегаты категории и история продавца могут подсмотреть будущее.
- Не хватило четкого определения строки: что является строкой - объявление на момент публикации, изменение цены, показ объявления пользователю или сессия.
Сильная структура ответа
- 1Сильнее было бы определить строку и момент времени: например, объявление в момент публикации. Все признаки считаются на этот момент, без будущих контактов, продаж и цен похожих объявлений.
- 2Разбиение делать по времени, а качество смотреть не только средней абсолютной ошибкой или метрикой ранжирования, но и по категориям, регионам, новым продавцам, дорогим товарам и объявлениям с малой историей.
Этап 5
Новая карусель и нехватка честных исторических меток
Что спрашивали
- Интервьюер коротко, но важно спросил: как на исторических данных измерить точность новой карусели, если такой поверхности раньше не было.
- Это проверка на понимание, что отсутствие показов означает отсутствие прямых меток реакции именно на этот интерфейс и позицию.
Что было хорошо
- Кандидат понял, что у новой поверхности нет готовой истории показов.
Где просело
- Нужно было явно сказать: точная оценка на исторических данных невозможна без предположений. Можно использовать похожие поверхности, ручную разметку, старые логи контактов, но это только приближение.
- Позиция, вид блока и тег меняют поведение пользователя, поэтому старые метки из поиска или другой ленты не переносятся один к одному.
Сильная структура ответа
- 1Сильнее было бы собрать контрольный набор для проверки здравого смысла: для сессий взять исторические позитивные контакты, похожие объявления, жесткие фильтры и ручную разметку релевантности, но не выдавать это за точную оценку будущего интерфейса.
- 2Дальше запускать поэтапно: теневое логирование без влияния на пользователя, маленький A/B, контроль жалоб, честности показов продавцов, задержки ответа и сравнение с вариантом простого ранжирования.
Практика по просадкам
Этап 6
A/B: отделить эффект интерфейса от эффекта модели
Что спрашивали
- Интервьюер спросил про новую карусель или тег Deal of the Day: если метрика выросла, как понять, что помогла модель, а не сам новый интерфейс.
- Это был главный экспериментальный поворот кейса.
Что было хорошо
- Кандидат обсуждал A/B и понимал, что нужно смотреть метрики после клика, а не только сами клики.
Где просело
- Если вариант эксперимента одновременно меняет место на странице, тег и алгоритм, рост нельзя приписать ML-ранжированию.
- Нужно было предложить отдельный вариант, где интерфейс такой же, но ранжирование простое: популярное, случайное среди допустимых или старое правило.
Сильная структура ответа
- 1Сильнее было бы сделать минимум три группы: контроль без новой поверхности, новая поверхность с простым ранжированием, новая поверхность с ML-ранжированием. Разница второй группы с контролем - эффект интерфейса, разница ML с простой группой - вклад модели.
- 2Метрики: контакт, сделка, время до продажи, выручка, жалобы, скрытия, честность показов продавцов, разнообразие категорий и каннибализация других блоков.
Термины
- Marketplace health
- Здоровье рынка: не только выручка, но и баланс спроса и предложения, доверие покупателей, честность показов продавцов, жалобы и качество сделок.
- Action
- Действие продукта: поставить тег, изменить цену, показать объявление в карусели или поднять его в ранжировании. Модель оценивает последствия, но действие выбирает продуктовая политика.
- Leakage
- Утечка будущего в обучение или валидацию. Например, использовать при проверке цены агрегаты похожих объявлений, которые были опубликованы уже после тестового объявления.
- Offline validation
- Проверка модели на исторических данных до запуска. Она полезна как фильтр плохих решений, но не заменяет A/B, потому что новая поверхность меняет поведение пользователей.
- UI effect
- Прирост от самой формы показа: нового блока, яркого тега или позиции на странице. Его нужно отделять от качества ML-ранжирования.
- Latency
- Задержка ответа сервиса. Для маркетплейса это время, за которое модель или ранжирование должны вернуть объявления без заметной паузы в интерфейсе.