Задача на system design: Задизайнить мессенджер по типу Telegram или WhatsApp.
#systemdesign
Задача. Задизайнить мессенджер по типу Telegram или WhatsApp.
Решение. Описал тут: Дизайн мессенджера Telegram

Что такое CDN?
#systemdesign

Хорошая и короткая статья на сайте AWS о том, что такое CDN(content delivery network): Content Delivery Network

Эта технология незаменима для быстрого доступа, например, к медиа контенту. Картинкам, видео и аудио. Такие сервисы как Netflix, youtube, instagram опираются на CDN для быстрого доступа к медиа контенту.

Обработка ошибок при вызове другой компоненты
#systemdesign

Допустим у вас есть две компоненты, и одна компонента вызывает другую. Например, у вас есть сервис Users Service (сервис пользователей) и он вызывает сервис Orders Service (сервис заказов) для получения списка заказов для конкретного пользователя. Или ваша компонента читает/пишет сообщения из очереди типа AWS SQS или Rabbit MQ, или вы читаете/пишите из стрима типа Kafka или AWS Kinesis. Если вторая компонента не отвечает или бросает ошибки, то нужно соответствующим образом реагировать на такие ситуации.

Какие могут возникнуть проблемы?
1) Не удается установить соединение. Проблемы сети или компонента лежит.
2) Соединение удалось установить, но вызываемая компонента не возвращает никакого результата длительное время.
3) Соединение удалось установить, но вызываемая компонента возвращает ошибку.
4) Соединение удалось установить, но в процессе выполнения операции соединение прервалось.
5) Установление соединения занимает очень длительный период времени, но не возвращается ошибка о том, что сервер не доступен, т.к. сервер постоянно занят.
6) Сервер доступен, но он бросает ошибку по типу Throttling Exception, если для компоненты настроен Throttling (например, максимальное число вызовов в единицу времени или максимальное число соединений и т.д.)

Как можно реагировать в подобных случаях для достижения low latency, fault tolerance, resilience и availability?

Описал тут: https://telegra.ph/Obrabotka-oshibok-pri-vyzove-drugoj-komponenty-10-24

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

Global Talent Visa UK

Если вы программист и хотите переехать в UK для работы и жизни, то в большинстве случаев вам вначале нужно найти работодателя, который может предоставить вам визу. Тип этой визы будет Skilled Worker Visa. Она позволяет вам прожить в UK 5 лет, через 5 лет получить ILR (вид на жительство). Прожить еще один год по ILR и получить гражданство UK.
Минус такой визы в том, что вы привязаны к работодателю. Если вы захотите сменить работодателя, вам нужно найти другого работодателя, кто может быть спонсором такой визы. Далеко не все работодатели в UK могут предоставить такое спонсорство. Более того, если вас уволят (например, в результате сокращений (layoffs)), у вас будет 60 дней, чтобы найти новую работу. Иначе вам нужно выехать из страны. Вы также не можете заниматься бизнесом или консультированием имея эту визу или жить в UK не работая.

Но в UK есть другой тип визы: Global Talent Visa. Она позволяет приехать и жить в UK не имея работодателя. Вы можете работать, заниматься бизнесом и консалтингом в UK. При этом вы не привязаны к работодателю. Она также сокращает время для получения ILR c 5 до 3 лет. Через 3 года жизни в UK вы можете получить вид на жительство и еще через 2 - гражданство.

Вначале я переехал в UK по Skilled Worker Visa. Но после я подался и получил Global Talent. Для Global Talent нужно подготовить много документов, но это стоит того. Основные документы: отзывы от высокоуровневых менеджеров (уровни CEO, CTO, VP, Director) с ваших прошлых мест работы о ваших достижениях в этих компаниях, какие-то подтверждения этого + подтверждения ваших контрибьюшенов вне работы в Digital Sector. В качестве таких контрибьюшенов можно предоставим ваши выступления на IT конференциях, публикации на известных IT форумах, видео на youtube с вашими выступлениями на IT темы, контрибьюшены в open source и т.д. Если у вас это все есть, то я сильно рекомендую вам получить именно такую визу.
Если вы скажем можете получить отзывы от работодателей, но контрибьюшенов вне работы у вас нет, то вы можете воспользоваться услугами сторонних компаний, которые помогут вам это организовать. Например, есть компания https://www.immigram.io/ У них есть связи с разными площадками, которые помогут вам где-то выступить, где-то написать статью и т.д. И в целом подготовить пакет документов для Global Talent Visa.

Число вакансий в tech индустрии медленно, но растет

В соответствии с https://www.trueup.io/job-trend число вакансий достигло дна в марте 2023 года и начало медленно расти.

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

Googleyness interview

