😱 забанили в LinkedIn

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

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

однажды, зайдя в линкедин, я увидел просьбу подтвердить свою личность. Прислав им в форму скан паспорта (О_о), они обещали ответить в ближайшее время. Спустя сколько-то дней пришло письмо, что «ваш аккаунт заблокирован по причине нарушений правил»

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

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

⌘⌘⌘

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

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

тогда я попробовал зарегать следующий. Уже с новым телефоном. Бан на следующий день. Новый акк с рабочей почты — тоже бан. Когда появился шведская симка я сделал ещё одну попытку, но результат остался тем же.

⌘⌘⌘

понятно, что по ту стороны коммерческая организация, которая вправе придумывать любые правила пользования своими услугами; и, регистрируясь, мы все жмём галочку и «подписываем» этот контракт.

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

как бы теперь Кларна не оказалась моим последним местом работы >_>

🍅 middle →→→ senior

https://seattledataguy.substack.com/p/how-to-grow-from-mid-level-to-senior

y Seattle Data Guy гостевой пост про то с какой стороны подходить к прыжку от мидла к синьору. Резонирует с тем что я вижу вокруг и как представляю свой путь в сторону помидорства


⌘⌘⌘

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

✓ непрекращающееся развитие — всегда готов научиться чему-то новому и рассказать об интересном

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

→ направления на подумать: вдумчивые и развивающие код-ревью, парное программирование и другие сессии обмена опытом; улучшение процесса онбординга


⌘⌘⌘

работать над действительно важными для компании штуками: ведь неважно сколько кафок с куберами задействовано, если пользователей — ноль

→ направления на подумать: интересоваться целями компании, смотреть вширь от проекта: апстрим и даунстрим


⌘⌘⌘

овнершип и ответственность. Увидел проблему — взял и решил. Не скидывать ответственность на других.

→ направления на подумать: оставлять поляну после себя чуть лучше, чем была до; планомерная работа над документацией проекта; помогаешь преодолевать блоки у задачи


⌘⌘⌘

да! и не забыть рассказать тимлиду про свои хотелки, составить и провалидировать конкретный план с явными сроками; а после — не забыть задокументировать результаты своей бурной деятельность

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

😱 етл-таски в очереди по ~23 часа

в Яндекс Го была довольно стандартная (да ведь?) дата-архитектура: были дата-лейк на YT и DWH на Greenplum. Вначале все данные попадали в лейк, там как-то предобрабатывалось и потом можно было залить в GP для всяких там джойнов и прочих оптимальных доступов.

Два наблюдения:

- между YT и GP случались заторы — данные туда-сюда заливались немаленькие и задача перекладывания джейсонов между базами довольно нетривиальная

- одного не самого инженера могло быть достаточно, чтобы сделать GP плохо ( :wave: ) — как-то ко мне пришёл наш ДБА и попросил засунуть в остановить свой запрос и немного его оптимизировать перед следующим запуском

⌘⌘⌘


Проблема, видимо, распространённая, так как в Кларне схожая картина: есть лейк на S3/Athena и DWH в Redshift. По умолчанию все данные заливаются в Редшифт и там уже обрабатываются.

Дата платформа хотела как лучше и сделала удобный фреймоврк по клепанию Airflow-тасков: нужно всего лишь написать sql-файлики и добавить их в yaml по нужной форме. Вуаля! и ваш даг уже задеплоен Дженкинсом в коммунальный Airflow.

Фреймворк получися удобным и всё больше дата-инженеров и аналитиков стали добавлять свои тасочки. В начале задержек не было, потом очередь стала больше и свободные слоты в пуле Редшифта заполнились.

Начались очереди на запуск тасков — квадратик таска в Airflow никак не хочет становиться ярко-зелёным, хотя ДАГ запущен.

Задержки в очереди всё росли и росли; и к текущему моменту нельзя с точностью сказать когда запуститься твой таск. При кроне в 7 утра он может начать работать в 10, 18 или даже завтра! О новый дивный мир!

