От Junior до Team Lead меньше чем за 2 года

Всем привет! Меня зовут Дмитрий Лёвочкин, я Flutter Team Lead в компании Friflex, а также автор блога «Дневник Flutter-разработчика».

Разделим эту статью на четыре логические части:

1. Кратко расскажу о своём пути до Junior и опишу своё видение, как бы я входил в IT сейчас, без технического образования и опыта.

2. Расскажу о своём пути до Team Lead. Почему эту «лычку» получил я и как докатился до жизни такой)

3. Дам советы, как быстрее развиваться по софт и хард скиллам.

4. Четвертая часть — это ответы на вопросы моих подписчиков. Я спрашивал в своем блоге, что читателям было бы интересно увидеть в этой статье, и некоторые вопросы не удалось раскрыть в основной части. А они стоят внимания)

1. Мой путь в junior flutter developer, кратко

Я начал своё погружение в IT в 27 лет. У меня гуманитарное образование (специальность — управление проектами). Моя предыдущая деятельность никак не была связана с IT. 

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

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

Подробно о своём пути до junior я описывал в этой статье.
Там есть и рекомендации, и про создание блога (чем это помогло), а еще о том, сколько я обучался и с какими проблемами сталкивался.

По итогу обучения я начал рассылать резюме своим знакомым разработчикам и спрашивать: «Как тебе? Что поправить?» 

P.S. На момент моего входа в IT у меня не было ни одного знакомого из IT. Все знакомства появились благодаря блогу. Чаще всего я просто писал тем, кто оставлял комментарии к постам. Еще я сразу подписался на все профильные чаты и активно там общался.

Юрий Петров на моё такое сообщение ответил: «О, ты ищешь работу, давай я тебя порекомендую HR Friflex». Конечно же, я согласился. Но через пару дней он написал, что HR отказала, так как найм сейчас закрыт.

В общем-то я на этом не сдался и пошёл на сайт Friflex, где заполнил анкету на открытую вакансию. Мне позвонила HR, мы хорошо побеседовали, но мне снова отказали — по причине того, что найм откроется примерно через месяц.

Это меня тоже не остановило, и через пару дней я вспомнил, что видел у одного из подписчиков блога (в Telegram можно отслеживать, кто подписывается на блог) в bio «CEO Friflex». Тогда я ещё не знал, что СЕО — главный исполнительный директор)) Я подумал, что это менеджер, и, возможно, через него попаду на собес.

Написал: «Я откликнулся на вакансию на сайте Friflex и не знаю, отправилось ли резюме с сопроводительным. На сайте после отправки не было никакой информации…». 

CEO cказал, что дадут ответ в понедельник. В понедельник позвонила HR и сказала, что меня очень ждут и готовы прособеседовать, как только я сделаю вступительное тестовое:)

Так я в итоге и попал на собес после двух отказов) Собес я успешно прошёл и устроился на позицию Flutter Junior Developer с первого собеседования.

Совет 1: отказ компании, в которой вы хотите работать — это не всегда 100%-ный отказ. Часто можно найти обходные пути. Или, как минимум, попытаться.
Какие обходные пути? Найти контакты HR и написать ему или ей. Откликнуться на вакансию на сайте компании. Поспрашивать знакомых — возможно, их знакомые там работают и вас зарефералят. Если же знакомств нет, рекомендую поискать сотрудников компании на LinkedIn и попробовать попасть на собес через их рекомендацию.

Как бы я входил в IT сейчас, без знакомых, технического образования и знаний

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

Но с текущими знаниями рынка могу сказать, что Junior’ов очень, ОЧЕНЬ много. На некоторые позиции приходит по 700 откликов. HR даже физически их всех не может просмотреть.
Также без знаний, которые можно получить (по большей части) только в компании от более опытных разработчиков, шанс трудоустроиться достаточно мал.

В общем) Мой путь был бы таким:
1. Определяюсь с направлением и понимаю, что мне это интересно. У меня изначально была идея создания мобильного приложения, поэтому я выбрал мобильную разработку.