В Google поведенческое собеседование называется Googleyness interview. Оно частично похоже по поведенческое собеседование в Amazon, где нужно привести примеры из карьеры, где вы демонстрировали те или иные Amazon Leadership Principles. В Google принципы частично пересекаются, но есть различия. Вот хороший канал, где hr из Google рассказывает про это собеседование, что такое Googleyness и как к нему подготовиться. Пригодится и для подготовки к поведенческому собеседованию в другие компании https://youtu.be/TWFs3dxfiOc?si=ctE_Zx5FI5Dv53pM

Задача с собеседования: сгруппировать анаграммы

Завел youtube канал, записал видео разбора задачи с leetcode. Т.к. это мое первое видео, качество может храмать: https://youtu.be/QvhS-8qScvo?si=LJxEHy1tRrceavo5

Пишите свой фидбек на видео в комментариях.

Где я был предыдущие пару недель

Учил историю, культуру и государственное устройство UK. Это было нужно для сдачи экзамена Live in UK Test. Я его наконец вчера сдал и теперь знаю всех жен Генриха 8, их порядок, его детей и причины развода. Этот экзамен нужно сдавать всем, кто хочет получить ILR (ВНЖ) в Великобритании. ВНЖ в UK можно получить после 5 лет жизни в UK или после 3 лет, если вы обладатель Global Talent визы (мой случай).

Случай на собеседовании в FAANG

Компания, в которой я работаю, возобновила активный набор сотрудников, после практически годовой паузы. Я снова сейчас активно собеседую кандидатов.
Собеседования все также проходят online, как и в ковид. Я недавно собеседовал кандидата, на позицию E6 (Staff Software Engineer, с зп от $ 500 000 в USA). И мне кажется, что я первый раз серьезно заподозрил кандидата в читерстве. Во-первых, он периодически переводил глаза, во время написания кода. Но это еще ничего не значит, т.к. я не вижу его сетап рабочего стола и не могу точно сказать, куда он смотрел. А во-вторых, Он ничего не уточнял в условии задачи. А обычно, задачи формулируются так, чтобы там была какая-то неопределенность в формулировке, чтобы посмотреть как кандидат коммуницирует и работает с неопределенностью (ambiguity). Он же вообще мало говорил, ничего не уточнял. Словно зависал на время и потом словно ниоткуда писал оптимальное решение, но не обязательно на те условия задачи, которые я имел ввиду. При этом не поясняя решение до того, как его написать и обсудить его, проанализировать плюсы и минусы решения. А просто его писал, периодически поглядывая в другой экран. А потом с трудом пытался его объяснить.
Кандидат, конечно же, был зареджекчен. Но не потому, что читерил. Доказательств этого у меня нет. А по communication. На алгоритмическом собеседовании основное это не "решил или не решил" задачу. На нем кандидат оценивается по 4 осям: communication, problem solving, coding, testing. А задача используется как способ получить сигналы от кандидата по этим осям. Если вы ничего не объясняете, не уточняете, не реагируете на вопросы и подсказки, но при этом вывалили откуда-то правильный код, то вы не пройдете ни по одной из осей.

Задача с собеседования в Google: Слияние интервалов

Записал разбор еще одной задачи с собеседовая: https://www.youtube.com/watch?v=b7UuqAIrpgM

Ссылка на leetcode: https://leetcode.com/problems/merge-intervals/

Incident management в Amazon

В любых софтверных сервисах и продуктах случаются outages, полные или частичные. Когда сервис падает и становится недоступным или часть функционала перестает работать.
Как в Amazon реагируют на такие ситуации, как обнаруживают, что делают во время инцидента и после него?
В Amazon все разработчики без исключения участвуют в так называемом oncall. Т.е. по очереди дежурят в поддержке работы сервисов, которые они разрабатывают. Обычно это длится одну неделю раз в в 1.5 - 2 месяца. В течении этого времени они реагируют на тикеты и таски связанные с саппортом продукта и участвуют в их митигации (именно митигации, а не починке root cause). Все сервисы производят огромное число метрик, на которые созданы alarms, которые в случае проблем автоматически создают таски. Например, это может быть AWS Cloudwatch. Тикеты и таски имеют свой severity. Самые важные автоматически приходят на рабочий телефон и очень громко звенят(paging). В том числе это может произойти ночью. В таком случае нужно принять этот paging в течении короткого промежутка времени и надо начать смотреть тикет. Если это не сделать, то такой alarm начнет будить вашего менеджера, потом менеджера его менеджера. Вплоть до CEO если это очень серьезный инцидент и никто не реагирует.
Далее oncall смотрит тикет и принимает шаги по митигации (stop the bleeding, не починки). Например, делает rollback до последней стабильной версии, восстановление из backup, перезагрузку кластера и тому подобное.
При этом активно комментирует все свои действия в тикеты, т.к. часто это может повлиять на другие компоненты и сервисы, которые активно пишут, что они тоже заафекчены. Иногда перебои в Amazon приводят к outage в других продуктах. Например, однажды outage в AWS S3 привел к недоступности видео в Netflix. Иногда происходит мониторинг медиа типа twitter, на предмет жалоб на outage. Как только инцидент был замитигирован(stop bleeding) начинается формирование документа COE ревью, который призван помочь в предотвращении таких инцидентов в будущем. Одна из особенностей как митигации так и COE ревью - no blame culture. Т.е. не заниматься поиском виноватых людей, а поиском дыр в системе, процессах, которые позволили этому случиться. Про COE ревью детально напишу в следующих постах.

