Как устроено System Design Interview в FAANG?

System Design Interview (SDI) встречается на все позиции программистов, кроме интернов. Для интернов есть только собеседования по алгоритмам. Для всех других позиций у вас будет хотя бы одно SDI.
Оно встречается только на full loop. На скрине будет только собеседование по алгоритмам и иногда будет еще поведенческая часть. На full loop у вас будет поведенческая часть, несколько собесов по алгоритмам и хотя бы одно по System Design.
Для примера, так выглядят собесы в Amazon и Facebook:

Amazon:
Screen - online assessment (онлайн тест на две алгоритмические задачи). Если все ок - full loop, если все плохо - reject, если что-то между могут назначить собеседование с человеком на такие же алгосы.
Full Loop: 3 coding + LP собеседования (три собеседования по 45 минут. На каждом одна задача на алгосы и поведенческая часть на Amazon Leadership Principles). И одно на System Design + LP.

Facebook:
Screen - 45-минутное собеседование по алгосам с человеком на 2 задачи.
Full Loop: 2 собеседования по алгосам, такие же как и Screen, 1 поведенческое, 1 по System Design.

Для уровня Staff Software Engineer будет 2 собеседования по System Design.

Для Junior уровня SDI немного отличается. Оно проще. Вас могут попросить сделать ООП дизайн классов для какой-то задачи.
Для уровней начиная с Middle вас попросят задизайнить какую-нибудь широко известную систему вроде месенджера, новостную ленту, систему бронирования билетов и т.д.
На содержательную часть собеседования у вас будет минут 40.
Т.к. вопрос очень общий, то на него нет одного правильного ответа. А в силу ограниченного времени, вам надо четко установить scope задачи.

Поэтому само собеседования я бы разделил на 6 основных этапов:
1) Получение задачи. Если вас попросили задизайнить какую-то систему, а вы вообще не в курсе, что это такое, то это нужно уточнить сразу. Но обычно, вы будете знакомы с тем, что вас попросят сделать. Вроде задизайнить youtube и т.д. Но если вы не уверены, что это такое, то лучше выяснить сразу.
2) Уточняем и формулируем функциональные требования. Обычно, у системы, которую вас просят задизайнить огромное число функций. Но из-за ограниченного времени, вам скорее всего нужно задизайнить 1-3 ключевые функции. Какие именно, нужно уточнить у интервьюера, если это не было понятно на этапе получения задачи. Даже если вы это поняли, то стоит сформулировать эти требования явным образом, что нам надо поддержать ту или иную функциональность.
3) Уточняем, делаем асампшены по поводу нефункциональных требований. Делаем оценку требуемых ресурсов. Сделайте предположение и согласуйте это с интервьюером по числу пользователей, дневной активности и т.д. На основе этих данных сделайте оценку требуемых ресурсов: число серверов, дискового пространства, требования к пропускной способности сети и т.д. Это нужно сделать, чтобы понимать масштаб компонент. Т.к. соц сеть на 100 пользователей и 3 миллиарда - это два разных приложения.
4) Делаем high-level design. Рисуем диаграмму в виде квадратов, соединенных стрелочками с основными компонентами. Поясняем зачем и почему нам нужна та или иная компонента. Проходим по дизайну и проверяем, что он покрывает все требования.
5) Обсуждаем trade-offs. У каждого подхода есть свои плюсы и минусы. Если вам в голову приходят разные варианты дизайна, реализации тех или иных компонент или использования тех или иных технологий (SQL vs. NoSQL, RPC vs REST vs GraphQL vs Websocket, In-Memory Cache vs NoSQL) то обсудите эти варианты и какие плюсы и минусы у этих подходов и почему вы в итоге выбрали то, что выбрали.
6) Делаем детальный дизайн. В рамках обсуждения с интервьюером, вас могут попросить раскрыть более детально ту или иную часть дизайна. Как вы будете партиционировать данные, какие у вас будут таблицы в базе, как у вас будет распределятся нагрузка, как будет работать система при отказе той или иной компоненты. Проверьте, что ваш дизайн удовлетворяет нефункциональным требованиям (обеспечивает масштабирование, fault tolerance, resilience и т.д.).

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

