🛠️ 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://yangx.top/datacoffee⁠⁠⁠⁠⁠⁠⁠⁠
Mastodon: ⁠⁠⁠⁠⁠⁠⁠⁠https://techhub.social/@datacoffee⁠⁠⁠⁠⁠⁠⁠⁠
Чат подкаста: ⁠⁠⁠⁠⁠⁠⁠⁠https://yangx.top/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://yangx.top/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).

⚖️ собесы: дисбаланс за столом

бывало на собесе сижу-пыхчу над задачкой, отбрасывая варианты один за другим, в итоге в муках порождаешь вроде-ничего-такое решение… только для того, чтобы интервьюер на той стороне нашёл там несколько критичных багов, и не особо запариваясь при этом. в такие моменты я чувствовал себя совсем тупым. ну или как минимум тупее интервьюера (а значит, тупее среднего сотрудника целевой компании!) 🤦‍♂️

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

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


⌘⌘⌘

🤓 как можно подготовиться к собесам:

— собрать список вопросов и накидать ответы;

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

— обложиться поддержкой: профильные коммьюнити и консультанты;

— потренироваться «на кошках»: попробовать пройти мок-собесы;


⌘⌘⌘

📚 открытая инфа

§ эпизод Lenny’s podcast c Phyl Terry — он помогает людям искать работу уже третий десяток лет и автор книги Never Search Alone; один из его советов — не бояться попросить помощи.
https://www.lennysnewsletter.com/p/land-your-dream-job-phyl-terry

§ подкаст Собес — плод труда Киры Кузьменко (New HR) и не менее замечательных ребят из студии подкастов Либо/Либо. В последнем сезоне как раз делают публичные мок-интервью: соискатель проходит интервью и сразу получает обратную связь с рекомендациями.
https://libolibo.ru/sobes

§ спин-офф от команды LeftJoin — канал о карьере и рекомендациях. Я воспользовался советами об оформлении Линкедин https://yangx.top/leftjoin_career/32

§ свежий неожиданный врыв в дата-инфополе: канал с отчётами по форме о нескольких десятках собесах: с вопросами и вилками. можно пополнить свой список вопросов, посмотреть интересные компании и откалибровать хотелки https://yangx.top/get_rejected/39


⌘⌘⌘

👯‍♀️ коммьюнити

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

§ https://boosty.to/halltape_data (больше для джунов и только-только вкатывающихся)

§ https://boosty.to/rzv_de (уже для миддлов и дальше)

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


🥊 консультации

как тренер за спиной боксёра — не сможет за тебя помахать кулаками, но настроит на нужный лад перед встречей и поможет отрефлексировать итоги после. плюс можно сориентироваться внутри отрасли, узнать общую сводку по компаниям: кто чем отметился в публичном поле за последнее время. как пример — Семён Осипов https://yangx.top/ohmydataengineer


⌘⌘⌘

до мок-интервью пока руки не дошли — было ощущение что на внутреннем рынке поиск идёт «достаточно хорошо». в следующий раз хочу попробовать пройти несколько, уже присматриваюсь к сисдизайну https://yangx.top/system_design_world и архитектурным катам https://yangx.top/arch_katas_russia


⌘⌘⌘

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

☝️

😭 как я не прошёл «собес» в ABBYY

сходил на подкаст к Кире Кузьменко, поговорили в формате мок-интервью
https://yangx.top/kirafound/1861

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

было интересно поговорить и ещё более интересно узнать «как надо».

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

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

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

⌘

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

🏦 новый_план(2)_final

в 2021 у меня был план, который потом пришлось спешно править и вот спустя всего год снова пришлось пере-пере-придумывать план.

в шведской Кларне нотис-период был два месяца, было время подумать-подготовиться. исходный план был максимальной широкий: «посмотреть всех» — включая иностранные компании.

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

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

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

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

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

в общем, по всем пунктам можно поставить галочки:

⌘ посмотрел в сторону валютных удаленок (но не пошёл дальше)

⌘ бывшие коллеги и смежники звали пообщаться про новые проекты (когда зачётка работает на тебя)

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

