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

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

Чем-то мне это напомнило 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

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

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

Если бы меня спросили, какое качество больше всего хромает у разработчиков (в русскоязычном сегменте уж точно), то я с уверенностью скажу — прозрачность (transparency).

Никто не идеален и все промахиваются со сроками, но есть огромная разница между тем, чтобы это сообщить сразу как стало ясно и за 5 минут до дедлайна. Не стоит притворяться рембо-программистом, который в одиночку все вытащит и сделает в срок. Сообщите вашему руководителю, возможно, в результате обсуждения вы поймете, как что-то можно упростить, либо если проект критичен, сколько дополнительных сил там нужно. Если все равно не удастся уложиться в сроки, можно хотя бы сообщить об этом клиентам, чтобы смягчить их реакцию и занизить ожидания. Поверьте мне, хуже всего молчать. И чем более опытный (senior) программист, тем более он прозрачен.

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

А где еще нужна прозрачность?
Пишите в комментариях и делитесь с друзьями!
Ссылка на канал: ➡️ https://t.iss.one/cto_diary ⬅️

⚔️ Решение vs код

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

Для начала сделаем шаг назад и поймем, что решение должно что-то решать. То есть должна быть задача, которую мы решаем. Так вот решений одной и той же задачи может быть великое множество, но лучшее из них в первую очередь должно быть продиктовано бизнесом. Не имеет смысла строить космический корабль, когда ты просто пешком можешь дойти из точки А в точку Б. Аналогично, не имеет смысла даже начинать идти пешком, когда расстояние между А и Б 1,000 км.

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

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

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

___
💬 Поделитесь в комментариях своими мыслями и опытом на эту тему
🔗 Ссылка на канал: https://t.iss.one/cto_diary

Настроение в Твиттере после прихода Маска

Кажется, самая частая фраза, которую я не устаю повторять что внутри стартапа, что когда я кому-то что-то советую: “Давай сделаем шаг назад и поймем, какую именно проблему мы хотим решить”.

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

На практике я часто вижу, что бизнес уже приходит с какими-то решениями. Частые примеры:

- “Мне нужно мобильное приложение, чтобы …”. — Давай сделаем шаг назад и поймем, какую проблему ты хочешь этим решить? Может быть тебе достаточно мобильной версии сайта? А может просто конструктор использовать? А может просто для начала на маркетплейсе зарегистрироваться и через него что-то сделать?
- “Мне нужно добавить вот такое поле в БД”. — Давай сделаем шаг назад и поймем, какую проблему ты хочешь решить? Как ты будешь использовать это поле?
- “Мне нужно встроить чат в приложение”. — Давай поймем, зачем нужен чат, какую проблему ты хочешь решить? Можно ли просто тут добавить кнопочку? Можно ли как-то подсвечивать карточку в такой ситуации?

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

___
💬 Поделитесь в комментариях, как вы меняли ход решения правильными вопросами?
🔗 Ссылка на канал: https://t.iss.one/cto_diary

Умение слушать и слышать для фаундеров критично.

Если опытный человек тебе говорит: так не делай, так не работает, то поставь по-честному свои идеи под сомнения.
Признак того, что ты искренне сомневаешься — желание разобраться, т.е. почему конкретно так делать не надо и по какой причине так не работает. На практике же видишь, что люди говорят «я тебя услышал» и переводят тему.

Я хочу сделать свой стартап, с чего начать?

Как и в любом деле, предлагаю начинать с получения знаний:
- Пройдите Startup School от YC. YC — это сильнейший в мире акселератор
- Если это ваш первый стартап, обязательно постарйтесь попасть в какой-нибудь акселератор (в идеале YC, но на нем мир не сошелся) вживую. Одно дело послушать лекции, другое дело — поработать с настоящим опытным трекером
- Поймите, каких компетенций вам не хватает и найдите кофаундера, об этом я писал уже выше

- Если проект некоммерческий, прочитайте книжку Engine of Impact

По своему опыту скажу, вместе с Tooba мы наступили практически на все грабли, которые были описаны в Engine of Impact. Также с celly мы сделали немалое количество ошибок, которые можно было легко избежать, просто следуя советам от YC.

___
Нравится контент?
Подпишись на канал и поделись с друзьями: https://t.iss.one/cto_diary

Горжусь работать с таким CEO, альхамду ли Ллях

Про увольнения в Твиттере (часть 1)

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

Во-первых, сейчас глобальный рынок в целом чувствует себя плохо. Посмотрите на акции Meta, или Google. Они падают, а дна еще не видно. Поэтому все сейчас перестраиваются из режима быстрого роста в режим максимальной прибыльности.
Во-вторых, покупка была сделана по завышенной цене акций: $54. Был привлечен крупный кредит, в результате нужно выплачивать долги по процентам. И самый легкий способ увеличения прибыльности уже крупной компании — сократить расходы.
В-третьих, в Твиттере работают прекрасные люди, однако процессы, автоматизация и эффективность выстроены в компании плохо. В результате Твиттер развивался очень медленно. Какие крупные фичи вы помните за последние 5 лет? Их можно пересчитать по пальцам.

Так что с глобальной точки зрения я прекрасно понимаю Маска: компанию нужно, а самое главное есть куда перестраивать и улучшать. А вот что в этой перестройке было не так (спойлер: все) — поговорим в следующем посте.