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

Каждый раз просматривая мок интервью на ютубе (не 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: Если эффективное решение не сильно сложней, то реализуйте именно его

Офферы в 2022

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

- Максимальный оффер был в январе на $400k/y, в качестве Engineering Manager в Yandex.Cloud. Я даже думал его принять, но, хвала Аллаху, у Яндекса были проблемы с юр. лицом в Лондоне и все затянулось, а в феврале произошло то, что произошло
- Самую высокую роль мне также предложили в январе: стартап Remofirst поднял инвестиционный раунд в $14m и искали CTO. Я, конечно же, UvU не стал променивать, хоть и условия были намного круче
- Самые крутые бенефиты были от Protocol Labs, которые давали безлимитный отпуск (при условии, что ты выполняешь свою работу) + 6 месяцев parental leave (т.е. после рождения ребенка ты 6 месяцев не работаешь и получаешь полную зп)
- Самые классные интервью были в Snowflake. Ребята очень постарались, чтобы найти интересные задачи и разносторонне проверить опыт человека
- Самое неожиданное интервью было в Huawei Cloud, когда после того как я запросил ЗП выше их лимитов, он мне назначили созвон с 4 китайцами из их головного офиса, которые говорили со мной через переводчика (и я все равно мало что понимал с его китайского акцента)
- Самое короткое кодинг интервью было в Miro, где я полностью рассказал и решил задачу за 12 минут
- Единственный раз, когда я завалил кодинг, был в Wayve, где я затупил и не решил 2 задачки за 1.5 часа
- Самая классная задачка на дом была от стартапа Nillion, где они попросили написать аутентификационный gRPC сервис при помощи ZKP
- Самое стрессовое кодинг интервью было в Revolut, когда они потребовали писать на Java, и я за день до интервью примерно повторил синтаксис, а на интервью не знал, как написать собственный эксепшен (но интервью все же прошел)

Выводы которые я сделал:
- Рецессия или нет, если вы ценный специалист, вам будут давать хорошие офферы
- Следующий год будет сложным. Было 3-5 случаев, когда компании хоть и при успешных интервью, но все равно замораживали процесс, потому что лишались открытых позиций (руководство сокращает затраты)

Напоследок: многие спрашивают, мол когда я приму какой-то из этих офферов? Отвечаю: я остаюсь в UvU и постараюсь по воле Аллаха сделать этот стартап успешным. Если не пробовать и не рисковать, так до конца жизни и будем работать на Масков и Цукербергов

О чем наш стартап?

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

Логичное продолжение вопроса: тогда чем вы отличаетесь от маршрутки?
Мы — “умная маршрутка”. Мы постоянно улучшаем наши маршруты и подстраиваем их под тех, кто с нами регулярно ездит.

Почему мы ушли из женской развозки?

Для начала стоит отметить, что женское он-деманд такси у нас все еще функционирует. Мы автоматизировали его до какой-то степени и отправили в свободное плавание. Женщины водители до сих пор зарабатывают и помогают возить других женщин и детей.

Говоря же о запланированной развозке детей в школы и кружки на легковых авто женщинами, то мы отошли от этой концепции, потому что были определенные сложности в скейлинге этой истории. Раскрываю детали:

- Базовая цена. Если просто возить по одному ребенку, то так как ты ограничиваешь водителей по полу (а значит спрос на водителя выше), то поездки получаются где-то в 1.5 раза дороже Яндекса
- Конкурентное преимущество. Просто так бодаться в лоб с Яндексом — сильно не вырастишь. Поэтому мы поняли, что засчет того, что мы в точности знаем расписания детей, мы можем заранее планировать маршруты, чтобы каждая “мама за рулем” могла захватить нескольких детей. В результате мы снизили цены и стали примерно на равне с Яндексом
- Отмены. Порядка 20% поездок клиенты отменяли из-за болезней, коротких дней и переносов уроков. Если с этим ничего не делать, то придется эти 20% положить на плечи клиентов, а значит заново стать дороже Яндекса
- Умное планирование. Чтобы решить проблему выше, мы стали планировать поездки не на весь год или месяц, а на день вперед, таким образом делая клиентам возвраты, если они заранее делали отмены
- Подводные камни. Стоит отметить, что так как по цене и сервису мы были схожи с Яндексом, то к нам были примерно те же требования: например, клиенты не хотели платить на месяц вперед, или то что были очень высокие ожидания от мобильного приложения
- Проблемы скейлинга. Но еще большей проблемой были водители. Чтобы отвезти 2,000 детей, тебе нужно порядка 500 водителей, а с учетом того, что кто-то болеет, и у кого-то ломается машина, то мы говорим о порядке 700 “мам за рулем”. И даже на таких размерах сохранить качество уже невероятно сложно. Кто-то просыпает, кто-то опаздывает, постоянно новые маршруты и новые дети, в результате “мамы за рулем” долго их ищут, колл-центр начинает разрываться
- Решение. Стартап Kidsway решил подобную проблему засчет того, что они задрали цены в 2 раза выше Яндекса и сфокусировались на премиум сегменте. Мы понимали, что премиум сегмент намного меньше масс-маркета и не хотели туда идти

В развозке на микроавтобусах ты изначально даешь цену в 2 раза ниже такси, фиксируешь маршруты, принимаешь оплаты на месяц вперед, работаешь с куда меньшим количеством водителей. Все это помогает тебе быстро расти и генерировать прибыль. Именно поэтому, взвесив все “за” и “против”, мы решили пивотнуться в эту сторону.

[leetcode] Решаем 3 medium задачи без подготовки

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

Должен ли стартап быть инновационным?

Часто приходится слышать: в такой-то школе уже 15 лет существует развозка, такая-то компания уже давно развозит своих сотрудников и т.д.
Все абсолютно верно, однако, это еще не означает, что там нет потенциала построить стартап. Напротив, это указывает нам на то, что спрос есть и спрос этот огромный! Было бы удивительно, если бы у людей была какая-то боль, и не было бы ни одного решения рынке.

Наш стартап является маркетплейсом: с одной стороны у нас есть люди, создающие спрос — demand, с другой стороны водители, генерирующие предложение — supply. Задача маркетплейса — уравновесить рынок. Что это означает?

Demand. Сейчас на рынке в основном есть частники, в результате, если я бизнес, который хочет заказать развозку своим сотрудникам, мне нужно обыскать 10 сайтов и найти наиболее приемлемое решение по цене/качеству. Сложно найти справедливую цену в условиях ограниченной информации. В результате, либо я получу завышенную цену (потому что не было полноценной конкуренции), либо вовсе откажусь от идеи развозки.

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

Marketplace. Если нам удается сравнять supply и demand, устроив честную конкуренцию, то все оказываются в выигрыше: бизнесы получают более низкую цену, в результате спрос растет. Засчет выросшего спроса водители начинают зарабатывать больше, и растет предложение. Сам маркетплейс берет себе какую-то комиссию.

Что самое инновационное в Убере? Мобильное приложение? Нет! Самое важное — это ценообразование. Именно засчет умного ценообразования Уберу удается сделать так, что с одной стороны ты 20 минут не ждешь машину, а с другой стороны водитель не получает совершенно копейки.

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

Что я читаю (часть 1)

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

Так вот, если у кого схожие интересы, хотел бы поделиться блогом Eli Bendersky, который пишет простым языком с хорошими картинками и пояснениями. Из недавнего, что прочитал: Implementing reader-writer locks — классная статья о том, как можно под капотом реализовать R-W Mutex, в том числе в самом конце Эли приводит реализацию приближенную к тому, что находится в стандартной библиотеке Go в sync.RWMutex.

А тем, кто хочет попрактиковать свое concurrent-кунг-фу, предлагаю следующую задачку. Основными свойствами R-W Mutex’а являются: (1) отсутствие busy wait’а и (2) writer preference. Задача заключается в том, чтобы реализовать R-W Mutex с разными свойствами при помощи обычных мьютексов:
- busy wait + writer preference при помощи одного мьютекса
- no busy wait + reader preference при помощи двух мьютексов
- no busy wait + writer preference при помощи трех мьютексов

Все реализации должны получиться достаточно лаконичными. Если у вас выходит какой-то монстр — попробуйте заново.

Про зону комфорта

«… нельзя сказать, что у него за плечами двадцать лет опыта. Его опыт — это год работы, повторенный двадцатикратно.» (Ицхак Адизес)

Просто золотые слова. Адизес очень красочно выразил мысль, которую я так долго вынашивал. Частенько вижу, как программисты входят в зону комфорта, получая зарплату $3k+. Вроде как что-то делает, вроде и пользу приносит, но развития никакого. И так он сидит годы либо на одном проекте, либо перескакивая с проекта на проект.

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

Я не знаю ни одного успешного стартапа, где фаундеры бы отсиживались в зоне комфорта.

А если вы хотите оставаться разработчиком (что тоже абсолютно нормально), то знайте, Chat GPT придет за вами, если остановитесь в развитии :)