⌘⌘⌘


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

Но, видимо, в какой-то момент что-то пошло не так. Коммунальное и доступное привело к ситуациям, когда дата-саентист жалуется в поддержке, что его запрос выдаёт ошибку. Начинают разбираться и оказывается что он пытается скопировать к себе во временную таблицу все заказы за пять лет — и не просто инкрементально, а через drop-create каждый раз!

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

⌘⌘⌘


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

и сейчас всеми силами пытаются исправить это бутылочное горлышко в виде Редшифта и перевести таски на Афину или Спарк с выделенным компьютом.

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

👷 решения из реального мира

один из источников данных для нашей команды — внешние API. Каждый день мы запрашиваем новые данные и иногда пере-запрашиваем исторические.

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

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

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

… но лямдбу-то надо ещё написать, плюс она будет сама по себе отжирать из тех же лимитов на запросы. А потом всё это поддерживать…

тут выходит менеджер и предлагает просто написать вежливое письмо с просьбой сбросить лимиты.

и представляете — сработало! сбросили лимит ещё и подняли порог на следующий месяц!

получается, вместо того, чтобы писать код и приносить сложность в систему, достаточно было «просто спросить»

🙅 no more* AI

* вольный перефраз оригинального заголовка
https://ludic.mataroa.blog/blog/i-will-fucking-piledrive-you-if-you-mention-ai-again/

коллега скинул отрезвляющую и фомо-утоляющую статейку (спасибо, Игорь!)

ключевая мысль статьи — «вам не нужен AI только если вы не ресёрсч лаборатория» — звучит очень свежей посреди этого аи-хайпа вокруг


⌘⌘⌘

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

ведь по факту получается, что вы тащите в свой прод экспериментальную (!) технологию с недетерменированным выводом (!!), в которой у вас нет экспертизы (!!!) и вы не умеете её разворачивать и поддерживать (!!!!)

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

слепое использование ко-пайлота в компании не повысит уровень кода (только его количество, хе-хе)


⌘⌘⌘

отдельно хочется отметить авторский слог, приправленный австралийскими реалиями:

I learned the wisdom of our ancient forebearers. You can hear it too, on freezing nights under the pale moon, when the fire burns low and the trees loom like hands of sinister ghosts all around you - when the wind cuts through the howling of what you hope is a wolf and hair stands on end, you can strain your ears and barely make out:

"Just Use Postgres, You Nerd. You Dweeb."

и вот перевод на русский с заглавной иллюстрацией важного технического термина из оригинального заголовка — piledrive

https://habr.com/ru/articles/823584/

🔍 Data Observability

в Кларне наша команда отвечает за мониторинг монетизации партнёрского трафика. Данные получаем от affiliate networks (на русский вики предлагает перевод как «сеть партнёрских программ»). Сети передают данные по API (в основном).

казалось бы, тривиальная задача — взять данные из АПИ и положить их в базу. В целом так! но есть ньюанс >_>

когда команда начиналась, была одна сеть. Потом добавилась ещё пара. Через какое-то время клиенты начали просить добавить «ещё одну». Спустя несколько лет мы имеем 20+ сетей, к каждой свой коннектор и бегущие джобы.

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

⌘⌘⌘

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

так жить нельзя, подумал я, и из готовых блоков (Airflow + Datadog) наваял сбор метрик по свежести данных в разрезе сетей. Настроил алерты в Датадоге по порогам. Для наглядности там же в Датадоге вывел на деше значения метрик по каждой сети в динамике (с конфигурацией сразу в Terraform).

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

как говорят коллеги, теперь это дешик, с которого начинается утро (по крайней мере для дежурного) — на деше сразу видны тренды, если с какой-то из сетей неполадки (там где не помогли штатные ретраи)

привнёс Data Observability, получается ☝️

⌘⌘⌘

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

и отдельно видно сети, которые мы начали переводить с ежедневного крона на каждый час — чёткие гребешки стали почти плоскими равнинами

⚾ Andy Pavlo

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

