Weekend Offer от Яндекс GO

В это воскресение можно попасть на собеседование в Яндекс (и даже сразу на два, если повезёт). Для этого до четверга надо решить два задания на Контесте.

Там понадобится шарить в алгоритмах, поэтому подойдёт тем, кто решает алгоритмы для фана вместо кроссвордов и судоку; или уже месяц не вылезает из LeetCode и щёлкает easy и medium оттуда ))

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

https://yandex.ru/promo/events/fasttrack-taxi-analytics

Я как раз недавно прошёл этот путь (не в рамках Weekend Offer, а просто) и теперь вот датаинженерю в Яндекс GO; поэтому могу ответить на вопросы или рассказать что-то подробнее, если интересно.

почему мне тут нравится:
⁃ есть воля сделать хорошо (выше постил конспект выступления Head of DWH — Феди Лаврентьева)
⁃ есть ресурс на это всё (Федя уже договорился с бизнесом)
⁃ уже влито куча энергии в инфраструктуру и в планах продолжать
⁃ все сущности задокументированы — нет боли неведения
⁃ крутые крутаны за соседними столами (ну или в чате в Слаке / ревью в Гитхабе)

плюс известная атмосфера Яндекса с кучей плюшек.

кароч, GO к нам

Кстати, об алгоритмах — вот Антон Жиянов коротко и чётко описал в чём там суть, зачем вообще понимать сложность какого-то алгоритма.

Там серия из 4 постов, вот первый:
https://news.1rj.ru/str/ohmypy/114

BREAKING: всея отечественного дата сайенса — Валерий Бабушкин — завёл свой канал. Стопудов там будет интересно.

https://news.1rj.ru/str/cryptovalerii/3

П.С.: не могу пройти мимо упоминания «пирамиды» — это та самая пирамида, на которую я опирался, когда приходил в инжиниринг данных ^_^
https://news.1rj.ru/str/data_days/159

Датаи́зм (data-ism) — философская парадигма, провозглашающая, что Вселенная состоит из потоков данных и что ценность всякого явления или сущности определяется их вкладом в обработку данных.

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

https://ru.wikipedia.org/wiki/Датаизм

===

Узнал о новой «религии» (?). Не знаю пока, что с этим делать, но лучше быть в курсе 🙂

Увидел такую визуализацию и залип (спасибо каналу Data-comics)

Как автор так удачно разместил все горы в аккуратные треугольники? Какое красивое естественное распределение получается: 1 уровень — одна гора (Фуджи); 2 уровень — три; и дальше по нарастающей.

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

И, кажется, всё равно пришлось немного округлить высоту каждой горы до какого-то значения. А потом вспомнил, что это карта 1886 года и вряд ли они тогда знали, что высота Фуджи именно 3 776 метра. Так что автору скорее всего и округлять не пришлось :-)

Но на этом остановиться я не мог и сделал чарт в Гугл-таблицах (да простят меня коллеги из BI), чтобы узнать как на самом деле выглядит распределение высот гор в Японии.

Взял список гор с высотами (спасибо Википедии и стандартной формуле IMPORTHTML), округлил значения до 100 и в сводной таблице посчитал количество гор для каждого такого «бакета».

Видно, что количество гор логично увеличивается с уменьшением высоты. Так же видно и «пропуски» по некоторым высотам, которые автор исходной визуализации так мастерски спрятал.

Гугл-таблица с данными, вдруг вам тоже интересно

Подглядывать через плечо к программистам

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

https://news.1rj.ru/str/data_days/46

Это получился такой прикладной уровень

Чем дальше подсматриваю, тем более высокоуровневые вещи открываются.

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

При разработке ДВХ точно такие же проблемы: классно и удобно пересчитывать с нуля все сущности при каждом обновлении. Потом слоёв становится не три, а восемь и количество зависимостей каждой сущности возрастает соответсвенно. Поменял в начале одно поле — протягивай его дальше по всем слоям.

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

Нравится слушать ребят из Moscow Python подкаста ↓

тимлид и ответственность

Плоская структура без руководителей и менеджеров хорошо работает в небольших системах. При росте системы растёт и сложность; и появляется свой «налог» — должен кто-то отдельный заниматься процессами и рулить этим хаосом.

