Hack of the Week

В хроме есть классный экстеншен Block Site. Там можно не только заблокировать сайт, но и настроить редирект. Так вот facebook и instagram я редирекчу сразу на GitLab. Взгляд на то, что у тебя есть MR'ы, которые ты не доревьюил, очень сильно отрезвляет 🙂

Ради интереса я пообщался с русскоязычным фаундером этого стартапа. До встречи я чуть погуглил про него и посмотрел его Linkedin профиль. Он в 2020 году, кажется, попал в YC (топ-1 акселератор в мире). Дальше наша беседа [мои мысли и комментарии в квадратных скобках]:

- Привет, я Муаммар, <тут рассказ о моем опыте>, рад знакомству
- Привет, я <имя фаундера>, я все время делал социальные приложения [social apps], самое крутое приложение собрало 15m скачиваний. Сейчас мы работаем над Web3 социальной криптой, <достаточно сумбурно рассказывает механику>. Мы уже сделали приложения под iOS и Android, сейчас пишем движок для нашей криптовалюты и ищем человека, который хорошо разбирается в concurrency, чтобы мы могли процессить десятки/сотни тысяч операция в секунду. Мы предлагаем зп + хорошие опционы как одному из первых разработчиков
- Раз вы даете много опционов, то я выступаю инвестором своего времени в ваш стартап. Так что сейчас я позадаю инвесторские вопросы: у вас есть питч-дек [презентация для инвесторов], можешь его показать?
- Нет, у нас нет питч-дека [этот момент меня крайне насторожил: человек, который побывал в YC не имеет питч-дека?]
- А как вы подняли инвестиции? И, кстати, сколько подняли?
- Мы подняли $1.4m, проинвестировали мои друзья, нам должно хватить где-то на год [у человека есть связи, это хорошо]
- Хорошо, а ты можешь отправить какие-то материалы, где подробней рассказывается о проекте? Мне нужно понять, заходить ли в эту авантюру или нет?
- Смотри, наш стартап уникален, <какие-то слова про то, что он просто не может прогореть с этой идеей> [вот тут я насторожился второй раз: начала проявляться слепая любовь к своему проекту (это очень плохо)]
- Окей, а у вас есть трекшен [первые пользователи, продажи, показатель, что ваш продукт нужен на рынке]?
- Да, у нас есть приложения и продукт уже почти в стадии готовности
- Это не трекшен: у вас есть пользователи?
- Трекшен бывает разный. У нас очень сложный проект, и трекшеном там считается готовность продукта [опять же я увидел слепую любовь к своему проекту и не принятие критики]
- Хм, это правда. Хотя когда мы подавались в YC с другим стартапом, у нас был Deep/Med Tech, и YC не считали готовность проекта трекшеном. Ты, кстати, ведь тоже прошел акселерацию в YC? С этим стартапом?
- Нет, у нас был другой стартап
- А что с ним случилось?
- Ну… мы сделали все ошибки, которые только могли и он утонул [было заметно, что тема не очень приятна, это тоже очень негативный фактор: человек плохо воспринимает самокритику, а значит плохо учится на своих ошибках]
- Хорошо, расскажи о вашей команде, сколько вас?
- Нас 10 человек [в сообщении ребята предлагали ЗП $150k, если умножить на 10 человек, то получается, что деньги кончатся через 1 месяц 😄]
- В основном программисты?
- Да, <я не помню как, но в итоге он сказал, что очень вдохновлен примером Телеграма и тем, что там работает 20 супер-крутых программистов> [это достаточно смешно, что ты вдохновляешься Телеграмом, а сам уже на pre-seed стадии набрал половину от их команды]
- Окей, хорошо, присылай тогда инфу, чтобы я мог спокойно почитать и поразмыслить. Рад был познакомиться!

В Snowflake поставили System Design интервью с Tyler Akidau. Просто погуглите, что это за человек, и посмотрите его опыт в Linkedin. Обычно, я к System Design не готовлюсь, но тут должно быть что-то интересное 🙂