Примеры внутренних тулов и библиотек Facebook, которые стали общедоступными

Я неоднократно писал, что одной из особенностей работы в FAANG компаниях, является использование внутренних тулов, которые вы больше нигде не встретите. Это библиотеки, фреймворки, базы данных, системы контроля версий, таск тулы, тулы для code review и т.д.
Иногда, некоторые из этих проектов становятся общедоступными. Многие внутренние инфраструктурные технологии Amazon в последствии стали AWS. В Facebook нет своего клауда для внешних клиентов, но есть много внутренних технологий, которые стали общедоступными и open source.

Некоторые примеры, про которые вы возможно слышали или даже использовали:

1) React JS - библиотека JS для создания UI
2) Apache Hive - data warehouse, база данных для работы с Big Data
3) Presto - распределенный SQL движок для работы с Big Data
4) PyTorch - библиотека для ML, используется при создании всех современных моделей AI
5) Llama - open source LLM
6) RocksDB - key-value база
7) GraphQL

И много много других проектов: https://opensource.fb.com/projects.

И еще больше проектов, которые остаются закрытыми.

Как проходили массовые сокращения(layoffs) в Facebook? Часть 3.

Предыдущие части:
Как проходили массовые сокращения(layoffs) в Facebook? Часть 1.
Как проходили массовые сокращения(layoffs) в Facebook? Часть 2.

И в завершении темы layoffs. После первой волны сокращений, акции компании пошли вверх. На следующем перфоманс ревью нам дали много акций, для компенсации падения стоимости акций до этого. Эти акции, в последствии, выросли в цене в 3 раза. На этом, казалось, что кризис пройден.

Но весной 2023 последовала новая волна массовых сокращений. В этот раз она шла в три этапа и было сильно больше информации, какие роли и отделы заденет. Но все же не было информации по конкретным людям вплоть до самого дня X. Сокращения разбили на три месяца. В начале сократили еще не инженерные позиции. Потом очень сильно порезали позиции Data Analyst, TPM/PM, Data Scientists. И наконец разработчиков. В Лондоне полностью закрыли команды, которые относятся к Instagram. Теперь они только в США. Из инженеров сильно порезали Junior и Middle разрабов, их осталось очень мало в компании. Кроме того, уволили всех кто был в bootcamp на позициях ниже Senior. По итогу, многие люди просидели в bootcamp, не присоединившись к команде в течении почти года и были уволены. Также порезали менеджеров. Начали делать иерархию компании более плоской. Чтобы было меньше уровней репортинга между разрабом и гендиром. Многие менеджеры перешли на позиции разработчиков. Хотя надо сказать, что это продлилось не долго. Через полгода снова начали образовываться новые уровни менеджеров и репортинг чейн снова вырос. По факту, уплощения компании не случилось. Из-за телодвижений с уплощением и обратно было много перетасовок команд и людей между ними.
Все это повлияло на чувство Job Security и на культуру в компании не в лучшую сторону. Когда заканчивалась очередная волна сокращений и тебя не увольняли, то было только чувство снятия напряжения, но мотивации и воодушевления это не добавляло. В будущем все эти злоключения щедро компенсировались ростом акций и люди заработали много денег. Но моральное состояние компании в эти годы уже сильно другое.

Я ко второй волне получил Global Talent визу, а еще через полгода - ВНЖ. Поэтому потенциальное увольнение было мне уже не так страшно.

Пишите, что вы думаете об этом. Проходили ли вы сокращения, как на вас это повлияло.

Советы по написанию резюме для FAANG, и не только

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

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

