🧟‍♂️ Road To Staff

Год назад я начал рубрику, которая называется #roadtostaff.

Цель вырасти до стаффа внутри компании и еще, как доказательство, получить оферы из MAANG компании на уровень стаффа. Я знаю, звучит амбициозно.

Я на какое-то время забросил писать об этом, но у меня на самом деле тут есть сдвиги.

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

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

В-третьих. Опять же по заветам Will Larson, часть роста это спонсоры и попадания в различные комнаты. Последние 4-5 месяцев я прикладывал усилия, чтобы попасть во внутреннюю команду по развитию интервью процессов Канвы. Это не было просто, напишу наверное как-нибудь отдельный пост. Но я очень рад, что смог туда попасть.

Следующее ревью будет через пару месяцев и если честно я сомневаюсь, что получу продвижение. Если все пройдет как и задумано, то я перейду на следующую роль в течении 6-12 месяцев. Главная цель, это запуски внутри команды, нужны прям сильные примеры.

И да, я начал потихоньку проходить собеседования. Хочу до конца года попробовать себя во всех MAANG. Пока что закончил Atlassian и AWS, Microsoft отказал на HR созвоне.

Stay tuned

#roadtostaff

👽4 совета: как не стоит готовиться к собеседованиям

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

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

• Не тестировать себя в «пробных» компаниях

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

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

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

• Верить в свой опыт больше, чем в подготовку

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

Многие собеседования были провалены одним человеческим пороком, гордыней. Я видел и вижу множество крутых и сильных инженеров, которые не доходят до финала, не понимая, что сильный кандидат и стаж работы не одно и то же.

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

• Только Литкод и ничего кроме Литкода

По какой-то причине, нас всех приучили, что лучше всего готовиться к алгоритмам - это решать литкод. Это правда, но только наполовину, ведь сколько историй про 500 и 1000 решенных задач, но проваленных собеседований.

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

Собеседования на алгоритмы это не Литкод. Это умение быть спокойным и находить правильное решение в стрессовой ситуации. Тренируйтесь на пробных собеседованиях.

• Не ставить себя на место интервьюера

Я никогда не думал о том, что реально хочет услышать интервьюер и не пытался понять, а зачем он задает тот или иной вопрос.

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

В этом плане мне очень помогло начать собеседовать самому. Я начал замечать свои ошибки в других кандидатах.

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

🔥 - ставь огонь, если было интересно получить пошаговый план подготовки к FAANG?

Хай 👋

Я тут написал первый newsletter, поддержите лайками и репостами
https://bigtechdream.substack.com/p/ownership-why-you-should-have-it

Рахмет ✊

👩‍🏫 Как практиковать систем дизайн?

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

Что это значит?

Я вижу, что много людей при подготовке сильно полагаются на просмотр решений. Их идея состоит в том, что если я просмотрю 100 видео по всем возможным вопросам, то на интервью смогу примерно вспомнить и решить правильно.

На практике же все превращается в кашу. Кандидат помнит, что должны быть очереди, но не помнит куда их поставить, кандидат говорит в целом правильные вещи, но сильно путается в деталях.

Поэтому видео должны дополнять практику, а не заменять ее.

Как готовлюсь я

Оставим за бортом изучение теории, представим на минуту, что я изучил основы Sql vs Nosql, sharding, balancing, protocols, etc.

Чтобы закрепить полученные знания, я должен научиться мыслить как архитектор. Я нахожу в интернете или придумываю сам себе любую задачу, например реализовать TikTok. Потом нахожу в офисе свободный кабинет с большой доской и начинаю рисовать.

Я иду по порядку
• Определить требования
• Попробовать расчитать нагрузку
• Накидать схемы таблиц и выбрать хранилище
• Нарисовать общую схему работы
• Попробовать найти узкие горлышки и устранить

Во время определения требований, я сам себе задаю вопросы и сам же на них отвечаю. Например, “Нужно ли реализовать комментарии к тик ток видео?”, “Давай пока нет, только лайки, но мы можем вернуться к этому вопросу потом”.

Потом во время решения, я задаю себе вопросы, почему я выбрал ту или иную технологию, могу ли я обосновать выбор?

Я не ограничиваю себя во времени, скорость второстепенный показатель, мне важен именно мыслительный процесс.

Как понять, что я решил правильно?

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

Поэтому “Как понять, что я решил правильно?” - неверная постановка вопроса. Точнее будет “Что я не учел при проектировании системы?” “Можно ли было решить оптимальнее с учетом требований?”

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

После такого процесса у меня получается небольшой список тем, которые стоит мне поизучать. Это мои зоны роста.

Каждый раз проходя такой круг, я как бы калибрую сам себя. С каждым разом нарабатываю практику и закрываю теоретические пробелы.

Ставь 🔥 - если нравится решать system design задачки
Если не нравится, то 🤮