имя Andy Pavlo у меня прочно ассоциируется с базами данных: Andy = databases, databases = Andy

у него есть открытый каталог всех баз данных, где уже есть ссылки на 998 (!) штук
https://dbdb.io/

ещё у него есть был стартап, который помогает тюнить клиентские базы данных с помощью мл: моделька на основе метаданных подкручивает настройки вашего постгреса в цикле с обратной связью. сами данные она не видит.
https://ottertune.com/

и, видимо, для души (и будущих клиентов и сотрудников), он ведёт курс по базам данных в университете CMU

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

вот записи с последнего потока — 2024 год

🍎 Andy Pavlo & Amazon Redshift

а теперь к деталям: в Кларне — AWS, поэтому хранилище тут на Redshift. для знакомства с технологией посмотрел соответствующую серию из курса:
https://youtu.be/T9-MM8oHzsM

⌘⌘⌘

в нулевых было несколько проектов по параллелизации Постгреса и к 2010 оставался только один, который не купили.

В 2010 Амазон решила порядочно сэкономить: вместо покупки целого стартапа, они просто в него инвестировали. Это позволило ей получить лицензию на сам код.

→ в 2013 выходит Redshift как продукт

→ в 2016 запускается Athena — доступ через SQL к данным на S3 (типа как Hive, да?)

→ в 2017 добавляется Spectrum — Redshift может напрямую читать данные с S3 без предварительного инджеста данных в свою файловую систему

⌘⌘⌘

ещё Энди высказывает мнение, что Snowflake был «лучше на старте», но у AWS есть привычка измерять всё на свете и на основе данных постоянно улучшать продукт.

по оценке Энди Redshift приносит AWS «миллиарды»; хотя открытых данных нет, но Энди делает оценки исходя из общего профита и примерной доли. Неплохой профит за небольшую инвестицию в 2010-м!

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

🛠️ Musk Engineering Algorithm

читаю биографию Илона Маска, нахожу любопытным его подход

Илона часто сравнивают со Стивом Джобсом:
основатели культовых компаний, визионеры-провидцы, дотошные менеджеры, и оба в жизни что называется asshole

в жизни Джобса был период, когда он управлял двумя компаниями одновременно: Apple и Pixar. Днём накручивал хвосты дизайнерам в Купертино, а после мчал на встречи с командой в Пиксаре. Есть версия, что именно этот период подкосил его здоровье, что в итоге способствовало развитию рака.

не умалая достижений Джобса, Маск — это какой-то следующий уровень: управлять не двумя, а уже шестью семью компаниями одновременно. SpaceX, Tesla, Solar Roof, Neuralink, StarLink, Boring Company, а теперь ещё и Twitter с xAI.

⌘⌘⌘

ниже «алгоритм», опробованный на заводах SpaceX и Tesla, а затем и на следующих компаниях

× SpaceX в составе 500 инженеров смогли запустить свою первую ракету в космос. Счищая наросшие за десятилетия требования, о назначении которых уже никто не помнил, они смогли добиться снижения стоимости полезной массы и привести компанию к прибыльности (и единственной частной космической компании).

× Tesla должна была выйти на сборку 5000 машин в месяц, чтобы экономика вышла в плюс. Через последовательное применение алгоритма к каждому этапу производства Маск смог за несколько месяцев поднять почти в три раза (1800 → 5000), достигнув целевых показателей.

× тот же подход использовали в StarLink, когда первый проект спутника выкинули за негодностью и переделали с нуля: без лишних деталей и упрощённой конструкцией. На 2022 год StarLink была единственная в своём роде компания, предоставляющая «космический» интернет.

⌘⌘⌘

1. ставьте под сомнение каждое требование. Любое требование должно сопровождаться именем человека, который его выдвинул. Никогда не принимайте требование от «отдела»: например, «юридического отдела» или «отдела безопасности»; только от реального человека. Затем вы должны подвергнуть его сомнению, независимо от того, насколько умён автор. Требования от умных людей наиболее опасны, потому что их реже подвергают сомнению. Подход обязателен, даже если требование исходило от меня [Маска]; в этом случае постарайтесь сделать требование менее тупым.

