Про 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? Нет, но об этом в отдельном посте.

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

Сделал небольшой ребрендинг канала

Проблема Senior Developer в том, что это почти как "сферический конь в вакууме". Если не углубляться, то получается небольшое количество общих тем, которые я и так до какой-то степени уже затронул. А если углубляться, то в том же System Design уже конца и края не видно будет. А значит на это нужно уделять значительное время.

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

💡Имеет ли идея ценность?

За последние два дня я поговорил с тремя начинающими мусульманами предпринимателями, у которых проекты были на пре-MVP стадии (то есть продукт еще в разработке, нет ни единого клиента). И вот какие общие черты я выявил:
1. Они в этой стадии уже годы
2. Вложено много денег и сил
3. Все поголовно боятся, что их идею украдут

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

Нет, нет и еще раз нет! Идея — это лишь 3% успеха, все остальное — это усердный труд и командная работа. Инвестиции в стартапы на ранних стадиях — это инвестиции в первую очередь в команду, а не идею. Идея по пути еще 10 раз будет корректироваться, а может и вообще по ходу изменится на другую.

У меня есть сотни идей для проектов, которые просто некогда реализовывать. Недавно общался с человеком, у которого есть контакт на министерства туризма в КСА. Там есть все: и деньги и идеи. Нет только людей, которые сумеют взять эти деньги и воплотить идеи в жизнь.

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

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

❓Зачем нужны кофаундеры?

Заметил, что многие СНГ-шные люди при старте своих проектов с большой опаской относятся к ко-фаундингу, и даже если и соглашаются, то стараются дать партнерам минимальную долю.
Темы выбора кофаундера и распределения долей я постараюсь затронуть в отдельных постах, а сегодня просто о том, зачем оно нужно.

Топ 5 причин:
1. Крутой стартап обычно является очень сложной системой. Там нужно и код писать, и дизайнить, и маркетинг делать, и операционка бывает, а еще привлекать инвестиции, делать b2b продажи, сводить юнит-экономику, постоянно изучать рынок и т.д. Да, вы можете закрыть 30-50% этих функций, но оставшиеся области будут страдать. И это может кардинально повлиять на успех всей компании. Так вот, лучше иметь 50% от единицы, чем 100% от нуля
2. В одиночку двигаться медленней. Чем медленней растешь, тем больше шанс, что появятся конкуренты, которые по-быстрому захватят тот же рынок. Ну и венчурным инвесторам стартапы с медленным ростом не интересны
3. Кофаундер не даст сдаться в сложную минуту. Поверьте, моментов, когда хочется все бросить будет много. Очень много. Кто-то, кто тебя поддержит в такие минуты очень важен.
4. Деньги не решают. Есть тип людей, которые думают: а, сейчас я привлеку деньжат, дальше найму программистов, маркетологов и т.д. и все у меня магическим образом заработает. Поверьте, не заработает. Сознание фаундера кардинально отличается от сознания человека, который просто работает за зарплату. Если заатусорсить программирование, то вам придумают какое-то решение. Но если у вас будет технический фаундер, то глубоко зная бизнес и технологии, он придумает наилучшее решение
5. Одна голова хорошо, а две — лучше! Стартапы — это про гибкость и поиск рынка. В одиночку ты можешь очень долго чего-то не замечать, либо во что-то слепо верить. Иметь человека, который может покритиковать твои идеи, поспорить, предложить альтернативы очень важно

А зачем еще нужны кофаундеры? Пишите в комментариях 🚀

Ссылка на канал: https://t.iss.one/cto_diary

Путь успешного стартапа 😁

Ссылка на оригинал