Ошибки интервьюеров

Каждый раз просматривая мок интервью на ютубе (не FAANG типа), не перестаю удивляться количеству поверхностных книжных вопросов. Мой критерий плохого интервью прост: к нему можно подготовиться зазубрив книжку. И джун, и мидл, и сениор — все могут прочитать книжку, а как тогда различить между ними?

Вот примеры плохих вопросов на интервью, и как их можно улучшить:

1. Плохо: расскажи, что такое “декоратор” (говорим про язык Python)? Неопытный человек, который просто прочитал эту информацию за день до интервью, сможет на него ответить.

Хорошо: напиши декоратор, который подсчитывает количество вызовов функции. Опытного человека от неопытного отличит то, насколько быстро и качественно он напишет этот код.

2. Плохо: расскажи, что ты знаешь о библиотеке BLoC (говорим про Flutter)? Человек, который сделал пет проект на BLoC-е сможет достаточно неплохо ответить на этот вопрос.

Лучше: расскажи, почему любой Bloc нельзя заменить Cubit’ом? Чтобы ответить на этот вопрос, нужно больше разбираться в библиотеке. Человек без опыта полноценно на него не ответит.

Отлично: напиши Bloc для логина через СМС… (после того, как он написал)… а теперь измени свой код на Cubit так, чтобы он отработал некорректно. Тут мы проверим и то, как человек пишет код, насколько хорошо он делает ивенты и стейты (что приходит исключительно с опытом), а также поймем, насколько глубоко он может копнуть.

3. Плохо: расскажи, за что отвечает буква I в аббревиатуре SOLID? Опытные программисты этим принципам на подсознательном уровне следуют. Спрашивать их книжные определения неправильно.

Хорошо: пришли мне ссылку на какой-нибудь написанный тобою код. По реальному коду уже становится ясно, насколько хорошо в работе человек применяет те или иные паттерны.

Обязанности CTO в стартапе

Disclaimer. Речь пойдет о продуктовом стартапе на ранней стадии

Для тех, кто подписался, но все еще не понимает, что означает название канала, ваш час пробил! CTO — это Chief Technology Officer — в общем, самый главный по всему связанному с IT

Так вот, что входит в его (мои 😏 ) обязанности:

1. Выстраивание архитектуры и принятие важных технических решений. Какие языки программирования, фреймворки, сервисы, зависимости, базы данных и т.д. нужно использовать? Как в кратчайшие сроки клепать MVP, чтобы проверять гипотезы. И многое-многое другое. В конечном счете именно CTO головой отвечает за все технические промахи
2. Самостоятельное написание и ревью кода. Стартап все еще на ранней стадии, руки для написания кода не бывают лишними. Наверное, я трачу 40-50% времени на написание кода, и еще 30% на ревью и технические обсуждения с программистами
3. Быть мастером на все руки и постоянно учиться. Возможно, иногда и можно привлечь много денег на pre-seed раунде и с самого начала взять себе крутых помощниках в тех областях, где ты не силен (допустим, фронт в моем случае), но далеко не всегда так бывает. Я по ходу учу новые языки, разбираюсь в мобильной разработке и еще вагон и маленькая тележка обязанностей
4. Продакт менеджмент. В нашем случае у нас есть отдельный фаундер, который опытный продакт, но частенько такого нет, поэтому нужно хорошо разбираться в продукте, уметь общаться с клиентами, задавать правильные вопросы и делать правильные выводы
5. Проджект менеджмент. Опять же в силу ограниченности ресурсов и малых команд, я бы даже сказал вредно вводить промежуточных людей между собой и программистами
6. Найм. Ты должен уметь находить и договариваться с техническими (и иногда с дизайнерами) специалистами. Уметь “продавать” свой стартап, т.е. создавать такую среду, чтобы туда хотели идти работать люди
7. Человеческий (people) менеджмент. Нанять то нанял, но важно и не потерять. Нужно уметь слушать других, понимать их проблемы, недовольства, решать какие-то операционные вопросы, уметь сорганизовать работу в команде