2. удалите любую часть или процесс, который можете. возможно, позже вам придется вернуть их обратно. На самом деле, если потом не придется вернуть хотя бы 10% — значит, вы удалили недостаточно.

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

4. ускоряйте цикл — каждый процесс можно ускорить. Но делайте это только после того, как выполните первые три шага. На заводе Tesla я [Маск] по ошибке тратил много времени на ускорение процессов, которые, как я позже понял, нужно было удалить.

5. автоматизируйте; но только в последнюю очередь. Большая ошибка в Неваде и Фремонте заключалась в том, что я [Маск] начал с попытки автоматизировать каждый шаг. Но нам следовало бы подождать, пока все требования не будут поставлены под сомнение, части и процессы не будут удалены, и пока все ошибки не будут устранены.

⌘⌘⌘

алгоритм скопировал из поста DHH, где он тоже впечатлён книгой и её героем; там же понравился подход — можно не любить человека, но это не мешает у него учиться:

> You can absolutely learn from people you wouldn't want to be. Extracting wisdom from Musk's success does not oblige you to become his disciple or his mirror. Besides, you'd probably fail miserably in an attempt of the latter anyway.

💊 реал биг дата!

у меня начинает складываться ощущение, что проблема big data плавно смещается; сначала все боялись этих терабайт данных: как же их хранить, как обрабатывать и искать в них инсайты.

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

теперь же встала другая проблема — среди этих десятков тысяч залитых и нагенерированных сущностей найти ту самую!

× как посчитать активных юзеров за прошлый месяц?

× как узнать сколько было возвратов?

× как понять сколько бизнес заработал? (или потерял!)

если спросить пять коллег, то получишь семь ответов; при этом часть будет пересекаться, а другая — прямо противоречить

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

кстати! давно хотел спросить: а что вы думаете о вопросах в конце постов?

136 (S5E21). Будни дата-инженера

В гостях у подкаста 🎙"Data Coffee" Саша Михайлов, дата инженер ( Telegram⁠, LinkedIn⁠)

Обсудили:
• кофе
• дата инженер
• нужен ли CDO для data mesh
• карьерный путь
• переезд в Швецию
• деанон по фитнес-трекеру
• детские сады района
• почему дата инженер
• pet projects
• как развиваться

Сайт: ⁠⁠⁠⁠⁠⁠⁠⁠https://datacoffee.link⁠⁠⁠⁠⁠⁠⁠⁠
Telegram: ⁠⁠⁠⁠⁠⁠⁠⁠https://t.me/datacoffee⁠⁠⁠⁠⁠⁠⁠⁠
Mastodon: ⁠⁠⁠⁠⁠⁠⁠⁠https://techhub.social/@datacoffee⁠⁠⁠⁠⁠⁠⁠⁠
Чат подкаста: ⁠⁠⁠⁠⁠⁠⁠⁠https://t.me/datacoffee_chat⁠

#datacoffee #data #podcast #данные #подкаст #кофе #coffee

Где слушать🎧:
— Бот-плеер
— RSS feed
— YouTube
— Остальные площадки

🎙️сходил на подкаст обсудить кофе и дату

↑

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

в эпизоде упоминали:

⌘ доклады Жени Ермакова и Коли Гребенщикова про чудо-DWH в Яндекс GO, благодаря которым я загорелся идеей попасть туда;

⌘ на один из предыдущих эпизодов подкаста, где гостем был Игорь Мосягин — поскольку он был в команде дата-платформы, там было много сочных деталей типа админстрирования Редшифта на 2к пользователей и мотивацию к документации.

🍱 восстанавливаю LinkedIn

→ в прошлых сериях: в процессе поиска работы в 2021 мне забанили аккаунт. Ретроспективно (спасибо за ссылки в комментах к прошлому посту!) прихожу к выводу, что это потому что я слишком агрессивно добавлял контакты и набралась критическая масса людей, которые в ответ на мой запрос жали кнопку «я не знаю этого странного чела»