Правильный тимлид — это не просто прораб, который утром раскидал задачки рабочим, а потом весь день покуривает сигару в тенёчке.

На самом деле это малоприятная работа:
⁃ читать чужой код (бр-р-р!) и делать ревью,
⁃ грумить бэклог следить за задачами: непонятные уточнять, переписывать, дополнять контекст, вставлять скриншоты
⁃ следить за показателями тайм-ту-маркет: чтобы новые фичи пилились за разумное время
⁃ организовывать, короче

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

Слушать в Overcast и iTunes

#подкаст

Внимание, опрос!

Не так давно попал в DWH Яндекс GO: тут ребята идут в data mesh со своим гибридом Anchor Modeling и Data Vault. Каждый день крутятся несколько тысяч ЕТЛ-процессов, обновляя сколько-то там сущностей. А в конце всего этого пайплайна находится отдел Ромы Бунина (@revealthedata) со своей космической BI-системой и стайл-гайдами.

Кажется, можно было бы больше рассказывать про разную местную внутрянку. Что думаете? Что было бы интересно узнать?

Про процесс собеседований

Так, отлично! Опрос ↑ показал, что можно писать про Яндекс. Я то я переживал, что будет неинтересно 🙂

Не знаю с чего начать — пожалуй, начну с начала, т.е. с собеседований

Общий порядок для инженера данных выглядел так:
0. Знакомство и скрининговое интервью с рекрутером
1. Секция про SQL + программирование
2. Секция про SQL + программирование
3. Секция про алгоритмы
4. Знакомство с командами (1-3)
5. Оффер

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

0. Рекрутер

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

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

Рекрутер — это связующее звено между кандидатом и компанией. Он назначает следующие встречи, отвечает на вопросы по статусу и любые другие. У меня получился очень комфортный процесс: если вопрос был на их стороне, то рекрутер всегда держал связь и ориентировал, когда ждать ответа (Никита, привет!).


Собеседования по коду

Дальше были две секции по SQL и программированию:
- сначала простая задача на джойн (связать две таблицы без потерь),
- потом задача на программирование (отсортировать чётные/нечётные, рассадить зрителей в кинотеатре)
- плюс в конце общий вопрос: у меня было про возрастание долей (типа парадокса Симпсона) и верхнеуровнево прикинуть структуру рекламных доходов РСЯ.


Собеседование на алгоритмы

Третьим собеседованием были АЛГОРИТМЫ! Тут обычно дают две-три задачи. Длительность ограничена 90 минутами, а задачи подбираются так, что можно было бы их решить за 10-30 минут. То есть гуру решают три задачи и ещё остаётся время на поговорить. А кто-то останавливается на первой.


Финалы

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

После этого надо выбрать одну команду. То есть команды не могут конкурировать между собой за кандидата и перебивать его аферами. Если команда проявила взаимный интерес, то переходим на следующий этап — подготовку оффера.


Оффер

Оффер будет только один — от команды, которую ты выбрал. Оффер готовят вообще другие ребята: не те, которые тебя собесили, не твой руководитель и даже не рекрутер. Специальные математики в недрах Яндекса готовят предложение о работе по единым стандартам.

Когда оффер готов, рекрутер назначает (по идее) уже последнюю встречу на 20-30 минут. На ней он последовательно перечисляет все плюшки, которые компания готова предложить кандидату: деньги, дмс, условия работы и прочие ништяки.

Как вычисляется оклад: по итогам всех собесов получается оценка кандидата на какой-то грейд. Плюс реководитель отдела тоже должен подтвердить, что он готов взять кандидата на такой грейд. У каждого грейда есть фиксированная вилка окладов.

Если оффер принят, согласуешь дату выхода и приходишь. Дальше получаешь ноут, доступы, проходишь онбординг и начинаешь перформить 🙂


----
Получилось коротко, но обо всех этапах. Если что-то забыл, пишите в комментах или спрашивайте в личку @sashamikhailov

Инженеры данных и аналитики

В небольших компаниях инженеры данных как человек-пароход: сам данные достал из источника, сам спроектировал слои и сущности в двх, сам сделал графики и положил их на дашборды (может, это и называют Analytics Engineer?)

