Ассаляму алейкум ва рахматуллахи ва баракатуху!

Ид аль-Адха мубарак!
Пусть Аллах примет от вас и от нас благие дела.

Я все ещё достаточно занят, поэтому через неделю проведём System Design Interview для бэкенд разработчиков.

Пусть желающие поучаствовать отпишутся в комментариях.

Как и обещал, сегодня проводим System Design Interview на бекенд разработчика

Начинаем в 19:00 по Москве, просьба не опаздывать, будет жарко 🔥

Ссылка на сегодняшнее интервью: https://us04web.zoom.us/j/9642129552?pwd=OWVHV3NXdUNqSnNaVXd1Z0podnRmQT09

Когда пройдет 40 минут, подключайтесь по той же ссылке

System Design Interview: https://youtu.be/tKYiPuxZ9EI

Поделитесь комментариями, расскажите, насколько это было полезно и стоит ли еще проводить подобные интервью.
Если считаете, что контент полезный, лайк, шер, сабскрайб 🙂

https://medium.com/flo-health/notification-sending-pipeline-at-flo-2e4621a6ab82

Небольшой рассказ о том, как построить пайплайн, который будет делать миллионы пушей. Полезно для system design мышления

Про Ownership

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

Это далеко не последний пост про ownership, но для затравки распишу свое видение уровней сковзь его призму:
1. Джун — владение на уровне фичей. Количество сильно варьируется от задач, но на вскидку 3-5 фичей, которые активно потребляют время
2. Мидл — владение на уровне бизнес-процессов, которые обычно в себе объединяют множество фичей. Стоит отметить, что владеть бизнес-процессом, включащим в себя 5 фичей и владеть 5-ю фичами — это не одно и то же
3. Синьор — владеет целыми областями. Тут много подробностей и говорить будем отдельно

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

🔥 Топ 5 ошибок джунов на ревью 🔥

1. Описание к PR-у. Ревьюеры мысли не читают, сделайте нормальное описание и приложите нужные ссылки.
2. Тестирование своего кода. Бывает вижу, что код написан с явными ошибками, которые тот час бы выявились во время тестирования. Иногда вроде как человек протестировал, но результаты нигде не приложил. Все это должны делать вы сами, а не ревьюер!
3. Код-стайл. Если все булевы переменные названы isSomething, то назовите свою также. Если все классы в тестировании наследуются от X, то тоже отнаследуйтесь от X. Читайте код, который написан до вас и делайте похожим образом.
4. Невнимательность. Прежде чем отправлять код на ревью, сделайте самостоятельное ревью. Обычно вы найдете немало опечаток и даже ошибок. Не тратьте время опытного разработчика на это.
5. Повторяющиеся ошибки. Учитесь на своих ревью! Если ревьюер раз за разом указывает на одну и ту же ошибку (допустим, булеву переменную человек проверяет как = true), то это очень плохой знак.

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

💬 Поделитесь в комментариях, какие еще ошибки по вашему мнению джуны не должны допускать?

А как ещё вы дебажите код? 😁

Нашёл иллюстрацию к своему посту. Спасибо @meeirlan

Советую: https://youtu.be/xjIRVM616Qo
Даже если ходите в зал, то тоже полезно, потому что на эти группы мышц многие забивают

Создаем БОТНЕТ

Провели с Мансуром System Design Interview
Вообще, сама задачка — гроб. Обычные методы, которым учат для таких интервью, практически не работают. Во-вторых, задачка очень широкая и глубокая. Настолько, что по ней можно различить между Staff и Senior Staff Engineer.

Напишите в комментариях, достаточно ли хорошо Мансур ответил для позиции мидла в Фейсбуке?

Досмотрели видео до конца? Лайк, шер, сабскрайб!

Senior Engineer обязан быть эффективным. Советую

https://youtu.be/H-E84nCAVdc

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

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

Чем-то мне это напомнило vertical vs horizontal scaling

System Design Interview for a Meta Engineer 🔥🔥🔥

