Привет! Меня зовут Савва Степурин, я старший разработчик в группе рекомендательных продуктов в Фантехе Яндекса. Сегодня расскажу вам про то, как мы сделали «Незнакомое» для Моей волны — специальный режим для активного поиска музыкальных открытий.

«Незнакомое» позволяет вам получать от Моей волны те треки, которые вы ещё не слушали (возможно, даже не знаете про их существование), но которые с большой долей вероятности могут попасть в ваши музыкальные предпочтения. Если Моя волна в чистом виде — это идеальный баланс между любимыми композициями и чем-то новым, то «Незнакомое» помогает выйти из музыкального информационного пузыря и послушать новые треки. 

Под катом — техническая эволюция «Незнакомого» от фильтра до отдельного продукта, описание новой модели ранжирования и многое другое.

В ранние годы развития компьютеров программисты могли лишь мечтать о портируемости. Все программы писались непосредственно в машинном коде для каждой компьютерной архитектуры, на которой они должны были работать. Языки ассемблера с мнемоническими именами каждой команды CPU и другие удобства сильно упростили жизнь программистов, но программы по-прежнему были привязаны к архитектуре. Тогда ещё не изобрели операционных систем, поэтому программа не только управляла всей компьютерной системой, но и должна была инициализировать всю периферию, а также управлять ею. На самом деле, такие низкоуровневые программы реализовывали драйверы для каждого используемого ими устройства. И каждый раз, когда программу нужно было перенести на оборудование с другой архитектурой, она в буквальном смысле переписывалась с учётом различий архитектуры набора команд CPU, структуры памяти и так далее.

Именно так произошло с Unix, который изначально был написан Кеном Томпсоном на языке ассемблера более пятидесяти лет назад. Первые версии Unix писались для платформы PDP-7, а для портирования его на PDP-11 нужно было переписывать код. Когда Дэннис Ритчи создал язык программирования C, и вместе с Томпсоном они переписали на нём основную часть кода Unix, внезапно оказалась возможной портируемость ПО. Тому были две главные причины. Во-первых, код, написанный на языке высокого уровня, не зависит от платформы, потому что компиляторы транслируют его в язык ассемблера целевой архитектуры. Это ещё важнее для целевых платформ на основе процессоров RISC, так как они требуют написания гораздо большего количества ассемблерных команд, чем процессоры CISC. Даже при портировании Unix на другую платформу основная сложность заключалась лишь в адаптации зависящих от архитектуры частей кода. С другой стороны, сама операционная система абстрагирует все особенности оборудования от пользовательской программы.

Программистам не нужно реализовывать многозадачность, управление памятью и драйверы для используемых ими устройств, потому что всё это часть ядра ОС и работает в адресном пространстве ядра. Пользовательские программы работают в пользовательском адресном пространстве и получают доступ ко всем предоставляемым ОС функциям при помощи интерфейса системных вызовов. В ОС реального времени, например, в Zephyr OS ситуация немного отличается, но принцип изоляции и защиты памяти для пользовательских программ сохраняется. Это приводит к двум выводам:

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

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

Привет, Habr! На связи отдел аналитики данных X5 Tech.

Сегодня мы поговорим об очень интересном разделе прикладной математики — оптимизации.

Как в Х5 запускали программы лояльности

В предыдущей статье мы поговорили про роль Data Engineer в Х5, какие задачи он решает и с каким технологическим стеком работает. Рассмотрели структуру собеседования, основные направления, по которым мы оцениваем кандидатов, и подробно разобрали базовые требования, предъявляемые нами к уровню владения Python.

В данной статье мы разберём требования к ключевым для Data Engineer в X5 навыкам: распределённые системы и вычисления на Hadoop / Spark, а также SQL и проектирование схемы данных.

Привет, Хабр! Авторы этой статьи работают в команде больших данных в Х5 Tech. Мы решили объединить в статье наш личный опыт отбора кандидатов на позицию начинающего аналитика и дать несколько рекомендаций по составлению качественного резюме. Надеемся, что они окажутся полезными для тех, кто ищет работу своей мечты, и будет совсем здорово, если мы в итоге встретимся в X5 Tech.

Меня зовут Антон Денисов, я руководитель аналитиков больших данных в X5 Tech. В этой статье расскажу, с какими сложностями сталкиваются нанимающие менеджеры в сфере Data Science в условиях интенсивного процесса найма сотрудников, а также продемонстрирую, к какому виду мы привели процесс собеседований и найма аналитиков больших данных в X5 Tech.

Привет, Хабр! Это Андрей Смирнов. Вы можете знать меня по выступлениям на конференциях или как ведущего подкаста «Frontend Weekend» и «600k в секунду». Я руковожу большим управлением клиентской разработки в X5Tech — это почти 170 фронтендеров и мобильных разработчиков. Всего провёл более 1000 технических и менеджерских собеседований с фронтендерами и руководителями разработчиков. Научился этому не сразу, сначала отстроил процесс собеседований на небольшом отделе, а потом масштабировал его на департаменты.

В статье поделюсь идеями и расскажу, как проводить собеседования, чтобы оффер принимали как можно больше кандидатов. 

Для интервьюеров собрал примеры из практики — как строить собеседования, тратя меньше ресурсов на найм и улучшая конверсию. 

Если же вы — кандидат, узнаете как стать заметнее и увеличить шансы на оффер.

Привет, Хабр! В этой статье мы – Святослав Орешин и Александр Сахнов – попытались  разобрать достаточно специфичную для классического Data Science и критически важную для бизнеса тему – модельный риск или risk management для машинного обучения. 

Под катом говорим о том, как можно сделать машинное обучение в компании более эффективным, какие бывают риски у ML моделей и как на них реагировать, а также делимся своим опытом, как мы построили систему по модельному риску в X5 Tech – компании с сотнями ML моделей в production.

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