То есть тут роль меньше человека: один человек включает в себя несколько ролей.

Чем больше компания, тем мельче роль: отдельные люди занимаются экстрактом, другие — отвечают за платформу обработки данных и инфраструктуру хранилища.

Есть выделенная роль аналитика (в Яндексе их называют «партнёры по данным») — они разговаривают с бизнесом, изучают предметную область и отвечают за качество и консистентность данных. Это к ним потом приходят с вопросами «а как мне сджойнить водителей с географией?» или «где мне найти суммы заказов по пешим курьерам без НДС?»

И отдельно работают инженеры данных. На вход им подаётся уже довольно детализированная задача: откуда что достать, как назвать и куда положить; как же удобно работать, когда на новую пачку данных у тебя уже есть готовая ER-диаграмма связей!

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

Ну и где-то дальше по конвейеру сидят мастера BI, готовые из сырых данных делать полезную красоту.


----
интересно, а как у вас? чем обычно занимается инженер данных? а аналитики?

DWH Яндекс GO нанимает…

… всех 🙂

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

⁃ можно в зрелые Такси или Маркет
⁃ можно в молодые и дерзкие Лавку или Драйв
⁃ а можно в девственный «стартап» — Доставку (← я тут)

А над этим всем есть ещё отделы по инфраструктуре — пилят hNhM (свой аналог Anchor Modelin / Data Vault) и помогают с проектированием; плюс отдельные ребята, которые занимаются платформой — свой аналог распределённого ETL-оркестратора на основе Luigi.

Все вместе мы пробуем в Data Mesh (пока вроде получается).

И везде есть свободные места, все нанимают:
⁃ Инженеров данных (хе-хей!)
⁃ ETL-разработчиков (это лайт-версия инженеров по данным, насколько я понял)
⁃ Партнёров по данным ( ~ аналитики данных )
⁃ Системных аналитиков (общаться с бизнесом, думать СИСТЕМНО)

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

https://go.yandex/ru_ru/promo/join-dmp-team

И, конечно, я готов рассказать подробно, ответить на вопросы в комментах или личке @sashamikhailov; либо связать напрямую с нужным лидом или закинуть резюме напрямую эйчару.

В опросе лидируют BI-разработчики, что в принципе логично 🙂

Рассказываю, как это было у нас: собрались, значит, все отделы вместе, чтобы рассказать кто что делает, какие есть успехи, в чём возникают проблемы и с чем надо помочь.


Выходят продакты
… делаем приложение удобным для заказа, проводим кастдевы, ездим в поля, а ещё активно считаем ретеншен и хотели бы получать валидные данные из источников в ДВХ!


Выходят маркетинговые аналитики
… значит, у нас тут перформанс, бюджеты, сегментация. Хотим, чтобы все расходы были в одном месте и подтягивались автоматически, чтобы мы могли сравнить их с выручкой — рассчитываем здесь на помощь ДВХ!


Выходит отдел b2b продаж
… в общем, у нас тут много продажников, у каждого есть клиенты в работе, они идут по воронке. А ещё есть несколько источников с ручным импортом, которые часто ломаются.
Вот бы ДВХ нам всё настроил по красоте и вывел данные по клиентам и менеджерам на единый дашборд!


Выходят BI-разработчики
… короче, есть куча дашбордов, часть метрик между ними повторяется, но почему-то значения у них различаются. Было бы классно, если бы ДВХ сделал так, чтобы одни и те же метрики на разных дашбордах показывали одинаковые значения 🙂


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

🧪 ЭКСПЕРИМЕНТ! 👨‍🔬 пятничная флудилка

↓ здесь можно передать привет коллегам, маме или коту (если они, конечно, читают))

или скинуть последний мем…
или поделиться интересной ссылкой…
или спросить за жизнь…

ну или просто поздороваться с товарищами-читателями 👋

Head of ML в Blockchain.com готовит ЕТЛ-инфраструктуру. Интересно почитать рассуждения со стороны МЛ плюс тред на 100+ комментов.

А ещё там вакансии для инженеров данных с релокейтом в Лондон