2. Подписываюсь на все тематические чаты, что есть, и интересуюсь в этих чатах у людей, какие хорошие курсы они могут посоветовать. Не обращаю внимание на различные платные курсы за ~140 тысяч с гарантией трудоустройства от компаний, которые только и занимаются, что продажей этих курсов. Это ложные надежды, и, скорее всего, с такими курсами я бы потерял и время, и деньги. К тому же, часто эти курсы можно бесплатно взять с торрентов.
3. Прохожу курсы, которые мне посоветовали. Основные критерии доверия к курсу: спикер — действующий разработчик по этому направлению, сам курс или есть на YouTube, или его можно купить за «символическую плату»(не за какие-нибудь ~140к), есть практика и он свежий.

Примеры таких курсов по Flutter и Dart:

Канал Стаса Ильина на YouTube

Dart 3 в действии на Stepik

Основы Flutter на Stepik (в разработке)

4. Дальше, зная базу, иду к ментору. На мой взгляд, это беспроигрышный вариант. Ментор проводит моковое (тестовое) собеседование, чтобы проверить пробелы, и дает материалы для подготовки к собеседованиям. Если нужно, подтягивает отстающие «продовые» практики, и все это в итоге с лихвой окупает себя.

5. Когда ментор говорит, что я готов, иду  откликаться на вакансии на hh, LinkedIn и в профильных чатах для поиска работы с Dart/Flutter в Telegram. Каждое собеседование записываю на видео, после — анализирую и подтягиваю пробелы.

Насчет менторов — не хочу давать рекламу на habr. Напишите в лс tg @Hey_008, дам список менторов с отзывами.

2, 3. Путь до Team Lead. Ошибки и советы, на что делать упор

Со старта работы в Friflex прошло уже больше двух с половиной лет. Должность Team Lead я успешно занимаю последние девять месяцев:)

За эти два с лишним года я поработал в четырех разных проектах. Два были уже реализованные и другие два мы писали с нуля.

С самого первого проекта всем процессом по тех. части руководил тимлид. Code review было построчным от всех членов команды. Вначале это изматывало, но чем дальше, тем меньше было проблем на code review и тем больше насмотренности)

Совет 2: обязательно проводите построчное code review коллегам. Умение понимать чужой код, насмотренность, споры и обсуждения в комментах — это бесценный опыт, который быстро будет вас прокачивать. Вы будете подхватывать лучшие практики от старших коллег и всегда знать, какие изменения были внесены в main.

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

Все, кто меня читал, говорили в лс: «Никакого профита тебе это не принесёт». Так и вышло. Никто меня не заметил, после чего я полностью пересмотрел свой подход. Этот новый подход я смог воплотить в новом проекте, в  который я сам напросился.

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

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

Мы зарелизили этот проект раньше времени, легко укладываясь в каждый спринт.
Как легко укладывались в каждый спринт? В проекте сразу выстроили процессы, лид умело закладывал время на задачи с учётом новой команды. По итогу каждая задача поступала к разработчику с полным описанием: 

• что нужно сделать; 

• где нужно сделать;

• ссылка на дизайн в Figma;

• ручка бекенда;

• связанные задачи дизайна и бэка, чтобы отслеживать по ним статус и уточнять детали у исполнителей.

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

1. Конечно же, на первом месте — ответственность. Без неё никуда. Вы должны быть тем человеком, на которого всегда можно положиться и доверить ему сложный функционал. В будущем вам доверят и проект)
   Также здесь: приходите на встречи вовремя и не забывайте того, что обещали. Никому не нравится, если человек регулярно опаздывает на дейлики или куда-то вдруг пропадает, долго выполняет задачи или не отвечает на удалёнке. 

2. Прокачивайте свои технические скиллы во внерабочее время. Хотя бы по два часа в день. Отслеживайте новые практики, подходы, интересные решения коллег.

3. Постарайтесь перенять у лида его опыт по максимуму. Как технический, так и в области  управления командой. Это делается вопросами невзначай. Спрашивать, конечно же, желательно интересом. Все что вы узнали лучше сразу оформлять в свою базу знаний. Я делал это в Notion (сейчас в Obsidian).

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