Также хочется отметить, что в стартапах на ранних стадиях CTO обычно является кофаундером, а это влечет за собой:

1. Глубокое погружение в бизнес. У тебя есть N% в доле принятия решений. Ты должен их использовать, чтобы направлять бизнес в правильном направлении. Поэтому, чем глубже и лучше ты понимаешь то, что делаешь с бизнесовой части, тем лучше. Также у стартапов есть много своей спцифики, поэтому нужно образовываться и в стартаперской тематике
2. Аналитика и мат. часть. Ты ответственен за то, чтобы собирать все нужные метрики и визуализировать их, чтобы принимать решения на основе данных. Также нужно разбираться в том, как именно правильно считаются те или иные метрики, как строить юнит экономику (хотя в нашем случае СЕО очень хорошо справляется с задачей) и т.д.

Надеюсь, теперь вы лучше стали представлять то, во что вы ввяжетесь, если захотите стать техническим фаундером. Но оно того стоит, честно! 🙂

Анатомия MVP (часть 1)

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

MVP (Minimum Viable Product или Минимально жизнеспособный продукт) — продукт, обладающий минимальными, но достаточными для удовлетворения первых потребителей функциями.

Но прежде чем уходить в детали, поговорим в целом о стартапах:
— Чем стартап отличается от бизнеса?
— Стартапы растут экспоненциально, а бизнесы растут линейно
— Чем же достигается такой рост?
— Ты выбрал большой рынок и нашел боль у клиентов + сделал конкурентный продукт, который нравится пользователям и они продолжают им пользоваться + ты научился скейлить эту историю

Поиск рынка достаточно понятная вещь, скейлинг начинается позже, но вот нащупывание боли у клиента и создание продукта, который ее решает — тут конкретная труба. Если вы нащупали такую боль и нашли ее решение, что начали расти экспоненциально, то это называется Product Market Fit (PMF).

Наконец-то вступление закончилось и возвращаемся к нашему MVP, как он связан со всем что было сказано ранее? А вот как! Поиск PMF-а — это длительный процесс выдвижения гипотез и проверки их путем проб и ошибок. Прежде чем нащупать “ту самую гипотезу”, возможно, вы перепробуете десятки, если не сотни других гипотез. Поэтому, скорость проверки гипотез является ключевой метрикой стартапа на ранней стадии. И если, чтобы проверить гипотезу, вы каждый раз строите звездолет, то после двух неудачных “звездолетов” у вас уже упадут руки и вы сдадитесь. Более того, если ваши конкуренты быстрее вас проверяют гипотезы, то с очень высокой вероятностью они победят.

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

Как делать плохо: нужно создать мобильное приложение и загнать туда всех пользователей. Я детально буду разбирать, почему это плохо, но пока что по моей скромной оценке, на это уйдет как минимум 3-6 месяцев и порядка $50k.

Как нужно сделать: найти 5-10 водителей из чата и 5-10 активных пользователей и детально их проинтервьюировать, почему они не пользуются другими решениями, что им сейчас не нравится и т.д. После чего выбрать несколько самых больных моментов и сделать какого-нибудь телеграм-бота, который сможет эти боли закрыть. В итоге, одна неделя на интервью и еще одна неделя на создание бота. Результат: 2 недели и $1k бюджета.

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

Ничего особенного, просто хвастаюсь фидбеком который получил после интервью в Snowflake 😎

"Not many people get strong yes from Tyler Akidau, but not you!"

Идеальный руководитель

В процессе чтения книжки "Идеальный руководитель" Ицхака Адизеса, делюсь мыслями.

Есть 4 основные функции у руководителей:
- (P) Production — производить результаты, т.е. удовлетворять потребности нынешних клиентов
- (A) Administration — администрирование, т.е. выстраивать процессы и делать их более эффективными
- (E) Entrepreneurship — предпринимательство, т.е. видеть, к чему мы идем в будущем, понимать тренды и т.д.
- (I) Integration — сплочение, т.е. выстраивать отношения в компании, ценности, сплоченность и т.д.

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