и вот теперь они меня разбанили; ну как «разбанили» — видимо, где-то там внутри удалили старый аккаунт, и автоматика перестала банить новые попытки зарегаться как двойники. так что теперь заполнил всё заново и восстанавливаю старые контакты (крайне аккуратно, хе-хе)

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

тем временем приглашаю всех причастных и сочувствующих законнектиться! обещаю в ответ не жать злосчастную кнопку
https://www.linkedin.com/in/sasha-mikhailov-

к слову, если вы знаете как сделать линкедин по красоте, чтобы прям ваще вах! буду рад услышать прикладные советы <3

🥴 Reverse ETL — антипаттерн или норм?

у меня тут недавно наконец-то сложилась картинка в голове! до этого краем уха слышал этот новый термин, но никак не мог переложить его на реальность. А потом увидел схемку где помимо стандартного направления

источник → двх

была дополнительная стрелочка:

источник → двх → (обратно) источник

в итоге понял, что видел уже два таких кейса и пока ощущения смешанные:

1) считать бонусы определённому срезу сотрудников. был кейс когда ставка зависит от количества и статуса лидов например (или других штук, которые можно посчитать только в двх)

2) сейчас есть задача передавать данные между микросервисами (разные команды): микросервис А производит данные, их сгружаем в ДВХ, там происходит очистка и обогащение; а потом мы эти данные выгружаем в микросервис Б.

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

из плюсов вижу, что сразу «повышаются ставки» для наших данных и двх в целом — и пользователи начинают оперативно спрашивать за качество и свежесть) приходится проактивно шевелить булками и навешивать метрики с мониторингами. Это добавляет быструю обратную связь на результаты работы команды и держит всех в тонусе.

⌘⌘⌘

что думаете про Reverse ETL? какбэ антипарттерн или норм? есть альтернативы? как «правильно»?

👋 Саша Михайлов, безработный

почти год назад я писал, как устроился в шведский финтех Klarna и уехал жить в Стокгольм. Раз уж написал начало истории, напишу и её окончание 😭

что же случилось? не прошел перфоманс ревью? очередные лейоффы? Кларна закрылась?

всё гораздо проще: семья не прижилась в новой стране и мы решили вернуться назад

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

в итоге семья уехала «на лето к бабушкам на родину», откуда потом решили уже не возвращаться в Швецию. мне же оставалось только смириться (попутно пройдя те самые стадии) и написать заявление по собственному.

нотис период кстати вышел в два месяца (по контракту вообще три, но спасибо внезапному коллективному договору).

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

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

сейчас мы все уже в Москве, снова вместе 🫶

P.S.: вместе с возвращённым корпоративным ноутом у меня сломался мой блоггерско-редакторский процесс (и не только, хе-хе), но планирую скоро вернуться с регулярными постами ✌️

🤓 подгтовка к собесам: список техвопросов

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

в итоге на интервью на вопрос «какую базу выберешь под задачу» отвечал «хехехе, постгрес!». и хотя по всё нарастающей универсальности последнего ещё можно было бы дожать ответ, если бы я был наглее и увереннее; но по факту интервьюеры прекрасно понимали по ответу, что других баз я просто не в курсе.

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

часть вопросов легко гуглилась, с другой помогли товарищи инженеры 👋

например, с дорогим нашим airflow. последний раз я писал чистые даги в 2021 году ещё на клиентских проектах в консалтинге Epoch8. и, хотя я понимаю что это и зачем, всё таки пришлось заучить ответы на базовые вопросы (а ля сколько у него компонентов при развёртывании с докера), чтобы не добавлять лишних пустых ячеек в отчёте интервьюера.

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

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

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

после встречи я старался дополнять список новыми вопросами, если такие встречались. но тут есть ещё на чем поработать: мне не хватало «процессорной мощности» и вести диалог, и делать записи одновременно, то после встречи я не всё мог вспомнить, или просто пропускал этот этап 🤷