COE Review в Amazon

В продолжении к посту: https://t.me/faangmaster/217

После серьезного инцидента, как правило, пишется документ под названием COE Review. Серьезность инцидента зависит от того, какой был impact, какой сервис был заафекчен, какая функциональность перестала работать и т.д. Обычно это делается для инцидентов уровня LSE (Large Scale Event), Sev0, Sev1, Sev2, Sev3. Sev0 - это, обычно, значит, что перестала работать функциональность, которая непосредственно влияет на конечного пользователя (Tier0 сервис). Sev3 - непосредственно влияния на конечного пользователя нет, но могут быть отсроченные небольшие эффекты на пользователя или небольшие потери для бизнеса.
На написание и ревью документа отводится ограниченное количество дней. У документа есть owner, который работает над документом, но ему могут помогать и другие люди.
Основная цель документа - понять, что и почему произошло и что можно сделать, чтобы это не произошло в будущем (prevention).
Из чего состоит документ:

1) Into. Краткое summary. Описывается на абзац, что произошло, какой impact в цифрах (например, сервис был offline 2 часа, что привело к потере ~40 миллионов долларов прибыли), как обнаружили, как замитигировалли, какой root cause.

2) Impact. Более детально описывается влияние данного инцидента. Приводится расчет убытков, приводятся метрики, графики с детальным анализом, запросы и т.д.

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

4) Detection. Описывается как было обнаружено, что что-то не так. Какие метрики, alarms позволили это обнаружить. С какой задержкой это было обнаружено.

5) Mitigation. Какие шаги были предприняты, чтобы замитигировать проблему (stop the bleeding). Сколько это заняло времени и почему.

6) Five whys. Позволяют ответить на вопрос, что послужило реальной причиной (root cause).

7) Monitoring/Detection Improvement. Что можно сделать, чтобы быстрее в следующий раз обнаружить подобную проблему (улучшить метрики, алармы, добавить независимые методы детектирования и т.д.)

8) Mitigation Improvement. Что можно улучшить, чтобы быстрее митигировать проблему (улучшить или добавить автоматические системы, которые задетектируют проблему и автоматически сделают rollback, улучшить качество runbooks, добавить метрик, dashboard’ов и т.д.)

9) Root Cause Fix. Что нужно сделать, чтобы починить root cause.

10) Prevention. Какие шаги нужно предпринять, чтобы это не случилось в будущем.

Все это описывается, проходит цепочка ревью (внутри команды, внутри организации, в целом в компании), происходит публикация. Другие люди, могут найти этот документ в общей системе по ключевым словам и прочитать то, что произошло и как это можно починить, чтобы использовать в своих целях. Далее все эти action items реализуются разработчиками. В Amazon этому уделяется серьезное внимание, но и процесс очень сложный и бюрократический. В Facebook он намного более легковесный.

Задача с собеседования: Число островов
#dfs #алгоритмы #собеседование

Записал еще один видос с разбором задачи на dfs: https://youtu.be/dXeoNguCK2k?si=2Wj0m5PgNwbAl7Ce
Видео длинное, потому что я написал несколько вариантов решения (рекурсивное, со стеком, с и без visited)

Хорошее видео для тех, кто хочет написать свой LLM(то что использует ChatGPT) с нуля: https://youtu.be/kCc8FmEb1nY?si=65pUV5i45MTX_U8T
Автор канала один из основателей OpenAI и долгое время работал в Tesla AI.

Сделал еще один ролик для youtube про ресурсы для подготовки в виде топа: https://youtu.be/DnQdKvlosKk?si=5j3UN6RSz-wngo2z

Для тех, кто интерисуется шахматами.
Недавно, 14 чемпион мира по шахматам Владимир Крамник опубликовал статистику игр Хикару Накамуры на платформе chess.com. Из нее следует, что Хикару набрал 45.5 очков из 46 в 46 играх. Все это с намеком на то, что Хикару читер. Я написал небольшую програмку, которая проводит симуляцию и рассчитывает вероятность того, что в большой выборке игр можно найти последовательности из 46 и более побед при заданной вероятности выиграша. С параметрами: выборка 10 тысяч игр, вероятность выиграша (88%, Хикару играл с противниками на ~350 пунктов ниже) и ищем серии из 46 и более выиграшей подряд. У меня получилось вероятность этого около 96%. Но она быстро падает с уменьшением вероятности выиграша в каждой игре. Что думаете вы? Код выложил тутhttps://github.com/faangmaster/kramnik/blob/main/Main.java