В терминах продуктовой компании, например, это выглядит так: когда мы пилим много фичей (P), потом возникает много багов и страдает автоматизация и поддержка (A). Если мы фокусируемся на качестве (A), то начинаем медленней фигачить фичи (P).

На самом деле достаточно очевидно, но заметил, что мы иногда поздновато переключаемся между этими функциями. Обычно, в начале идет (P) — ты создаешь продукт, делаешь фичи для клиентов, понимаешь, что им важно, а что нет. В нашем случае, например, возьмем школьную развозку детей на микроавтобусах. В какой-то момент ты понимаешь: все, клиент, в принципе, доволен количеством фичей, больше ему не надо.

Дальше должен идти переход от (P) к (A), когда мы аккуратно начинаем считать маржу, рентабельность каждой школы, оптимизировать расходы, колл-центр и т.д. Мы же в UvU после (P) сфокусировались на другом сегменте, но не уделили (A) достаточно времени, вследствие чего мы слегка раздолбали сегмент со школами. Сделай мы этот переход раньше и более осознанно, возможно, у нас бы было на 20% школьных клиентов больше.

Другой пример: есть у меня один знакомый, продакт менеджер. Парень вроде хороший, вроде бы все умеет, но что-то вот не идет у него. Только сейчас я понял, в чем эта проблема. Продакт менеджмент — это (P) функция, продакт постоянно общается с клиентами и хочет удовлетворить их потребности, он постоянно что-то производит и создает. Но если пообщаться с этим человеком, то становится видно, что он очень большой консерватор, что характерно больше для (A). В итоге нужно либо себя поменять, либо сферу деятельности.

По немногочисленным просьбам делюсь опытом, как подготовиться к System Design интервью:

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

2. Практика, практика и еще раз практика. Чем подготовленный к кодинг интервью человек отличается от неподготовленного? А тем, что подготовленный практически молниеносно определяет паттерны и алгоритмы, которые нужно использовать при решении задачи. В System Design то же самое. Есть ограниченное число подходов, которые применяются в тех или иных ситуациях. Недостаточно их просто знать, нужно их очень хорошо уметь видеть, а это приходит с опытом

3. Реальный опыт работы с различными системами. Допустим, недавно меня спросили, как реализовать Delayed Queue — очередь, в которую можно класть сообщения вместе со временем, когда это сообщение вытащить. Чтобы решить эту задачу при помощи Distributed Key-Value Store, нужно знать один трюк: как реализовать там индекс, чтобы быстро вытаскивать сообщения, которые уже пора отправить. Так вот трюк такой: в таких системах есть обычно операция scan(prefix_from, prefix_to), которая эффективно сканирует по ключам, а сами ключи нужно иметь вида (state, timestamp, id). Если человек никогда подобную вещь не делал, то в лучшем случае потратит 5-10 драгоценных минут, чтобы это понять. И обычно, практически нигде это не рассказывается, кроме как при работе с реальными системами.
Также есть много областей в System Design, где легко можно отличить опытного человека от не очень опытного. Допустим, реалистичные оценки количества запросов, которые может обработать реальная база данных в секунду и так да-ле-е

Всем удачи при подготовке к интервью 😉

Какие технологии будут популярны в стартапах в 2023

https://youtu.be/jeblUIWEvmo

Зачем делиться опытом и как максимизировать свой impact?

https://youtu.be/K29d9fQq74M

В последние несколько дней заметил один повторяющийся паттерн. Программист хочет сделать какой-то it-продукт/стартап. Он придумывает MVP и начинает его пилить. На вопрос: как ты собираешься это продавать, монетизировать и привлекать клиентов, он не знает четкого ответа.

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

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

Не сделав ни первого ни второго, ты просто заметаешь мусор под ковер. Рано или поздно это аукнется тем, что посмотрев правде в глаза, ты бросишь проект, потратив на это кучу сил и времени.

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

UvU: бизнес итоги 2022