1) Оно должно легко парситься. Желательно делать очень простую и понятную структуру. Не надо всякие сайд бары, фотографии, ворд-арты и т.д. ФИО, контактная информация, саммари, скилы, Job History, Education.
2) Делайте его коротким. 1-2 страницы достаточно. Если у вас меньше 10 лет опыта, не надо писать 2-3 страницы ваших хобби, пет проектов, похвальных листов от бабушки и т.д. Сделайте 1 страничку. Люди не будут долго вчитываться в ваше резюме. Это секунды или пара минут на просмотр. Обратят внимание на ключевые слова: список работодателей и должностей и название универа и специальность.
3) Список работодателей, должностей, название универа, специальность и степень (бакалавр, магистр) должны легко и за несколько секунд считываться при беглом просмотре. Это, вообще, ключевые параметры, которые влияют на выбор вашего резюме. Эта информация должна легко считываться.
4) Делайте упор на последние ~5 лет. Если вы учились в универе 15 лет назад, то просто укажите название, степень, специальность и годы. Не надо расписывать детали. Если вы только закончили универ, то можно уделить этому больше текста, описать темы дипломов, проекты, достижения, если они релевантны вакансии. Если у вас 20 лет опыта, более детально опишите достижения за последние лет 5, остальное очень коротко.
5) Пишите результаты и достижения, а не обязанности. При описании Job History, пишите название компании, должность, команду или отдел и ключевые достижения, релевантные вакансии. Сделал то-то с таким-то импактом. Если вы аплаитесь на Senior, то должны быть проекты, которые вы бы лидили и были ваши контрибьюшены в роудмап, планирование и менторинг. Если на Staff, как вы лидили команду из 8-10 человек, драйвили роудмап, лидили проекты с крос тим или крос орг импактом. Не пишите текст, вроде работал работу, писал код, ходил на митинги. Это очевидно и занимает место в резюме. Нужно писать ваши результаты и чтобы эти результаты соответствовали требованиям вакансии.
6) Не пишите нерелевантные хобби, без существенных достижений. Не надо писать, что вы любите музыку, путешествия и вкусно покушать. Какой у вас любимый цветок и кто вы по знаку зодиака. Но если у вас есть существенные достижения, хоть они и нерелевантные, то указать их стоит. Например, вы участвовали в олимпиаде(по брейкдансу, по бегу), пробежали марафон, поднялись на эверест, стали гроссмейстером по шахматам. Хоть это все не релевантно, это будет говорить про вашу одаренность и способность к наивысшим достижениям. Релевантные хобби я бы писал, только при существенных результатах. Писать, что-то типа, люблю программировать или читать книги по программированию в свободное время, смысла нет. А вот если вы достигли результатов на всемирно известных хакатонах, конкурсах проектов, олимпиадном программировании, написали книгу, выступали на конференциях, контрибьютили в open source и т.д. То это указать имеет смысл.
7) Сделайте ваше основное резюме, и кастомизируйте его под вакансию. Для каждой вакансии, сделайте копию вашего резюме и немного доработайте его под вакансию. Пройдитесь по требованиям вакансии и убедитесь, что у вас на все/большинство пунктов есть что-то в резюме: в достижениях в рамках работы, в скилах, в образовании и т.д.
8) Имейте профиль на linkedin и держите его актуальным. В России это не нужно, но если вы хотите работать в зарубежных компаниях, то это обязательно. Также укажите его в контактных данных в резюме. Есть шанс, что вам сам на linkedin напишет рекрутер из FAANG, если его заинтересует ваш профиль или у вас много контактов из FAANG.

Что сейчас с хайрингом в FAANG?