⌘ в процессе случайно заскочил на подкаст про поиск работы (будем считать сайд-квестом)

и как итог «вернулся назад» в Яндекс, на этот раз в Яндекс Банк, он же Финтех (надеюсь, уже все открыли счёт, научились сплитить, и подключили авто-пополнение))

и спасибо всем, кто писал и шерил вакансии! в такие моменты поддержка особенно важна и к тому же крайне приятна <3

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

что же там оптимизировать, спросите вы? сейчас расскажу:

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

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

ведь (когда они не в мойке и не в раковине) вилки живут с вилками, ложки — с ложками; глубокие тарелки с одной стороны, отдельно от плоских. у кастрюль и плошек тоже есть свои места.

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

сравним две последовательности разгрузки:

ложка → вилка → нож → нож → вилка → ложка

ложка → ложка → вилка → вилка → нож → нож

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

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

можно пойти дальше и провести аналогии в выборе момента для упорядочивания элементов с двумя известными известными подходами: запись inplace в B-Tree или append-only LSM; то есть либо мы заранее оптимально раскладываем элементы (тратя какой-то ресурс на это), либо мы сваливаем как есть, а разбор элементов оставляем на потом (ровно как и траты ресурсов).

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

⌘ ⌘ ⌘

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

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

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

🗿 подкасты про карьеру

специально для постоянной читательницы этого блога — Натальи — ни к чему не обязывающая подборка подкастов на тему карьеры, её смены и всякого такого >_>

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

⌘⌘⌘

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

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

→ https://libolibo.ru/sobes


⌘⌘⌘

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

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

→ https://yangx.top/podlodkanews/1440


⌘⌘⌘

и отдельно на тему аналитики два проекта от ребят из тбанка.

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

→ https://yangx.top/eto_schitaetsya/477

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

→ https://yangx.top/karty_dengi_product/112


⌘⌘⌘

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

→ https://music.yandex.ru/album/22481935/track/129159864


⌘⌘⌘

§ что ещё можно послушать-посмотреть условному бизнес-аналитику в условном финтехе?

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

📦 YDB + OLAP = ?

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

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

https://yandex.cloud/ru/blog/posts/2024/12/ydb-dwh


⌘⌘⌘

интересно посмотреть со стороны аналитики и нашего двх-мира.

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

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

→ добавили колоночное хранение c массивно-параллельными вычислениями через векторные движки

→ стоимостной оптимизатор (cost-based) для плана запроса с подбором оптимального порядка и алгоритма джойнов

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

→ спиллы на диск для больших вычислений

→ нативная поддержка охлаждения данных в s3 (автоматическое гибридное хранение для колоночных таблиц)

→ сбор статистики для таблиц

→ predicate pushdown для оптимизации чтения

→ федеративные sql-запросы из разных источников

→ пулы ресурсов — разделение под разные нагрузки

→ асинхронная репликация между удб-инстансами


по мотивам обзорного доклада про новости удб с конфы yandex scale
https://vkvideo.ru/video-200452713_456239488

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

1/2

2/2

в общем, много чего для нужд аналитики в удб уже есть, но чего там нет — надо додумывать самому)

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

плюс в документации есть отдельная сноска чего пока нет в колоночных таблицах

> В настоящий момент реализована не вся функциональность колоночных таблиц
https://ясубд.рф/docs/ru/concepts/datamodel/table.html#column-oriented-tables

(надеюсь, документация просто чуток отстаёт от новых фич)

⌘⌘⌘

в теории звучит хорошо — один инструмент лучше, чем пять разных (при прочих равных)

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

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

⌘

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

то есть зоопарк инструментов остаётся, но задачи и кейсы могут чуток перераспределиться — polyglot persistance пока не отменяем
https://martinfowler.com/bliki/PolyglotPersistence.html

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

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

🦆 прилетят орлы и поднимут прод

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

со стороны это читается как «там на дисках место заканчивается … кто-нибудь сделайте что-нибудь!»

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

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

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

- понятно, что решение может быть тоже не простое или даже несовсем правильное

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

иными словами, приходи с решением, а не проблемой!