После новости об отмене удаленной работы неуволенные в Твиттере стали нам дико завидовать 😏

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

P.S. На этом мы заканчиваем про Твиттер, единственное отвлеченное, что я хотел еще рассказать — про налоги в UK. Если тема интересна, то поставьте молнию ⚡️

🔥 Mock Coding Intervew, ep. 2

Под конец видео я поделился фреймворком, как нужно подходить к решению любой кодинг задачи: https://youtu.be/cA9RUG_0MSU

💰 Налоги в UK 💰

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

1. Прогрессивный подходоный налог. Те кто живут в СНГ немного не привыкли, но в UK налог зависит от того, сколько ты зарабатываешь. Если совсем немного, то платить будешь мало, а если много, то обдирать тебя будут конкретно. Теперь по цифрам:
- 12,570 — 0%
- 12,570 - 50,270 — 20%
- 50,271 - 150,000 — 40%
- 150,000+ — 45%
Допустим, вы зарабатываете 100k, тогда налог будет: tax(100,000) = 12,570 * 0% + (50,270 - 12,570) * 20% + (100,000 - 50,270) * 40% = 0 + 7,540 + 19,892 = 27,432. То есть ваш суммарный налог составит ~ 27.4%. Чем больше будете зарабатывать, тем ближе будете приближаться к отметке в 45% налога.

2. Прогрессивный налог на дивиденды. То же самое, что и подоходный налог, только процентаж слегка отличается:
- 50,270 — 8.75%
- 50,271 — 150,000 — 33.75%
- 150,000+ — 39.35%
В целом видно, что быть предпринимателем и вытаскивать деньги как дивиденды в UK чуть получше.

3. Capital Gains Tax. Если вы держите часть сбережений в акциях, и, допустим, акции подорожали на 100%, то продав их, 20% вы обязаны отдать государству.

4. Corporation Tax Rates. Компании в UK платят налог 19%.

5. IR35. А как дела обстоят с серыми схемами? Допустим, стандартной практикой в России было зарегистрировать человека как самозанятого (или ИП) и платить 6% налога вместо 30%. В принципе, можно ведь зарегистрировать компанию и выводить деньги как дивиденды, а не ЗП, в результате платить меньше налогов? Так вот согласно IR35, при заключении рабочего контракта, если это full time employment, вы не имеете право вытаскивать деньги как дивиденды, а обязаны будете выплачивать это как ЗП, и платить обычный подходоный налог.

В итоге, чтобы бизнес заплатил высококвалифицированному работнику 100 фунтов в конечном итоге, он должен заработать: 100 / 0.55 / 0.81 = 224.47. Государство отобрало себе 55.5%.

Добро пожаловать в UK 🇬🇧

P.S. Особенно для малого бизнеса есть много послаблений, во время COVID-а, например, была программа: eat out — help out, когда 3 дня из 5 рабочих государство оплачивало половину чека в кафешке (тем самым стимулируя экономику и ресторанные бизнесы, которые сильно пострадали).

Продолжая и заканчивая тему налогов в UK, вот вам статеечка, как жена нынешнего премьер министра UK — Риши Сунака уклоняется от налогов. Вместо £20m она платит £30k.

Вывод тут такой: в UK хорошо жить либо очень богатым (они умеют хорошо уклоняться от налогов), либо очень бедным (они получают реальную пользу, т.е. крупные пособия), а вот честным программистам в UK жить невыгодно 🥲

Очередное хорошее видео от YC: стоит ли мне делать стартап?
https://youtu.be/BUE-icVYRFU

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

А так, по секрету, стартапы того стоят. Распрощавшись с Твиттером и начав работать фулл-тайм в UvU, я наконец-то почувствовал себя свободным от гнета работодателя 🙂

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