I'm happy to announce, next weekend I'll be mock-interviewing a friend of mine from Meta, in shaa Allah.
He is a commited and practicing Muslim, an Egyptian and an exceptional senior engineer working at Meta.

Let's see how well he will perform on the interview 😎
P.S. The interview will be in English

Senior Meta Engineer GRILLED on a System Design Interview

Вот и провели интервью с моим другом, Махди Насром. В целом, это хороший ответ на мидла в Meta, но по некоторым осям не дотягивает до сениора. Смотрите сами и делитесь в комментариях, как вы бы подошли к решению задачи!

https://youtu.be/Igi-WeswCOA

Продуктивный терминал

Давно не писал, сильно загружен. Просто поделюсь полезной статейкой по настройке терминала.
https://ivanaugustobd.medium.com/your-terminal-can-be-much-much-more-productive-5256424658e8

Нетривиальная интервью задачка

У вас есть два сервера, которые могут общаться между собой по сети. Каждый сервер хранит множество (set) строк. Назовем их A и B. Известно, что пересечение A и B достаточно большое, допустим 90%. Задача этих серверов — синхронизировать множества, т.е. сделать так, чтобы на каждом сервере в итоге было их объединение (union) A ∪ B.
Нужно описать протокол, который решит эту задачу, при этом нужно постараться минимизировать количество байт отправленных по сети.

Чтобы точно было понятно, вот пример: A = {a, b, c, d}, B = {a, b, c, e}. В итоге на каждом из серверов должно оказаться {a, b, c, d, e}
Решение в лоб: просто обменяться множествами и локально посчитать объединение.

Пишите свои решения в комментариях

#interviews

Решение задачки выше

Нужно построить префиксное дерево (Trie) и над ним посчитать дерево хешей (Merkel Tree).

Протокол будет следующим:
1. Обмениваемся хешами в корнях деревьев. Если хеши одинаковые, значит и множества тоже совпадают.
2. Если хеши отличаются, идем в сыновей: сверяем там. Где хеши совпали, то значит множества из этих под-деревьев совпадают. И т.д.

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

P.S. Когда множества значительно отличаются, такой алгоритм выдает не оптимальный результат, но что поделать, нет супер-универсального алгоритма.

❓Так ли бесполезны кодинг FAANG интервью?

Как минимум раньше бытовало мнение, что кодинг задачки с применением алгоритмов бесполезны и мало что показывают. Это не так и вот почему:
1. FAANG кодинг задачи обычно просто формулируются, и это очень большой плюс. Не нужно тратить драгоценное время кандидата, чтобы вводить его в курс дела
2. На подобных задачах хорошо видно то, как ты умеешь объяснять решения, как ты мыслишь
3. Легко выявляется и умение чисто, лаконично и быстро писать код
4. Насколько человек умеет продумывать корнер кейсы и тесты — очередная сильная сторона подобных задач. Обычно, там достаточное количество подводных камней
5. Обычно в FAANG компаниях закрытый и сильно кастомный стек, поэтому задавать вопросы по конкретным технологиям не очень разумно. Зато знание алгоритмов фундаментально и не меняется от стека, к тому же наращивать его бывает намного сложней. То есть лучше нанять человека, который знает алгоритмы, но не знает питона, чем наоборот. Потому что в одном случае на его обучение уйдёт 3 недели, а в другом случае 1 год
6. Если бы у вас было два равных кандидата, один из которых закончил факультет по компьютерным наукам, а другой нет, то кого бы вы выбрали? Так и тут, знание алгоритмов — это некая такая «университетская корочка» для FAANG
7. Знание алгоритмов — это показатель того, что человеку не достаточно поверхностных знаний, ему хочется копать глубже и разбираться во всем досконально. Это крайне похвальная черта

Нужно ли всем теперь проводить кодинг интервью как в FAANG? Нет, но об этом в отдельном посте.

___
А какие минусы вы видите в подобных интервью? Напишите в комментариях, поддержите лайком и репостом