5. Это достаточно холиварная тема, но не советую создавать рабочий аккаунт с какой-нибудь картинкой из аниме и странным ником. Хотя бы имя и фамилию добавьте) Это, как минимум, создаст более доверительное и дружелюбное отношение к вам. Какие-нибудь странные блоги с матами лучше тоже не светить)

6. Проявляйте инициативу. Вы можете перерабатывать в стол и очень круто отрефакторить что-либо, что никто не заметит, и нужно это, скорее всего, только вам.
   Бизнесу нужна инициатива. Нужны решения, закрывающие баги и фичи, приносящие пользу. И все это должно быть видимым именно для бизнеса. Тогда вы действительно проявите себя и зарекомендуете.
   Пример: придя в новый проект, где я сейчас лид, я сразу предложил бизнесу внедрить метрику для отслеживания действий пользователей, пуши и режим дебага. Первые две фичи вообще сложно оценить, вклад приличный. А режим дебага помог минимум в два раза ускорить процесс тестирования.

7. Вы можете выбирать задачи, которые вам интересны. Не стесняйтесь. Лично мне ни разу не отказывали в инициативе.

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

9. Коммуникабельность. Желательно быть тем самым «приятным, интересным парнем») Так вы сможете всегда держать руку на пульсе — знать, что происходит в других проектах, в других компаниях. А знакомые из других компаний в случае чего с радостью зарефералят вас к себе.

10. Одно из самых сложных в программировании и в общении с бизнесом — оценка задач. Лучше с самого начала своего пути начинать отслеживать, сколько времени у вас занимает та или иная задача. Так вы быстро разовьёте этот скилл. Правильно оценивать задачи мало кто умеет, это действительно классный навык.
    Я до сих пор отслеживаю затраченное время через Togl Track для себя. Анализ помогает лучше планировать время.
    Бизнес будет относиться к вам несерьёзно, если вы раз за разом будете говорить одни сроки и закрывать важные им задачи — в другие. 

11. В дополнение к предыдущему пункту: лучше держите слово) Если пообещали бизнесу важную сборку завтра и не успеваете, я бы предпочёл переработать и сдержать слово, выпустив её в 23:55. Но после, конечно же, нужно учесть такое непопадание в сроки и лучше оценивать задачи.

12. Не нужно язвить внутри команды или считать себя самым умным, старайтесь со всеми общаться дружелюбно. Вы команда и у вас одни цели) Не нужно после 6 вечера скидывать сборки или писать в чатах и тегать коллег. Если уже близко к этому времени, лучше спросить вначале: «Привет! Еще работаешь?)» Так же НИ ЗА ЧТО не пишите коллегам по рабочим моментам в их отпуск.

13. Старайтесь проявлять инициативу внутри компании. Намного проще повышать человека, которого знают и который «на слуху», чем просто рядового разработчика.

14. Тоже достаточно холиварно, но старайтесь хвататься за каждый шанс. Бывает, лучшие предложения появляются, но ты их упускаешь, так как не готов или ещё куча разных отмазок. Лучше согласиться и в случае чего переиграть, чем отказаться и упустить хорошую возможность. Пример: когда мой лид предложил мне занять позицию лида, я ответил: «Да, конечно!». Когда я знакомому (хорошему разрабу), которого не повышали, предложил перейти ко мне в проект и со временем занять моё место, он отказался. Хотя предложение было хорошим)

15. Старайтесь почаще запрашивать фидбек о себе у лида и команды. Так вы будете всегда на виду. Это полезно со всех сторон: если фидбек не очень, вы подправите своим минусы. Если фидбек хороший — можно запрашивать повышение. К тому же, руководство видит, что вам не все равно. Не просто «пришёл, отсидел рабочее время и ушел».

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

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

4. Ответы на вопросы подписчиков

«Как бороться с синдромом самозванца?)) Что все работают уже долго и все супер опытные»

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

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

Если у вас есть сомнения, вот мои советы:

1. Обратная связь. Чаще запрашивайте фидбек у команды и лида по поводу вашей работы. Скорее всего, уже здесь вы поймёте, что страхи только в вашей голове.