Развитие истории можно посмотреть по последним роликам в каналах Хикару https://youtube.com/@GMHikaru?si=ddMRyd-avgVNR0h5 и LevitovChess https://youtube.com/@LevitovChess?si=eB5u3O1kAzDZSP22

Основные ошибки на собеседовании в FAANG

Пару месяцев назад возобновился активный найм в FAANG компании. Я провожу по паре собеседований в неделю и выделил несколько наиболее распространенных ошибок, которые не позволяют кандидатам пройти собеседование.

1) Отсутствие должной подготовки. Некоторые кандидаты вообще не готовятся к подобным собеседованиям. Это заметно на phone screen, а также на system design если они прошли phone screen. Это несмотря на то, что мы описываем весь процесс до самого собеседования и даже присылаем материалы для подготовки. Мы хотим, чтобы кандидат показал свой лучший перфоманс на собеседовании, свой максимум. Пройти такое собеседование без подготовки практически не возможно. Только если вы уже готовились к нему когда-то ранее, или у вас бэкграунд топового олимпиадника + большой практический опыт в создании high load систем. Или вы гений с IQ 150-160. Поэтому если вы действительно хотите собеседование пройти - нужно уделить время подготовке.

2) Кандидаты не задают уточняющие вопросы, не уточняют требования. Все задачи обычно формулируются так, чтобы они не были однозначными, особенно system design. Ожидается что вы будете задавать уточняющие вопросы, уточнять требования или выдвигать свои предположения и спрашивать, могу ли я это предположить для решения задачи. Некоторые кандидаты ничего не уточнят и сразу начинают решать. Очень часто это приводит к тому, что они решают другую задачу, не которую хотел интервьюер. Это приводит к потере времени и негативному фидбеку по communication оси.

3) Кандидаты не могут без компьютера продебажить свой код и найти в нем ошибки. После того как код написан, мы просим протестировать код путем подбора примеров (test cases) и в ручном режиме пройтись по коду и проверить правильно ли он сработает или нет. Некоторые кандидаты не способны проверить работоспособность своего кода без запуска его на компьютере. Даже если им указываешь на конкретный пример, на котором это работать не будет, они все равно не могут понять почему. Из-за этого они получают слабый рейтинг по оси verification

4) Не реагируют на подсказки и наводящие вопросы. Иногда кандидаты вообще не реагируют на интервьюера и продолжают погружаться в свои рассуждения и мысли. Интервьюер делает подсказки не для того чтобы вас отвлечь и мешать вам думать и решать задачу. Он это делает, когда видит, что вы застряли или вы думаете куда-то не туда. Кандидаты, которые могут быстро среагировать на наводящий вопрос или подсказку могут быстро разблокировать себя и решить задачу.

5) Нерационально расходуют время. На кодинг собеседовании иногда кандидаты начинают тратить время на совершенно второстепенные проверки в коде, писать зачем-то комментарии к коду, рассуждать подолгу над именами переменных. Расходуют на это почти все время и не могут приступить к решению собственно самой задачи. Обычно, никакие проверки на input делать не надо. Это можно просто коротко спросить интервьюера, могу ли предпологать, что input валиден? ответ будет да в 99% случаев и просто можно его не проверять. Комментарии писать тоже не нужно, просто озвучивайте свои мысли по ходу написания. Интервьюер поймет что и зачем вы написали. Впечатлять интервьюера ненужными комментариями в коде не надо.

6) На system design кандидат не драйвит обсуждение. На system design кандидат должен быть тем, кто драйвит дискуссию. Это не собеседование, где интервьюер у вас должен спрашивать вопрос-ответ. Тут вы должны проявить себя в качестве лидера и вести дискуссию. Как на реальной работе, когда вы дизайните систему или API, вы должны описать и продать свой дизайн, а не у вас его выуживать в час по чайной ложке. Если вы будете работать в режиме вопрос ответ, то в лучшем случае скажут что вы не соответствуете уровню, на который вы собеседуетесь.

7) На поведенческом собеседовании не могут привести примеры из опыта, соответствующие вашему уровню. Если вы аплаитесь на senior или staff, но во всех ответах на вопросы вы приводите примеры, которые этому уровню не соответствуют это может послужить причиной или реджекта или в офере на более низкий уровень. Примеры проектов, которые вы лидели, примеры конфликтов, которые вы разрешили должны соотвествовать. Если это проекты или конфликты уровня staff, то они должны затрагивать множество команд, а не 2-3 человека в рамках одной команды.