Настоящий дизайн-док от Google

Вы хотели узнать как делают дизайн-доки в настоящем FAANG? Вот пример дизайн-дока от Google для Инспектора Памяти (Memory Inspector) для Chrome:

🔗 Гугл-док с дизайн-доком: https://docs.google.com/document/u/0/d/1LUOat3Q3pQ08IsnBQLrvL-4zWXSTgIuArb5ig3lEm-Y/mobilebasic?pli=1

💡Из интересного:
- one-pager summary в начале
- четкая формулировка ценности (value proposition) предлагаемой фичи
- очень короткое описание User Story
- много скриншотов с примерами
- много схем


Кстати, у Гугла есть еще бесплатный курс про то, как писать такие документы, поделюсь им тоже, stay tuned ;)

@faangiscalling

Бесплатный курс от Google по Technical writing 📝

Все мы пишем технические документы - этот курс за пару часов рассказывает, как делать это хорошо на уровне FAANG.

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


🔗Начать учится бесплатно: https://developers.google.com/tech-writing/one

Как говорят в самом Google - better wrong, than vague.

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

@faangiscalling

Гайд от Harvard по CV и Cover Letters 📄🇺🇸

Делюсь гайдом от Harvard по составлению резюме и сопроводительных писем:
– примеры резюме
– словать глаголов для описания своих результатов
– примеры сопроводительных писем
– общие советы

TL;DR: black and white one-pager is a king 👑

Пользуйтесь и улучшайте ваши резюме!

@faangiscalling

📊 Мониторинг 101: два стека (LGTM/ELK) и два подхода (Push vs Pull)

Я продолжаю прокачивать System Design, сейчас слушаю книгу от Google по SRE - главную книгу про мониторинг распределенных систем в продакшене.

Там говорится про их внутреннюю систему - Borgmon, которая работает на основе pull-подхода. Что это такое и какие есть классические стеки для мониторинга систем в проде, я хотел поделиться с вами сегодня.

Это важный элемент как в реальной работе (например, я сам делал дешбооды в Kibana для моих endpoints), так и на интервью.

Pull vs Push

Pull — система мониторинга сама опрашивает все сервисы-таргеты по расписанию (например, каждые 15 сек). Так же получаешь бесплатный heartbeat: сервис не ответил — значит, сервис не доступен.

Push — таргет сервис сам шлёт метрики на сервер. Удобнее для короткоживущих задач (jobs) и таргетов за файрволом.

Prometheus из LGTM (👇) и его предок в Google (Borgmon) как раз используют pull-подход.

Классический ELK (👇) – обычно push.

LGTM-стек (Loki, Grafana, Tempo, Mimir/Prometheus)

Cloud-native подход, всё от Grafana Labs:
• Prometheus/Mimir — метрики, pull-модель
• Loki — логи, индексирует только метаданные (дёшево, но нет полнотекстового поиска)
• Tempo — трейсы
• Grafana — единая визуализация сверху

Лёгче и дешевле в хранении, стандарт в Kubernetes-мире.


ELK-стек (Elasticsearch, Logstash, Kibana)

Более старый и “тяжёлый” подход:
• Elasticsearch — полный индекс текста логов (мощный поиск, дороже по ресурсам)
• Logstash/Fluentd — сбор и парсинг логов, push в Elasticsearch
• Kibana — визуализация
Даёт богатый full-text поиск по логам, но дороже в хранении и CPU, чем Loki.

🔵 Итог: LGTM — дешевле и проще для метрик+логов в облаке, ELK — сильнее, когда нужен реальный полнотекстовый поиск по логам.

В швейцарской компании мы использовали - Prometheus/Grafana, в Dashlane - Elasticsearch/Kibana, сейчас – DataDog (push).

А какой стек вы используете на работе?

@faangiscalling

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.

@faangiscalling

Банк историй для 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

Попрактикую этот метод и поделюсь с вами опытом через пару месяцев.

@faangiscalling

Подготовка по пути на работу (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?

@faangiscalling

Гайд 'How to network at a Meetup' от рекрутера из Меты 🇬🇧 🇺🇸

Если вы хотели, наконец, иметь методичку по тому, как развивать свой нетворк на технических мероприятиях (митапах, конференциях), вот она – от рекрутера из Меты и автора книги про бихейв интервью Остина МакДональда.

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

1. How are you leveraging AI in your current role?
2. What’s your take on (topic the meetup is about)?
3. What do you want to get from being here?


🔗 Полный гайд читать здесь: How to Network at a Meetup

Бонусом идет мой комментарий к статье из моего опыта на десятках митапов в США и Европе.

@faangiscalling

Remote-вакансия Software Engineer в Bending Spoons (до £250К 🇬🇧, до €188К🇪🇺)

Тут снова в новостях миланские ребята из Bending Spoons – они построили многомиллиардную империю, выкупая стагнирующие американские SaaS: Evernote, Vimeo, а недавно вот и Airtable (Excel на стероидах) за $1.285 млрд.

📖 Подробнее про их модель 'купить-сделать layoff-допилить где нужно-увеличить cash-flow' в лонг-риде у Гергея

Компания нанимает удаленно и платит довольно много – вот вакансия software engineer, где опытным кандидатам в Лондоне 🇬🇧 до £250К и в Европе до €188К.

При этом в Европе список стран для удаленки шире границ Евросоюза 🇪🇺 (есть, например, популярные у удаленщиков Сербия 🇷🇸 и Черногория 🇲🇪)

🔗Подаваться тут

Если вы уже собесились туда или там есть знакомые, делитесь обратной связью, интересно.

@faangiscalling

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 интервью перестает казаться чем-то страшным.

Сохраните пост — это хорошая шпаргалка перед собеседованиями. 🔖

@faangiscalling

🙁Как я ошибался: перезапуск интервью после кулдауна

Если честно, я думал, что перезапустить новые интервью после кулдауна будет очень просто, так как у тебя уже есть контакты 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 🙂 Да, без этого никак.

А какой у вас опыт перезапуска интервью после кулдауна?

@faaingiscalling

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 — это, по сути, очень хорошая случайность, чья надёжность держится не на теореме, а на репутации, проверенной десятилетиями попыток её разрушить.

@faangiscalling

DSA, system design и behavioral для финального рывка

Я завершил собирать свою 'боевую' библиотеку для финального рывка подготовки.

Приехали вот только что:
- новая книга Остина МакДоналда из Меты про подготовку к бихейву like a pro. Она неожиданно оказалось цветной внутри, с красивыми акварельными иллюстрациями 😍
- второй том Алекса Ху по system design. Формат подрос как и количество деталей в самой книге, выглядит скорее как v2.0, чем просто второй том. Но формат уже менее travel-friendly
- паттерны решения DSA/LeetCode снова от Алекса. Захотел попробовать альтернативу моей любимой EPIP с глубоким погружением в алгоритмы. У Алекса как и в system design книге много очень схем и картинок, книга-кандидат в refresher перед интервью как один из сценариев.

Посмотрю их в деле, расскажу вам.

@faangiscalling

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 — это не всегда новый алгоритм. Иногда это просто удачно разложить требования по битам. 🙂

@faangiscalling