2. Ошибки бывают. Если вы не накрутили опыт, коллеги не будут ожидать от вас «покорения Эвереста» со старта карьеры) Все понимают, что вы — новый член команды, и ошибки допустимы. Как и ваши сомнения. Все через это проходят в начале. Главное — поскорее пройти этот этап и набраться опыта.

3. Коммуникация. Старайтесь налаживать знакомства. Намного увереннее чувствуешь себя на работе, зная, что в любой плохой для тебя ситуации коллеги легко зарефералят к себе в компанию. Еще и с повышением по зп)

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

5. База ваших знаний. Начните вести таблицу или базу знаний. Это сильно поможет расти и чувствовать свой прогресс. Можно завести прямо в Excel: изучил новую технологию, закрыл хорошую задачу — записал это в ячейку и выделил её зелёным цветом. С каждой неделей количество зелёных ячеек будет расти, как и ваша компетенция. Это будет вдохновлять вас продолжать. Вы будете сравнивать себя с самим собой, а не с другими людьми.

6. Боитесь? Не бойтесь. На этом все, с вас 50к. Как сказал бы какой-нибудь психокоуч)
   Шучу. На самом деле, я бы ещё порекомендовал подумать, что вам это дает? Какой профит?
   Это как люди, у которых проблемы в жизни, но они считают, что лучше переживать об этих проблемах, чем решать их. Если хотите решать проблемы — советую первые пять пунктов выше:)

«Здравствуйте. Добавьте пожалуйста процесс самомотивации и трудности изучения на первых этапах.

+ стоит ли покупать мощный ноутбук для флаттер и какие характеристики необходимы для работы во флаттер и эмуляторах»

Проблема самомотивации была у меня в начале, так как сложно выполнять тяжелую интеллектуальную работу каждый день после основного на тот момент рода деятельности) 
Это была одна из причин, по которой я завёл блог. Намного больше ответственности и мотивации, когда понимаешь, что делаешь это не только для себя, но и приносишь пользу людям. 

Насчет мотивации и трудностей — настоятельно рекомендую вести таблицу или базу знаний. С ней вы будете чувствовать себя увереннее и наглядно отслеживать свой рост

Насчет ноутбука — первый год я работал на сборке с китайским xeon и серверной памятью) И не испытывал никаких проблем. Кто не знает, такие сборки с Aliexpress обходятся в ~20 000 рублей.
Потребность в сборках и тестировании под iOS у меня возникла намного позже. Тогда я приобрёл macbook. 

В начале подойдёт и простой ноутбук или компьютер. Со временем, по надобности, проапгрейдите)
В компаниях при трудоустройстве нет требований к личной технике. Даже если есть, вам на вряд ли откажут после собеса, если скажете, что у вас нет macbook. Компании часто сами предоставляют технику.

«Путь достаточно быстрый, есть коллеги которые дольше сидят «в девках»? И почему?»

Есть) Сложный вопрос, но, на мой взгляд, из-за нежелания брать ответственность, синдрома самозванца и нежелания цепляться за возможности. Пример описывал выше в советах.

«Что случилось с желанием свичнуться на iOS?»

Я считал, что на Flutter мало вакансий и хотел свичнуться в натив (iOS мне ближе, чем Android). Попробовал, но iOS мне не зашёл. Компетенция во Flutter увеличивалась, и я решил остаться, это моё пока что)

Да и к тому же, я прислушался к хорошей мысли коллеги: «Какая тебе разница, какое количество вакансий? Ты бери лучшие и все. А таких всегда мало».

«Интересно, как происходил рост по грейду, как это инициировать)

Статья как стать джуном мне очень помогла в свое время))»

Классического роста по грейду как такового у меня не было. У нас была введена система грейдов, когда тебе нужно сдавать для повышения техническое собеседование, но позже её пересмотрели и заменили на performance review. 

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

Чаще всего в компании есть установленные нормы по повышениям в определенный период. Обычно это:

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

2. Performance review. Название говорит само за себя) На основе вашего вклада в разработку и проект вас или повышают, или нет.

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