Совершенно сумасшедший год выдался. Вот краткое резюме:
- Январь. Готовим запуск в Алматы, происходит революция, правительство решает перевести все образование в онлайн якобы на фоне пандемии. Мы активно брейнштормим, куда можно релоцироваться: рассматриваем Москву и Киев
- Февраль. Решение об онлайн образовании отменяют, продолжаем работу в Астане. К концу месяца войска России вступают на территорию Украины
- Март. Курс дико скачет, начинаются проблемы с переводами денег в Россию. Платить программистам в России становится все сложней
- Июнь. Запускаем женское такси, получаем 50,000+ скачиваний, долго занимаем топ 1 в Appstore в Казахстане
- Июль. Попадаем в Google for Startups, многое переосмысляем и делаем pivot от женщин на легковушках к микроавтобусам
- Август. Растем по всем показателям, стоимость дизеля взлетает в 2 раза, паника у водителей, приходится повышать им ЗП в одной школе аж на 30%
- Сентябрь. За 1 час до начала развозки самой крупной частной школы в Казахстане, водители устраивают бунт и никого не везут (долгая история), мы подставляем 1000 родителей и хапаем от них тонну хейта. Хейт крепчает, когда нам приходится уходить из школы, и заодно делать возвраты всем родителям
В другой школе не успевают достроить новое здание, и вместо развозки 100% в одну точку (как мы планировали), нам приходится везти 50/50 в два старых корпуса в совершенно разных местах
В связи с мобилизацией и проблемами с переводами, релоцируем наших программистов в Казахстан
- Октябрь. Запускаем UvU Shuttle, начинаем возить взрослых в бизнес центры и жилые комплексы. Презентуем проект президенту Казахстана. Максимально сокращаем штат и затраты
- Ноябрь. Выходим в безубыточность, совершая 2,200 поездок в день. Договариваемся на пилот в КСА
- Декабрь. Готовим план по скейлингу бизнес-модели, пересчитываем юнит-экномоику, заключаем B2B контракты по развозке, готовимся к инвестиционному раунду

Итог: в 2022 году наши водители заработали порядка $500,000, совершив 250,000+ поездок, мы выросли по показателям в 7 раз с прошлого года, и готовы к новому росту в 2023!

Хвала Аллаху 🤲, Который помог всему этому свершиться!

P.S. Такой сумасшедший драйв никогда не получишь, работая в Фейсбуке или Твиттере 😉

А вы говорили leetcode не нужен!

Задача из реальной жизни, которую пришлось на днях решить:
В микроавтобусах конечное число мест. Все пользователи заходят и выходят в разных точках и бронируют места заранее. Как правильно определить, есть ли у нас свободные места между точками X и Y?

Наиболее эффективным решением этой задачи является алгоритм, который работает за O(n log n), где n — кол-во интервалов. Он состоит из 4-х шагов:
1. Определить все интервалы, которые пересекаются с заданным (на рисунке лишь B не пересекается с красным интервалом)
2. Разбить каждый интервал на два конца и составить массив из пар: (end, sign), где sign — это +1 в случае начала интервала и -1 в случае конца
3. Отсортировать полученные пары. При том важно (подумайте почему), что при равных точках, сначала должны идти концы (-1), а потом лишь начала (+1)
4. Пройтись циклом по всем элементам, складывать sign и пересчитывать максимум

P.S. Любителям алгоритмов: при определенных допущениях есть еще более эффективное решение. Какое?

Заранее отвечая на потенциальные вопросы по посту выше:

Q: Правда ли, что мы реализовали это решение с самого начала?
A: Нет! Сначала мы просто считали, что как будто все пассажиры едут от первой точки до последней, потому что это было очень быстро реализовать
L: Как стартап, первым делом приоритизруйте скорость

Q: Правда ли, что нам нужно было самое эффективное решение?
A: Тоже нет! Однако рассказанное решение в первую очередь корректно подсчитывает кол-во свободных мест, а реализация занимает всего 10 строчек + тесты
L: Если эффективное решение не сильно сложней, то реализуйте именно его