Одной из задач, стоящих перед мной в Blockchain.com, является подготовка инфраструктуры к росту объемов хранимых и используемых данных, деплоя моделей машинного обучения, работающих как в риалтайме так и по батчам и инфраструктуры для финансовых данных.

Будь я в России, то наверное пошел бы по проторённой дорожке: Hadoop, Postgres, Spark, Clickhouse,Kafka

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

В классической истории есть Data Lake где хранится всякое и есть DWH где хранится всякое обработанное, вытащенное и очищенное из Data Lake

Что предлагает Data Lakehouse?
В существующих дата лейках, чтобы использовать какое-то BI или ML приложение, нужно под них налаживать ETL
LakeHouse позволяет всем приложениям (ML, BI, ...) иметь постоянный доступ ко всем данным без отладки ETL каждый раз заного, что гарантирует консистентные данные, собранные из различных источников в даталейке.

ETL встроен в мета слой. Без data management/governance слоя каждая команда к источникам подрубается своими etl процессами и создает свои датамарты, затем непонятно как их поддерживает что создает проблемы с переиспользованием и дупликацией.

Вторая часть приятных вещей - транзакционность, для этого вводится delta tables/files/transaction log/engine/storage layer

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


Из того что я видел, Lakehouse предлагает Google (на Bigquery к которому я подозрительно отношусь), Databricks и AWS
С ребятами из Датабрикс мне советовали встретиться давно, тем более что основатели Датабрикс - создатели Spark. В итоге они сами на меня вышли и на этой неделе я планирую провести с ними уже вторую встречу и послушать их Solution Architect

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

Кстати мне сейчас нужны дата инженеры, заниматься этим и многим другим. RVожно как фул ремоут, так и с релокейтом в Лондоне. Есть офисы в Майами и Буэнос Айресе. Платим мы примерно как ФБ, если говорить про зарплату про и бонус, смотри #BigTechLevelsCompensation в дополнение есть криптобонус и опционы, которых мы даем даже чуть больше ФБ в абсолютах и это при текущей оценке! Можно податься здесь

чувствую себя тупым

Почему? Вижу два фактора:
1. В Яндексе в принципе всё непросто: как в силу технологичности, так и из-за большого размера.
2. Почти все инструменты — внутренние, то есть нельзя просто загуглить ошибку из логов.

Раньше же было как: вот есть, например, Airflow и Docker. В интернете уже все проблемы давно порешали и на всё есть детальные инструкции (в основном на английском, правда).

Тут так не получается. И выходит так, что как минимум раз в день Саша «выходит на середину комнаты» и публично признаётся в своей технической несостоятельности, задавая «глупые» вопросы.

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

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

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

Вроде у стартапов есть такой подход — fail fast. Надо быстро-быстро пробовать новое и искать работающие варианты: пускай на один работающий будет девять неудач, но чем быстрее эти девять случатся, тем быстрее найдём тот один работающий вариант.

То же самое и с вопросами: лучше быстрее спросить и узнать как надо, чем сидеть с потенциально-неправильной информацией (и принимать на её основе другие решения!)

Чувствую себя тупым и, кажется, это нормально.

машинное обучение: финальное решение состоит настолько же из кода, сколько из данных

Андрей Татаринов — ко-фаундер Epoch8 и Agima.ai — пришёл в гости к Moscow Python рассказать чем отличается «хайповый МЛ из рекламы» и реальные задачи.

За время работы в Epoch8 я больше всего любил встречи, где участвовал Андрей. У него всегда было чёткое видение проблем и точные формулировки для любых тезисов: одно удовольствие слушать (и потом делать, хе-хе)

⌘⌘⌘

В отличие от конкурсов на Kaggle, в реальном мире задача сформулирована крайне куце: найти все склады на спутниковой карте Москвы. А все данные — это два скриншота таких складов.

Чаще всего данные нужно откуда-то достать, а потом ещё и разметить. Разметка — дорогая процедура; например, чтобы опознать и разметить 2000 деталей на ОДНОЙ фотографии с рассыпанным Лего, может уйти неделя чистого времени одного специалиста.

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

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

Подкаст в Apple Podcasts и Overcast

#подкаст