С момента наибольшего падения в конце 2022 и начале 2023, число вакансий выросло примерно на треть. Но оно не идет вверх, а зафиксировалось в одном положении (https://www.trueup.io/job-trend).

Facebook сейчас хайрит достаточно хорошо. Число сотрудников практически вернулось до состояния перед сокращениями. Только с начала года я провел более 40 собеседований.
Судя по Linkedin вот такое, примерно, число открытых вакансий в основные Big Tech компании (через / указал число вакансий с тайтлом Software Engineer):

Facebook: 2829/761
Google: 4427/1313
Apple: 0/0
Amazon: 31696/5446
Microsoft: 3854/1245
Netflix: 446/112
Uber: 949/290

Всего: 44201/9167

Текущие стартовые оферы в США для junior/middle/senior:

Facebook: $145k/$234k/$353k
Google: $149k/$222k/$306k
Amazon: $140k/$220k/$337k
Microsoft: $133k/$159k/$203k
Uber: $135k/$248k/$408k
Apple: $119k/$176k/$268k
Netflix: $173k/$263k/$442k

В Европе эти числа в 1.5-2 раза ниже, в зависимости от локации. Для Лондона это примерно в 1.5 раза.
Моя зп в этом году в Лондоне по текущим ценам на стоки: £509k/$663k

По итогу, рынок не на пике, но из ямы вылез.

Наткнулся на это резюме на linkedin. Недавно, я писал свои рекомендации по написанию резюме: https://t.me/faangmaster/426

Какие есть минусы этого резюме:

1) Оно плохо парсится. Тут есть сайд бар. Тут есть фото. Фото, никого не интерисует в вашем резюме на инженерные позиции.
2) Нет достижений. Есть должностные обязанности. Работала работу, получала зп, ходила на митинги. Нужны достижения и результаты.
3) Саммари не продает. Прочитав самари человек должен понять, почему мне надо нанять его, а не кого-то другого.
4) Километровый стек технологий. Можно его не писать для каждой работы. А только в разделе скилов. И писать то, в чем вы действительно разбираетесь и что нужно работодателю. У человека скилов за 3 года опыта в резюме больше, чем мое резюме.

Что вы думаете, про такое составление резюме?

Советы по написанию достижений в резюме

В продолжении темы резюме. Пост о том, как писать резюме: Советы по написанию резюме для FAANG, и не только

Почему нужно писать именно достижения, а не должностные обязанности или список проектов ?

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

Список проектов — это уже лучше. Описание проектов позволяет подчеркнуть уникальность вашего опыта. Однако простое перечисление проектов не даёт понимания вашей конкретной роли в них, того, что именно вы сделали. Также не ясен результат или влияние вашей работы (impact). Нередко остаётся неясным, был ли проект сложным, какие трудности пришлось преодолеть и т.д.

Как писать достижения?
Прежде чем описывать свои достижения, ознакомьтесь с методикой STAR. Она используется в том числе и на самом собеседовании (в поведенческой его части). Такой же подход можно применять на performance review в рамках вашей компании для оценки производительности сотрудников.
Если кратко, то вам нужно описать контекст проекта и в чем была его сложность. В чем была цель, что сделали именно вы для ее достижения и какой получился результат.

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

Например,

Вместо: Занимался баг фиксами
Для Junior/Mid: Используя профилирование памяти, обнаружил утечку памяти, которая оставалась незамеченной в течение двух месяцев в продакшене. Предложил и реализовал способ её устранения с использованием XXX, что привело к увеличению пропускной способности приложения на 30%. Также предложил и реализовал YYY для предотвращения подобных проблем в будущем, а также создал метрики и алармы для их быстрого обнаружения.
Senior/Staff: Работал с инженерами из нескольких команд, чтобы выявить блокеры, которые снижают эффективность при работе над высокоприоритетными задачами саппорта, которые влияют на SLA/SLO ключевых компонент приложения. Предложил и драйвил реализацию XXX, что сократило время обнаружения и устранения проблем на N% в 4 командах.

Вместо: Принимал участие в напиcании кода, code review и дизайне.
Junior/Mid: Реализовал в составе команды из 4 человек функцию сортировки магазинов по удаленности от покупателя, которой пользуются 15 миллионов пользователей в месяц.
Senior/Staff: Предложил, сделал дизайн/архитектуру и драйвил реализацию командой из 4 человек функцию сортировки магазинов по удаленности от покупателя, которой пользуются 15 миллионов пользователей в месяц.

Гайд по подготовке к собесу в FAANG

Написал, в рамках одной статьи на dev.to, гайд по подготовке к собесу в FAANG на основе уже опубликованных постов в этом тг канале.