итоговая схема:
× собрать список тем
× темы заполнить вопросами
× по вопросам написать ответы
× перед встречей повторить ответы
× после встречи добавить новые вопросы

⇧ что думаете? чего тут не хватает?

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

среди всех начатых процессов мне запоминалась команда Купера (они же Sbermarket до июня 2024, а ещё раньше это был Instamart)

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

сам процесс был тоже без лишних этапов — быстрый скрининг и две секции: поговорить по душам за технику и потом за твой опыт и мотивацию

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

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

они ищут синьористого дата инженера в команду дата лейка; вот пост тимлида команды в небезизвестном чатике со всеми подробностями — в него можно накидать вопросов (если вдруг среди 49+ реплаев нет нужного ответа)
https://t.me/datajobs/482511

добавлю посту несколько сотен охвата к 3900+ подписчикам чатика, хе-хе

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

🤑 как я искал валютную удалёнку

когда я понял (ещё будучи в Стокгольме), что где-то осенью уже точно буду менять работу, я начал прикидывать варианты.

на тот момент (и с той стороны границы) самым выгодным казался вариант «валютной удалёнки»: когда платят в валюте европейского уровня зарплату, а я сам буду попивать смузи у себя в Москве. в уме я рисовал себе картину как буду получать на руки 5-7к долларов хе-хе-хе

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

⌘

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

по мере получения откликов, сложилось понимание, что топовые компании типа Miro или JetBrains (где я бы точно не отказался поработать при случае) имеют дополнительные ограничения на удалёнку: некоторые понимают «удалёнку» как «не обязательно ходить в офис, но надо быть в городе/стране где он есть».

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

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

⌘

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

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

⌘⌘⌘

потом подбил для себя плюсы и минусы:

+ + +
· зп в валюте (не привязан к курсу рубля)
· (потенциально) выше, чем в рублях в рф
· стэк без ограничений: облака, датабриксы, слаки и т.д.

− − −
· крайне ограниченный спектр потенциальных работодателей
· нужно ип-посредник, куда принимать деньги
· деньги с ип нужно регулярно конвертировать в рубли
· сложности с легальностью на стороне рф

(без оценки: кому как)
· точно удалёнка, без офиса рядом


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

подчеркну, что это решение, исходя из лично моих приоритетов в конкретный момент; лет пять назад (или ещё через пять в будущем) решение могло бы отличаться (и могло бы и нет — ваш кэп)

оставлю тут ссылку на папку с тг-каналами с вакансиями (вроде тут так принято, да?), которыми я оброс за время поисков. во многих присутствуют вилки зарплат, стэк и требования по гео: можно примерить на себя.

буду рад узнать ваши истории, если тоже проходили такое (особенно, если результат был иным))

🦖 как вытаскивали динозавра в опенсорс

каджый яндексоид знаком с «ытём» — система хранения данных с sql-подобным доступом. я бы сказал, что YT находится в центре всех процессов яндекса, которые завязаны на анализ данных (это получается, практически всех?)

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

а с не давних пор, посмотреть на этого дивного зверя могут все желающие — теперь YTsaurus доступен в опенсорс.

↓ доклад с прошлогоднего хайлоада с отчётом и рефлексией команды по итогам первой фазы этого эпического движа (да-да, с офф. релизом работа только началась))

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

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

⌘ по трудозатратам — год для команды 10 человек, и это только первый минимальный вариант «за который не стыдно»

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

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

https://youtu.be/Z7kv8tYVHx0

как сказал докладчик, ближайший аналог YTsaurus в опенсорсном мире — тот самый Hadoop. либо более современный S3 + Trino (+ обвязка)

https://ytsaurus.tech/ru/platform-overview

Архитектурно YTsaurus состоит из нескольких слоев:

1. распределённая файловая система и хранилище метаданных (Cypress).

2. планировщик с поддержкой парадигмы MapReduce.

3. высокоуровневые среды вычислений: YQL, CHYT (ClickHouse over YT), SPYT (Spark over YT).