tgindex

FAANG зовет!

описание

Уже $100К+. Теперь проверяю, получится ли FAANG. Реальные интервью, подготовка, победы и отказы. Meta · Amazon · Stripe · Datadog · DSA · System Design · зарплаты · жизнь разработчика во Франции 🇫🇷 Контакты: @srgpan

← к каналу@faangiscalling
366
подписчиков
Охват к подписчикам
17,5%
ERR
Реакции к просмотрам
1,44%
101 на 48 постов
Пересылки к просмотрам
1,07%
75
Постов в день
3,9
всего 50

Где отзываются чаще

доля реакций к просмотрам
  • 15 авг.$100К+ есть. Теперь зовет только FAANG! 🚀 Кажется, я сам, наконец, понял, о чём этот канал 🙂. Поэтому решил не усложнять: FAANG зовет! Почему? $100К+ я уже достиг. А вот в FAANG пока не попал — поэтому хочу рассказывать именно про этот путь: подготовку, реальные интервью в Meta, Amazon, Stripe и Datadog, удачи и отказы. Я живу и работаю в Париже 🇫🇷 уже 4 года. Но искать следующую работу буду шире: Лондон 🇬🇧 , Париж 🇫🇷 , Амстердам 🇳🇱, Цюрих 🇨🇭 — посмотрим, где в итоге окажусь. Здесь будут материалы по подготовке, мой опыт интервью в Meta, Amazon, Stripe и Datadog, зарплаты, карьерные наблюдения и немного жизни разработчика во Франции🇫🇷 То есть это не «я уже попал в FAANG и сейчас расскажу, как это сделать». Я сам пока в процессе — и буду делиться тем, что узнаю по пути — чтобы вы могли использовать мой опыт в вашей карьере, не повторять мои ошибки и, подготовиться к вашим следующим шагам лучше. Подписывайтесь, если хотите наблюдать этот путь изнутри, а если знаете человека, которому это может быть полезно — поделитесь с ним каналом. Буду рад, если мой опыт поможет кому-то быстрее прийти к своим целям 🚀 @faangiscalling16,67%
  • 14 авг.без подписи10,29%
  • 14 авг.без подписи8,11%
  • 09:24📊 Golden Signals: 4 ключевые операционные метрики распределённых систем от Google Термин 'golden signals' пришёл из книги Google SRE и стал стандартом индустрии. В основе — SLI/SLO подход: SLI (Service Level Indicators) — что измеряем SLO (Service Level Objectives) — какая цель по этой метрике Четыре 'golden signals' для распределенных систем: 📊 Latency (p95) — максимальное время выполнения 95% всех запросов (перцентиль p95), показывает реальный опыт большинства пользователей. Также часто меряют p99 🚀 Traffic / Throughput (QPS) — сколько запросов в секунду (queries per second/QPS) обрабатывает система ✅ Availability/Errors — соотношение 5xx к общему числу запросов к системе, показывающий уровень доступности системы ⚙️ Saturation — 'насыщение' ключевых ресурсов системы (CPU, память). Ранний сигнал о приближающихся проблемах. Термин настолько прижился, что стал частью продуктов observability-платформ. Например, все это есть по умолчанию в том же Datadog: для каждого сервиса видишь его 'golden signal' метрики (requests, errors, duration). Простой health check / heart beat дает слишком мало информации. Четыре 'golden signals' вместе дают полную картину: работает ли сервис, насколько быстро и корректно, и есть ли запас прочности под увеличение нагрузки. А что еще вы мониторите в ваших системах/сервисах? @faangiscalling6,38%
  • 10 авг.UUID: почему “уникальный” это на самом деле про вероятность Разбирался тут, откуда у UUIDv4, самой популярной 4-й версии, берётся “уникальность”, и оказалось интереснее, чем казалось. UUID (Universally Unique Identifier, “универсальный уникальный идентификатор”) — это просто 128-битное число, записанное как 32 hex-символа через дефисы для читаемости. Выглядит это так: f47ac10b-58cc-4372-a567-0e02b2c3d479 Сами дефисы и группы — просто визуальное удобство, никакой отдельной структуры в них нет. У v4 122 бита случайны, 6 фиксированы (обозначающие версию/вариант) — например, четверка сразу после второго дефиса всегда означает “версия 4”. Никакого хеширования при его генерации — это результат работы специального генератора случайных чисел. “Уникальность” здесь — не теорема, а оценка вероятности через классическую задачу о Днях Рождения: В группе из N человек какова вероятность, что хотя бы у двух из них День Рождения в один день? Уже для 23 человек получаем вероятность ‘коллизии’ выше 50% (Дня Рождения в один день хотя бы у одной пары людей). Теперь для UUID: – количество “дней в году”: 2^122 (именно столько случайных бит, остальные 6 фиксированы) – количество “людей” — число сгенерированных ID: n Из-за огромного количества вариантов (2^122), тут 23 уже не хватит для коллизии: чтобы получить вероятность коллизии в 50% на таком большом пространстве, нужно сгенерировать n~2⁶¹ UUID (это больше миллиона триллионов) ❗️ На практике это оказывается, по сути, невозможным — в том же смысле, в каком невозможно случайно угадать чужой приватный ключ (скорее в лотерею джекпот выиграешь 😀) Самое интересное — откуда берётся сама случайность. Ядро операционной системы (ОС) собирает энтропию, она же “случайность внешнего мира” (джиттер прерываний, тепловой шум в транзисторах, микро-колебания силы тока в процессоре), но её мало и она медленная (не так много событий за единицу времени, а генерировать нужно много ID). Поэтому её “растягивают” через CSPRNG (cryptographically secure pseudorandom number generator) — детерминированный алгоритм (ChaCha20 в Linux, AES-CTR в других системах), который по сути своей не случаен, но выдаёт последовательность чисел, которую невозможно отличить от случайной за разумное время вычислений — так называемое computational indistinguishability. Мой математический бекграунд потребовал разобраться, а есть ли тут вообще формальное доказательство 🤓 И тут есть нюанс. Формальные доказательства такого рода существуют — например, Blum, Blum, Shub (1986) построили генератор, для которого можно математически доказать: если найдётся способ отличить его вывод от случайного, то тем же способом можно решить задачу факторизации большого числа. Красивая штука — но такой генератор слишком медленный для реального использования, это скорее демонстрация того, что подобное доказательство в принципе возможно. А вот у ChaCha20 и AES — то, что реально реализовано в ОС и генерирует UUID — такого чистого сведения к одной понятной математической задаче нет. Их надёжность держится на другом основании: ~40 лет попыток взлома лучшими криптоаналитиками мира, ни одна из которых не увенчалась успехом. То есть в криптографии в принципе нет ни одного алгоритма с абсолютным доказательством “это невозможно взломать” — есть два разных вида уверенности: - либо чистое математическое сведение к нерешённой задаче (факторизация, но такие генераторы медленные), - либо эмпирическая устойчивость к криптоанализу (быстрые алгоритмы вроде ChaCha20, которые реально используются). Индустрия выбрала второй путь — не потому что математика не важна, а потому что для быстрых алгоритмов такого изящного сведения пока просто не существует. Так что “уникальность” UUID — это, по сути, очень хорошая случайность, чья надёжность держится не на теореме, а на репутации, проверенной десятилетиями попыток её разрушить. @faangiscalling6,10%
  • 9 авг.🙁Как я ошибался: перезапуск интервью после кулдауна Если честно, я думал, что перезапустить новые интервью после кулдауна будет очень просто, так как у тебя уже есть контакты HR и ты проходил скрининг, попадая на full-loop, что означает что ты уже более чем реальный кандидат. Но я сильно ошибался, сейчас у меня все это идет крайне сложно и медленно. Рассказываю текущий статус: • Meta (Лондон 🇬🇧) – после годового кулдауна мой HR ушел из компании, о чем она мне сообщила только после 2-3 писем на почту (которую она, как выяснилось, уже не получала ибо ушла из компании) и сообщения в LinkedIn. Нашел моего первого скрининг-менеджера на LinkedIn, жду ответа. • Amazon (Париж 🇫🇷/Лондон 🇬🇧) – после 2-3 писем на почту, только LinkedIn снова выручил - HR ответил, спросил какие я еще локации рассматриваю, я сказал, жду, что дальше ⏳ • Datadog (Париж 🇫🇷) – французский сезон отпусков в разгаре, моя менеджер на 3 недели в отпуске, подменный HR из Дублина отвечает что-то невнятное. Думаю, что надо пинговать моего менеджера в сентябре. • Stripe (Дублин 🇮🇪) – ноль ответов на 2-3 сообщения на почту, хотя кулдаун был вообще всего 6 месяцев. Но на днях случилось чудо и после почти года висящего запроса на коннект в LinkedIn, HR его акцептовала 😀 Посмотрим, значит ли это что-то. Просто к слову, со Stripe нюанс в том, что у них акции не на бирже и сток-пакет в целом довольно “бумажный”, в отличии от тех же Meta, Amazon и Datadog (correct me if I’m wrong в комментариях, пожалуйста). Выводов несколько: ⁃ Всегда пытаться получить второй канал общения – LinkedIn, добавлять туда своих HR-ов. Если не добавляются, вы все равно можете отправить 5 inMail (не требуют быть в контактах) в месяц даже без premium. ⁃ Ощущение, что подача снова через сайт может быть эффективнее. Может поэкспериментирую с этим. ⁃ Just keep on doing it 🙂 Да, без этого никак. А какой у вас опыт перезапуска интервью после кулдауна? @faaingiscalling6,09%
  • 13 авг.Snowflake ID: как Twitter решил проблему генерации уникальных ID в распределённой системе 🪪 Раньше писал про UUID — уникальный ID без центрального сервера, но случайный и не сортируется по времени в классической версии v4. Twitter хотел одновременно: – генерировать ID на сотнях серверов независимо – гарантировать уникальность – обходиться без центральной БД – получать ID, отсортированные времени с определенной точностью – уложиться в 64 бита для уменьшения размера индексов, кеша Главный челлендж здесь — разрешить конфликт между уникальностью, распределённостью и упорядоченностью по времени. Так в 2010 году появился snowflake (не связан с хранилищем для аналитики Snowflake, а просто отражение концепции, что snowflake, то есть снежинка по-русски, никогда не повторяется, они все разные, что и ждешь от генератора ID). Идея: один 64-битный ID с определенной структурой, решающей челлендж: ⁃ 1 резервный бит ⁃ timestamp (41 бит) ⁃ worker ID (10 бит) ⁃ sequence (12 бит) Timestamp — миллисекунды с эпохи Twitter (с 2010 года, а не 1970 как у UNIX), в старших битах → дает простое числовое сравнение ID = сортировка по времени с точностью до миллисекунды. Этой длины в 41 бит хватит почти на 70 лет Worker ID — какой датацентр (5 бит) и какой сервер (еще 5 бит) создал ID, по сути номер “воркера” (0 - 1023). Sequence — номер ID внутри текущей миллисекунды у конкретного "воркера", каждую миллисекунду обнуляется (0 - 4095) Два "воркера" создают ID независимо и эти ID никогда не пересекаются: timestamp | worker 17 | sequence 42 timestamp | worker 18 | sequence 7 Какое максимальное количество ID можно генерировать в секунду? 12 бит sequence = 4096 ID с одного "воркера" за 1 миллисекунду → ~4 млн ID с одного “воркера” за 1 секунду (1000 миллисекунд)→ ~4 млрд ID на 1024 “воркерах” за секунду. Более чем достаточно для Twitter и для других практических ситуаций. Сама идея «timestamp внутри ID» не нова — сила snowflake в удачной комбинации: distributed generation + uniqueness + temporal ordering + 64-bit integer. Отсюда пошли Sonyflake, Instagram-style ID и другие «flake»-форматы, а позже — ULID и UUIDv7, развивающие ту же идею. Так что хороший system design — это не всегда новый алгоритм. Иногда это просто удачно разложить требования по битам. 🙂 @faangiscalling5,56%
  • 11 авг.DSA, system design и behavioral для финального рывка Я завершил собирать свою 'боевую' библиотеку для финального рывка подготовки. Приехали вот только что: - новая книга Остина МакДоналда из Меты про подготовку к бихейву like a pro. Она неожиданно оказалось цветной внутри, с красивыми акварельными иллюстрациями 😍 - второй том Алекса Ху по system design. Формат подрос как и количество деталей в самой книге, выглядит скорее как v2.0, чем просто второй том. Но формат уже менее travel-friendly - паттерны решения DSA/LeetCode снова от Алекса. Захотел попробовать альтернативу моей любимой EPIP с глубоким погружением в алгоритмы. У Алекса как и в system design книге много очень схем и картинок, книга-кандидат в refresher перед интервью как один из сценариев. Посмотрю их в деле, расскажу вам. @faangiscalling5,19%
  • 4 авг.Подготовка по пути на работу (commute) 🚝 У меня поездка на работу в офис в Париж 🇫🇷 (тот самый commute) составляет 1.5+ часа, поэтому я искал эффективные методы использовать это время с пользой для подготовки. Делюсь тем, что работает хорошо: • аудиокниги Audible от Amazon. Там есть почти вся классика технической литературы – прослушал "кабанчика" (DDIA Клаппмана), The Staff Engineer's Path Тани О'Рейли, The Software Engineer's Guidebook Гергея Ороса и другие • бумажные книги с карандашом, ручкой и тетрадкой. Как System Design Interview Алекса Ху с фото - читаешь и делаешь пометки в книге и в тетрадке • подкасты на Apple Podcasts (сделаю отдельную подборку самых интересных) • ЮТуб-истории людей: Это обычно на вечер, на путь обратно. Из недавних интересных - история моего друга Евгения Рая, Staff Engineer в Мете в Лондоне 🇬🇧 Иногда нужен перерыв - включаю 'режим восстановления': музыка, подкасты про культуру/путешествия на русском. А какие у вас работающие способы в вашем commute? @faangiscalling4,96%
  • 3 авг.Банк историй для Behavioral Interviews 📝 Многие из вас знают, что для Behavioral interviews (Tell me about a time when...) нужно подготовить свой банк историй. Но на практике довольно сложно вот просто сесть и написать 10-15 историй на разные темы: • Failure/Leadership, • Conflict/Disagreement, • Ambiguity, • Leadership/Influence, • Scale/Tradeoffs, • Learning fast. Есть и другой подход, 'бухгалтерский' (записываем транзакции и агрегируем их в нужный вид). В рабочие дни Ежедневно за 2-3 минуты записывать по результатам рабочего дня все, что вызывало 'трение': - что сломалось или почти сломалось - вы приняли решение в условиях неопределенности (ambiguity) или с кем-то/чем-то не согласились - где вы застряли и потом разблокировали себя - вы шипнули что-то рискованное в прод, или заметили риск до этого В конце недели Затем еженедельная рутина на 10 минут: - выбрать транзакции с потенциалом историй для интервью, перенести в банк историй - в банке историй тегировать их по темам (Failure, Conflict...) 👆 В конце месяца Ежемесячно на 15 минут: - переписать лучшие 1-2 истории по методу STAR. Бонусом можно добавить блок 'что произошло дальше' - добавить второй тег - 'polished' к таким историям В день Х Перед интервью: - сделать динамические страницы по темам (фильтр по тегу темы) и дополнительным фильтром 'polished' - заучить истории - PROFIT! Как инструмент я использую Obsidian, там можно вот так: table date, company, role from "Stories" where contains(tags, "failure") and status = "polished" sort date desc Попрактикую этот метод и поделюсь с вами опытом через пару месяцев. @faangiscalling4,44%
  • 7 авг.15 паттернов, которые решают почти любое System Design интервью 🚀 Практически любое system design интервью в FAANG и не только сводится к знанию примерно 15 архитектурных паттернов. 📚 Хорошая новость в том, что не нужно изобретать велосипед — интервьюеры обычно проверяют, узнаете ли вы знакомую задачу и сможете ли применить правильный подход. Я сделал себе шпаргалку по основным системам с собесов, делюсь с вами – вот мой короткий список с главным челленджем для каждой системы: 📦 Dropbox — разбиваем файлы на чанки + используем Merkle Trees для синхронизации только изменений. 👉 Челлендж: не загружать заново гигабайтные файлы из-за одного измененного байта. 🔔 Notifications — очереди (Kafka/SQS/RabbitMQ) отделяют отправку от доставки. 👉 Челлендж: обрабатывать пиковые нагрузки и отрабатывать failed-отправки. 📰 News Feed (Facebook) — гибридный fan-out для ленты каждого подписчика: пишем вам в ленту от обычных юзеров, на которых вы подписаны, читаем на лету для знаменитостей. 👉 Челлендж: избежать миллионов записей в ленты подписчиков при каждом посте знаменитости. 🐦 Twitter Timeline — тот же fan-out + кэширование лент в Redis. 👉 Челлендж: выдерживать огромный объем чтений. 🔗 URL Shortener — Base62 + распределенные ID (Snowflake). 👉 Челлендж: генерировать уникальные ссылки без единой точки отказа (SPOF). 💬 WhatsApp / Chat — постоянные WebSocket-соединения + очередь сообщений для офлайн-пользователей. 👉 Челлендж: гарантировать доставку и правильный порядок сообщений (ordering), когда юзеры оффлайн. 🕷 Web Crawler — BFS + Bloom Filter. 👉 Челлендж: избегть повторных индексаций одной и той же страницы и бесконечных циклов. 🚦 Rate Limiter — Token Bucket в Redis. 👉 Челлендж: обеспечивать синхронизацию и выполнение лимитов одновременно на десятках распределенных серверов. 📺 YouTube — заранее перекодируем видео в разные качества и раздаем через CDN. 👉 Челлендж: быстро отдавать огромные видео пользователям с разной скоростью интернета. 🚕 Uber — Geohash или QuadTree для поиска ближайших водителей. 👉 Челлендж: поиск “рядом” в реальном времени на уровне целого города. 🎫 Ticketmaster — блокировки строк БД + очередь. 👉 Челлендж: не продать одно и то же место двум людям одновременно при огромном одномоментном спросе (начало продаж на концерт). 📝 Google Docs — CRDT (Conflict-free Replicated Data Types ) или Operational Transformation. 👉 Челлендж: несколько пользователей одновременно редактируют один и тот же текст без конфликтов. 📸 Instagram — оригинал хранится один раз, миниатюры (resize) создаются асинхронно, раздача через CDN. 👉 Челлендж: обрабатывать огромные объемы загрузок изображений и видео (медиа) не замедляя приложение. 🔎 Autocomplete — Trie с заранее рассчитанной популярностью запросов. 👉 Челлендж: отвечать менее чем за 100 мс на каждое нажатие клавиши. ⚡ Redis (дизайн) — Consistent Hashing с шардами по диапазонам ключей. 👉 Челлендж: перебалансировка кластера нод (серверов) без необходимости полного перераспределения всех данных между нодами. 💡 Если понять основной челлендж и паттерн, который его решает, то большая часть system design интервью перестает казаться чем-то страшным. Сохраните пост — это хорошая шпаргалка перед собеседованиями. 🔖 @faangiscalling3,70%
  • 28 июл.System design сюрприз от WhatsApp 😲 Недавно в рамках подготовки по system design я разбирал распределенную базу данных Cassandra, которую разработали в Facebook. Я пытался понять, почему есть Cassandra для поиска по сообщениям в самом FB (для этого ее и придумали), при этом ее не используют для поиска по сообщениям WhatsApp, где, очевидно, таких сообщений должно быть гораздо больше: вспомните, когда вы последний раз кому-то отправляли сообщение в FB, а когда в WA 😀 И тут сюрприз – WhatsApp не хранит у себя историю сообщений. По сути WhatsApp – это 'роутер' сообщений, никакого (долгосрочного) хранилища под сообщения нет. В том же FB ты можешь найти все свои сообщения хоть за последние 15-20 лет. Посмотрел историю WhatsApp с 2009 года – первая архитектура была сделана ребятами из Yahoo на Erlang, языке, оптимизированном под задачи роутинга, под огромное число одновременных соединений. По сути WhatsApp работал и работает как большая телефонная станция на 2 млрд абонентов, сотни миллионов из которых подключены одновременно. Но фокус в том, что еще в 2011 году инженеры из WA научились делать 2 миллиона (!) одновременных коннектов на одном сервере 💪 Про всю их очень интересную стату из 2011 года (~500 млн пользователей , 550 серверов, из них 150 серверов на 1М+ коннектов каждый) можно почитать в известном докладе 👇 How WhatsApp Grew to Nearly 500 Million Users, 11,000 cores, and 70 Million Messages a Second - High Scalability - Очень полезно всем практикующим distributed systems, high load, ну и подготовку к system design в FAANG. @faangiscalling3,28%