Как подготовиться к собеседованию в FAANG/Big Tech

В основном, гайд сделан на основе, следующих моих постов:

Варианты подготовки к собеседованию в FAANG/около FAANG для разных уровней текущей подготовки Часть 2 , Часть 3, Часть 4

Также, смотрите подборку постов, не связанных с разбором задач, но полезных, тем кто думает про релокацию и работу в FAANG/Big Tech:

Подборка постов в канале, не связанная с задачами. Часть 1
Подборка постов в канале, не связанная с задачами. Часть 2

А также подборки с моими разборами реальных задач с собеседований на позиции Java разработчика, которые я уже публиковал в этом канале (которые встречались в том числе в Яндекс, Mail ru, инвест банки):
Подборка вопросов и ответов для подготовки к собеседованию на Java программиста

А также мои разборы алгоритмических и system design задач в FAANG:

Подборка статей, которые я уже написал и опубликовал в этом канале по system design

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

Все такие подборки можно найти в закрепленных постах в этом канале.

Запись Mock Interview

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

https://youtu.be/hjjGDODYJ6M

Краткий сказ о том, как AI заменяет людей.
P.S. если что, там 3 буквы r и в другом месте.

Собеседовал сегодня кандидата из Сингапура

У кандидата 16 лет опыта, позиции за последние 10 лет выглядят примерно так: CTO, Technical Director, CEO и т.д. Правда, компании, которые я первый раз вижу.

Я ничего не понимал, что он говорит. Акцент настолько сильный, что почти ничего не разобрать. Да и не сказал бы, что он быстро и легко говорил, и это мне было сложно понимать акцент. Ему в целом, размышления на английском не давались. Я понимал только код, который он писал на Go. Задачки решил так себе. В конце вопросы почти не задавал. Точнее он спросил один вопрос, который я не понял сначала. После уточнений, я понял, что это был вопрос с претензией. Вроде, как часто, в реальной работе, вы решаете задачи, подобные этим.

Как по мне, если вы не принимаете правила игры, то просто, не надо собеседоваться в FAANG/Big Tech. Я постоянно встречаю не только на собеседованиях, но в качестве постов на линкенине, что так не надо собеседовать. Только проблема, что они не пишут, как надо, и почему это будет работать в масштабе FAANG компаний.

CAP Theorem
#systemdesign

Написал статью про CAP Theorem в распределенных системах:

https://dev.to/faangmaster/cap-theorem-413p

Вышло новое интервью с Дороничевым

Это бывший Director в компании Google, который приложил руку к youtube mobile и stadia.

Позиция Director это L8 уровень. Что примерно эквивалентно позиции Principal в инженерной карьерной линейки. У Director в подчинении Senior Manager'ы и Senior Staff инженеры.

Он ушел из Google и говорит про свое самое дорогое письмо в жизни. Ему пришлось оставить 6.8 миллионов еще не завесченных стоков(еще не выплаченных акций). Я могу это понять, у меня конечно не 6.8 миллионов, но чуть больше миллиона. Это и есть так называемая "золотая клетка".

https://youtu.be/zNpTHznYMW4?si=rxlajhUXvF8gH72z

Bloom Filter
#systemdesign

Написал статью про Bloom Filter: https://dev.to/faangmaster/bloom-filter-4f4e

Собеседовал только что многократного победителя соревнований на Kaggle

Текущая позиция кандидата - Staff ML Engineer. В прошлом у него несколько побед на платформе Kaggle. Это такой аналог https://www.topcoder.com/ или https://codeforces.com/, только для Data Scientists и ML.

На ML позиции, кроме собеседования, собственно, по ML, есть собеседование по кодингу.

Кандидат мгновенно придумывал правильные решения, но код был трехэтажным, без необходимости усложненным. То, что называется "индусский код". По всем осям я поставлю выше среднего (strong), но по кодингу - на грани.

Кроме индусского/спагетти-кода (запутанный, трудно понимаемый, слабоструктурированный код, с большим числом if-else и т.д.) бывает:

Пахлава/Лазанья код - когда чрезмерно много уровней абстракции для данной задачи. Я бы весь Spring назвал Лазанья кодом.
Равиоли-код - огромное число независимых компонентов. Легко понять отдельный класс, но не весь проект в целом.
Катамари-код - изначально нормально написанный код, но постепенно обросший костылями и новой функциональностью, простым добавлением кода, без редизайна.

А какой код у вас в компании?

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

Что я думаю про это?
Краткий ответ: и да и нет. Но скорее нет.

Собеседования по алгосам, в первую очередь, решают две другие задачи:
1) Стандартизация собеседований.
2) Минимизация false positive.

Практически все крупнейшие IT-компании мира (FAANG/Big Tech) собеседуют одинаково. Эти компании нанимают гигантское число людей каждый год. А число собеседований измеряется миллионами в год.
Поэтому если вы готовитесь к собеседованию по алгосам, это не значит, что вы эксклюзивно закомитились в одну конкретную компанию и потратили год или два на подготовку. Вы, в целом, будете готовы к такому типу собеседований и сможете попасть в одну из десятков крупнейших компаний мира.
Но рациональное зерно в этом есть. Это, особенно, касается локальных IT-рынков. Где большинство компаний так не собеседуют, а 2-3 собеседуют именно так. Условный Яндекс или Mail ru vs местный аутсорсер.

Что касается, реальных задач такого собеседования:
1) Стандартизация собеседований. Вы проводите невероятное число собеседований. Вам нужно масштабировать этот процесс. Вам нужно иметь универсальную рабочую метрику. Если каждый будет собеседовать кто в лес, кто по дрова, то очень быстро уровень людей в компании станет приближенным к среднему уровню по рынку. А хайринг лучших - это ключевой аспект успеха всех FAANG/Big Tech компаний. Это не какие-то супер процессы или культура инжиниринга, и не культурные ценности компании. Однотипные собеседования по одним и тем же критериям, а также проведения нескольких собеседований разными людьми, позволяют минимизировать субъективность.
2) Минимизация false positive. False Positive - кандидаты, которые прошли собеседование, но стали плохими сотрудниками. Большие компании стремятся минимизировать такие случаи. Они легко мирятся с false negative. Это такие кандидаты, которые не прошли собеседование, но могли бы стать успешными сотрудниками. Из-за того, что число кандидатов астрономическое - не наняли одного хорошего сегодня, найдем другого завтра. Кандидаты, которые хорошо проходят кодинг собеседования, с большей вероятностью становятся хорошими сотрудниками. Как минимум, так считается. Минимизация false positive достигается также несколькими независимыми собеседованиями, которые проводят разные люди и дают фидбек независимо. Чтобы пройти собес - нужно пройти все. Это минимизирует субъективность.

Связанная мысль, которая также приводит к мнению, что такое собеседование ничего кроме желания попасть в конкретную компанию не показывает - любой может надрочить такие задачи и все также проходить, а мне просто лень надрачивать такие задачи, т.к. они никак не связанны с реальной работой. Это сильное утверждение. По аналогии можно сказать, что каждый школьник может написать ЕГЭ по всем предметам на 100 баллов просто надрочив задачи, но просто не хочет. Или каждый может выиграть межнар по математике или информатике, но просто не хочет. Или, что каждый может стать топ 10 на topcoder, но просто не хочет. Или каждый может стать гроссмейстером по шахматам, просто не хочет.
На самом деле, объем теории, необходимый для решения алгосов можно изучить за 1 неделю. А вот научиться навигироваться во время решения задачи, преобразовывать условие в алгоритм, а алгоритм в реальный код - не такая простая задача. Такие задачи позволяют за 15-20 минут проверить многие аспекты мышления в плоскости программирования в чистом виде. Да, эти задачи не проверяют способность реальной работы, т.к. реальный код это на 90% просто бойлер плейт код или код с очень тривиальной логикой.

Пишите в комментариях, что вы думаете про это.

Подборка алгоритмических задач с решениями и описание алгоритмов уже опубликованных в этом канале
#interview #собеседование #алгоритмы #подборка