Привет, Хабр! Меня зовут Яна и я работаю Data Quality в департаменте развития аналитики "Цепочки поставок и поддерживающие функции" X5 Tech. В этой статье мы с моей коллегой Наташей, менеджером по качеству данных, решили рассказать о мониторинге качества данных большинства отчётов нашей команды.

На первый взгляд может показаться, что проверять таблицы – задача рутинная и однотипная, но это не так, ведь все данные имеют свои особенности, а значит и проверки для них зачастую создаются уникальные. Статья, как нам кажется, будет полезна тем, кто интересуется качеством данных, ищет подходы к мониторингу или хочет больше узнать о работе DQ в целом.

Привет, Хабр! Представляю вашему вниманию перевод моей статьи "Understanding the Customer Lifetime Value with Data Science".

Взаимоотношения с клиентами важны для каждой компании и играют ключевую роль в росте бизнеса. Одна из наиболее важных метрик в этой сфере — пожизненная ценность клиента (customer lifetime value, далее LTV) — предсказание чистого дохода, связанного со всеми будущими отношениями с клиентом. Чем дольше клиенты продолжают пользоваться продуктами компании, увеличивая прибыль, тем выше их LTV.

Есть много маркетинговых статей, о том, как важны LTV и сегментирование клиентов. Но, как Data Scientist’а, меня больше интересуют формулы и я хочу понимать, как модель на самом деле работает. Как предсказать LTV, используя только 3 признака? В этом посте я покажу некоторые модели, которые используются для маркетинговой сегментации клиентов и объясню математику, на которой они основаны. Здесь будет много формул, но не переживайте: все уже готово в библиотеках Python. Цель этого блога показать, как математика делает всю работу.

Beta-geometric/negative binomial модель для определения вероятности, что клиент “жив”

Рассмотрим такой пример [из онлайн-сервиса для заказа поездок (такси) по городу]: пользователь зарегистрировался 1 месяц назад, сделал 4 поездки и последняя поездка состоялась 20 дней назад. Основываясь только на этих данных, эта модель может предсказать вероятность, что клиент будет активен в течение определенного периода времени (как показано на графике), а также число транзакций в будущем (которое является основой для понимания ценности клиента в течение всей его “жизни” — взаимоотношений клиента и компании).

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

Рассказываем про любимую метрику маркетологов.

Наши аналитики разработали комплексную формулу расчёта LTV, которая учитывает не только специфику работы каршеринга, но также все доходы и затраты сервиса. В статье расскажу, как мы считаем пожизненную ценность клиента и как с помощью этих данных улучшаем свой сервис.

Привет! Меня зовут Сергей, я ведущий системный администратор службы эксплуатации в QIWI. Так сложилось, что в нашей компании довольно большое число сотрудников, и часть из них работает в специфических системах.

Например, есть люди, которые в своей работе часто взаимодействуют с бухгалтерией, финансами, единой биометрической системой, Госуслугами, Контуром и прочим добром. Причём от того, насколько комфортно им это делать, на самом деле зависит выполнение их рабочих обязанностей. А вы знаете, что сейчас для многих (если не для большинства) окологосударственных сайтов нужны сертификаты. И чтобы сделать из дефолтного Chrome или Firefox подходящий инструмент для такого сотрудника, приходилось немного костылить — обвешиваться плагинами, настраивать их, потом по отдельности помогать каждому человеку, если что-то вдруг тупило. В общем, так себе история.

Но работать-то надо. И желательно — без заморочек, в централизованном формате «Включил — работаешь». Поэтому мы решили, что хватит это терпеть, и попробовали Яндекс Браузер для организаций.

Под катом я расскажу, что умеет Браузер на сегодня, как именно мы его внедряли, поделюсь нашим скриптом для быстрой миграции (вдруг вам тоже пригодится) и впечатлениями от работы. Вишенкой — о работе Браузера в закрытом контуре без внешней телеметрии.

Что такое эмбеддинги?

Привет! Мы в QIWI любим проводить хакатоны. Во-первых, это просто интересно и помогает разгрузить голову. Во-вторых, зачастую помогает решить какие-то внутренние проблемы компании, от организации тех или иных процессов, которые давно хотелось починить.

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

Хакатонам в QIWI более 10 лет. Самый первый хакатон помнят только олды, которые давно в компании. Конечно, времена были разные, когда-то хакатонов проводили больше, а когда-то — меньше, но если говорить о каких-то усредненных числах, то в год мы делаем примерно два хакатона.

На каждый заявляется примерно 10-15 команд. Иногда доходило и до 20. Но одно дело — заявиться, другое — пройти отборочный этап и дойти до непосредственного участия.

Сами хакатоны у нас бывают двух видов:

Эффективность и успех работы команды напрямую зависит не только от профессионализма участников, но и от способа организации рабочих процессов. Ведь если у вас есть самые лучшие спецы в отрасли, но процессы при этом хромают на обе ноги, то сделать что-то значимое будет так же сложно, как если бы спецов не было вообще.

В этом посте мы поговорим о том, как формат сообществ (чаптеров) помогает нам в работе. Для этого мы подробно побеседовали с Михаилом Благовым, лидером чаптера инженеров данных. Еще нам помогали Николай Безносов (чаптер Data Science) и Артём Смирнов (Data Analytics).

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

Всем привет. Меня зовут Артур. Готовясь к выступлению на внутреннем митапе по теме особенности алгоритмов у CatBoost и LightGBM, я понял, что не смог найти единого места, где были бы понятным языком рассказаны основные особенности того, что алгоритмически работает под капотом у CatBoost и LightGBM. Причём не формальные записи алгоритмов на псевдокоде, а понятные пошаговые инструкции. Так появилась эта статья.