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

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

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

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

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

например, с дорогим нашим 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).

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

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

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

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


⌘⌘⌘

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

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

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

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

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


⌘⌘⌘

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

§ эпизод 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://t.me/leftjoin_career/32

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


⌘⌘⌘

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

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

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

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

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


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

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


⌘⌘⌘

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


⌘⌘⌘

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

☝️

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

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

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

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

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

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

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

⌘

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

⌘ ⌘ ⌘

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

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

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

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

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

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

⌘⌘⌘

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

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

→ https://libolibo.ru/sobes


⌘⌘⌘

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

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

→ https://t.me/podlodkanews/1440


⌘⌘⌘

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

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

→ https://t.me/eto_schitaetsya/477

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

→ https://t.me/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 должно быть дешевле, чем в удб. в силу архитектуры и заявленных характеристик систем.

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

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

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

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

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

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

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

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

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

🤑 yet another zarplaty

классный пример коллаборации:

Саша Варламов собрал парсер и визуализацию
https://t.me/data_bar/60

а Никита это дело автоматизировал
https://t.me/joni_in_web/21

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

что мне нравится в подобных проектах:

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

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

3. полезность, направленная наружу: когда решал свою задачу, а польза — всем

в общем, смотрите деш и ставьте лайки Саше с Никитой)

🐤 джуны, LLM и Shopify

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

→ и тогда со временем всю базовую джуновскую работу будут делать llm-агенты

⌘⌘⌘

противоположный тезис высказывает Farhan Thawar, Head of Engineering в Shopify (всё время читаю как Spotify, приходится себя одёргивать и перепроверять)

Shopify среди меня известен своим мега-крутым фаундером — Tobias Lütke; слушал его в Lenny's Podcast — создаёт впечатление очень здравого и продвинутого человека

кроме того, про него неоднократно упоминал Lex Fridman, что даёт ещё сколько-то очков этому джентельмену и культуре в его компании

⌘⌘⌘

ещё добавляет веса этой дискуссии фигура ведущего. Gergely Orosz — автор рассылки The Pragmatic Engineer (а теперь ещё и одноимённого подкаста)

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

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

⌘⌘⌘

про адоптинг аи-тулзов

господин Farhan замечает, что Шопифай был первым пользователем Copilot за пределами GitHub — для этого просто надо было написать письмо напрямую СЕО и просто попросить.

сразу после того, как Томас Домк стал генеральным директором GitHub, он отправил ему электронное письмо с просьбой предоставить доступ к Copilot для инженеров Shopify.

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

⌘

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

почти для каждого инструмента внутри Шопифай есть MCP сервер и инструкция как его подключить к своему Курсору.

⌘

про найм стажёров

- в прошлый семестр (?) Шопифай нанял 25 стажёров

- Farhan уговорил своего СЕО в следующий семестр нанять ноль 1000 (!) стажёров

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

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

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

в общем, Шопифай делает ставку на ai-стажёров

подкаст есть на ютубе
https://youtu.be/u-3IILWQPRM

@data_days

NewHR в очередной — уже шестой! — раз проводит опрос про работу аналитиков

я бы тоже прошёл, но я, к сожалению, я не аналитик

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

новый опрос за 2025 год тут

а освежить в голове
результаты опроса 2024 можно тут
https://newhr.org/data/research-analysts-2024

🎧 Data Platform T-Bank

послушал подкаст с СТО платформы данных Т-Банка
https://t.me/book_cube/3766

для понимания масштаба

→ 15К MAU пользователей платформы (при условных 18К всех сотрудниках инхаус — это довольно большое проникновение)

→ всю платформу поддерживает ~230 человек

→ сторадж — около 15–20 петабайт;

→ компьют — порядка 100К ядер

→ внутри ~20 тысяч объектов

основная аналитическая СУБД — Greenplum: около 10 кластеров от 30 до 72 нод в каждом


проблемы с текущей архитектурой

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

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

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

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


планы дальше

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

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

в качестве новой целевой архитектуры выбрали стандартный набор:
iceberg + s3 + spark + trino

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


@data_days

🤓 Martin Fowler в гостях Pragmatic Engineer

https://youtu.be/CQmI4XKTa0U

Мартину уже за 60 лет, из которых он 40 с лишним считает себя инженером; когда опыт исчисляется десятками, то накапливается тот уровень насмотренности, когда можно сравнивать эпохи и видеть глобальные тенденции

⌘⌘⌘

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

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

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

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

⌘⌘⌘

при этом в прототипировании аи-помощник показывает небывалые приросты в продуктивности. приводят пример инженера из Антропика, который за 2 дня собрал 20 прототипов, итеративно проверяя и валидируя их об команду.

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

⌘⌘⌘

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

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

⌘⌘⌘

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

и тогда действительно можно получать какой-то профит от совместной работы