Обновление подборки.

Общие статьи:
1) Как выбрать язык программирования для алгоритмического собеседования?
2) Как решать алгоритмические задачи на подготовке, чтобы это было эффективно
3) Как не забыть решения задач и алгоритмы
4) Шпаргалка по основным алгоритмам для алгоритмического собеседования
5) Шпаргалка по Java для алгоритмического собеседования
6) Подборка из easy задач для начала подготовки к алгоритмическому собеседованию.
7) Сбалансированная подборка из 100 задач для подготовки к алгоритмическому собеседованию.
8) Видео: mock собеседование по алгоритмам в FAANG

Two Pointers:
1) Проверка на палиндром.
2) Усложненная версия проверки на палиндром.
3) Merge Two Sorted Arrays
4) Самая длинная палиндромная подстрока
5) Удалить дубликаты в отсортированном массиве
6) Видео: Merge Intervals
HashTable:
7) Two Sum
8) Видео: Сгруппировать анаграммы
9) Задача с собеседования в Google. 939. Minimum Area Rectangle
10) Задача с собеседования в Microsoft: Самое большое палиндромное число
Stack:
11) Проверить скобочное выражение.
12) Удалить минимальное число скобок, чтобы сделать скобочное выражение правильным
Sorting:
13) Первый пропущенный положительный элемент массива
LinkedList:
14) Удалить n-й элемент с конца в односвязном списке
15) Deep Copy списка со ссылкой на случайный элемент.
BinarySearch:
Описание алгоритма BinarySearch.
16) Пропущенный элемент в отсортированном массиве.
17) Пиковый элемент.
18) Число итераций в бинарном поиске.
19) Первая плохая версия
DFS:
Описание алгоритма DFS.
20) Flood Fill.
21) Видео: Число Островов
BFS:
Описание алгоритма BFS.
22) Проверить полноту дерева.
23) Обход дерева по уровням.
24) Remove Invalid Parentheses
Топологическая сортировка:
Топологическая сортировка
25) Видео: Top k elements
Binary Tree:
Алгоритмы обхода двоичного дерева
26) Invert Binary Tree
27) BranchSums
28) Максимальная высота дерева
29) Максимальная сумма пути в бинарном дереве
30) Сумма элементов бинарного дерева поиска в диапазоне значение
31) Удалить вершины в дереве и вернуть оставшийся лес/forest
Dynamic Programming:
Основные этапы решения задач на динамическое программирование Top-Down методом
32) Top Down подход на примере задачи про ступеньки
33) Задача на динамическое программирование. Разделение на слова.
34) Количество дождевой воды
35) Bottom-up подход: разменять деньги
36) Видео: Longest Increasing Subsequence
37) Лучшее время для покупки и продажи акции
Sliding Window
38) Contains Duplicate ||
39) Наибольшая подстрока без повторяющихся символов.

Подборка статей, которые я уже написал и опубликовал в этом канале по system design
#systemdesign

Обновление подборки

Общие статьи:
Как устроено System Design Interview в FAANG?

1) Load Balancers 1
2) Load Balancers 2
3) Load Balancers 3
4) Consistent Hashing
5) Data Partitioning/Sharding
6) Design Web Crawler
7) Дизайн Uber/Яндекс Такси
8) Дизайн новостной ленты соцсети типа Twitter или Facebook
9) Availability
10) Consistency
11) Дизайн мессенджера Telegram
12) Обработка ошибок при вызове другой компоненты
13) Распределенный кэш. Часть 1.
14) Распределенный кэш. Часть 2.
15) Распределенный кэш. Часть 3.
16) Характерные числовые характеристики, которые нужно знать для System Design собеседования
17) Дизайн Google Maps
18) Некоторые подходы к архитектуре приложений в Amazon
19) Какие AWS сервисы мы часто использовали, когда я работал в Amazon?
20) Какие базы данных используются в FAANG?
21) Memcached vs Redis
22) CAP Theorem
23) Bloom Filter