4. Как это было у меня:
   Вначале повысили после испытательного.
   Написал CEO и сказал, что хочу повышение. Приложил свои достижения в письме. Повысили.

5. Написал HR и сказал, что хочу повышение. Мне сказали сдать на грейд, сдал, повысили.
   Повышение до Team Lead. Мне предложили возглавить проект.

6. Повышение по performance review. Не я был инициатором.

На самом деле, инициировать повышение вы можете, когда хотите)
Но лучше это делать в удобные для вас моменты. Например, когда вы закрыли большой, важный функционал для бизнеса или внедрили что-то крутое. Нужно прийти и запросить. Проще всего это делается через лида. Лид инициирует performance review или сдачу на грейд.
Подробнее повышение до лида я описывал в блоге, не хочу копипастить) Вот пост.
Если кратко, мне позвонил действующий тимлид, с которым мы работали в предыдущих проектах и предложил возглавить проект. Сказал, что я уже достаточно выроc и готов взять на себя такую ответственность. Я согласился. Но это было ещё только предложение.
Через неделю мне написал лид и сказал, что завтра мне нужно быть на созвоне, будут решать насчет моего лидерства в проекте.

На следующий день на созвоне нас было четверо: CEO компании, Head of Mobile, лид моего проекта, я. Они втроём сошлись на том, что я сильно вырос и меня давно пора повышать. Дальше обсудили, что от меня требуется в проекте и какие будут условия (новая вилка зарплаты). Я согласился, меня поздравили, с созвона вышел новый тимлид☺️

«1) Классический вопрос: что качественно отличает лида от сеньера по твоему мнению?

2) Если речь про техлида, 2-й тип, то как ты определяешь приемлемые/неприемлемые предложения/решения разработчиков? Для технички, как мне кажется, нужен опыт в разных ситуациях. Поесть всякого…»

1) Основное отличие — в ответственности. Сеньор отвечает только за техническую часть своих задач. На лиде (если не по типу менеджера) помимо технической части ещё управление командой и в целом ответственность за успех команды разработки.

2) Согласен! Никто не мешает поесть всякого, перенимая, в том числе, опыт старших коллег.
С опытом из разных проектов ты понимаешь, где можно «выстрелить себе в ногу», и не используешь такие подходы. Плюс ты активно общаешься с коллегами и знаешь, с какими проблемами сталкиваются они в соседних проектах.
В компании есть профильные чаты,  где можно обсудить сложные решения или посоветоваться «как лучше». У нас большая  Flutter-команда из 30 человек.

«За счёт чего происходил рост? Софтскиллов или хардскиллов? На что больше был сделан упор?

Было бы очень интересно почитать))»

Сложно сказать, так как ты не можешь измерить ни то, ни то) Меня повысили из-за достаточного уровня хард и софт скиллов. Но в начале я больше внимания уделял технической части. Со временем понял, что профитнее прокачивать ещё и софт скиллы (описывал выше, как пересмотрел свой подход).

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

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

Но техническую часть лучше держать на уровне. Тоже неприятно одно и то же на ревью человеку писать)

«- как сейчас обстоят дела с Flutter? На сколько востребованы флатеристы? 

— легко ли вы находите Flutter разработчиков? Какие ошибки разработчики совершают на собесах и чего им не хватает?»

HH в поиске по Flutter с фильтром в названии вакансии выдает всего 144 вакансии. Мало, если сравнивать с нативом.
Флаттеристы уровня middle+ очень востребованы. Коллеги легко получают нужные им офферы в хорошие компании.

2) Проще всего находятся джуниоры, так как их много)
Чаще всего разработчики просто не добирают баллов на собесе по технической части. 
Бывает так, что по технической части есть пробелы, но человек с горящими глазами, и его берут. Горящие глаза не в плане «у меня два кредита, и очень нужна работа», а в плане «о, я этого не знал, очень интересно, изучу еще». И делает заметки.
Еще это чисто психологический момент) Недотягивающий по технической части кандидат, которому делают оффер — намного более лояльный компании сотрудник в будущем.

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

Очень интересные вопросы, но я не знаю, как на них ответить, не попадая под NDA))