Что прокачать джуниор разработчику, чтобы стать мидлом за год

Реальные требования к кандидатам в плане инструментов разработки сильно различаются в зависимости от компании и задач. В этой статье поговорим про фундаментальные навыки, которые актуальны для роста в бэкенд-разработке и разработке в целом.

Роман Моисеев, менеджер продукта на программе «Мидл Python-разработчик» в Яндекс.Практикуме, рассказывает, над чем стоит работать, если вы джуниор, который хочет стать мидлом.

Роман Моисеев

менеджер продукта на программе «Мидл Python-разработчик» в Яндекс.Практикуме

Четыре грейда джуниор-разработчика

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

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

Первый — стажёр. Это ещё не полноценный джуниор-разработчик, скорее его MVP. На этом уровне человек знает основы языка программирования, его не нужно учить синтаксису. Однако применять этот язык программирования для решения реальных задач он ещё не умеет. Чтобы дать ему задачу в работу, её нужно расписать по шагам: «сделай A, B и С, возьми такую технологию и используй вот эту вот функцию».

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

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

Тем не менее процесс коммерческой разработки он знает скорее теоретически, поэтому ошибается на разных этапах написания кода. Он часто приходит к старшим коллегам и говорит: «У меня что-то поломалось. Не могу это сделать. Помоги!» И это нормально.

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

Третий — средний джун. Уже прошёл испытательный срок, освоился в компании и процессах командной разработки. Например, знает, какие agile-ритуалы используют в команде и почему. Теперь ему можно давать задачу и не контролировать её выполнение в рамках одного рабочего дня.

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

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

В качестве отправной точки для роста за год я буду рассматривать джуна-новичка. По двум причинам:

• по моему опыту, рост за год до мидла с этого уровня — это очень хороший темп для разработчика;
• многие компании готовы рассматривать кандидатов с опытом от года на позицию мидлов. Главное в этой фразе — «рассматривать»: отбор и заветный оффер это не гарантирует.

Эволюция сложности задач

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

1. Разогреть в сковороде немного подсолнечного масла.
2. Разбить и бросить в неё два яйца.
3. Немного посолить.
4. Подождать 3 минуты.
5. Яичница готова!

Если вдруг стажёр разобьёт яйца, и скорлупа попадёт на сковородку, сениор объяснит, что так делать нельзя.

По мере роста уровня разработчика растёт уровень самостоятельности. Мидлу уже достаточно сказать: «Нужно сделать яичницу». Он уточнит, какой вид яичницы нужен, например, нужно ли добавить сыр и помидоры, найдёт все ингредиенты и приготовит вкусный завтрак.

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

Кто такой мидл

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

Чисто сениорских задач в разработке мало. Большинство компаний решает достаточно стандартные задачи. И вот с этими задачами мидл должен уметь справляться самостоятельно. Для этого нужен достаточный опыт и накопленный багаж совершённых ошибок.

Hard skills мидла

Перед тем, как перейти непосредственно к списку требований, обозначу три важные вещи:

1. Здесь не будет конкретных технологий, которые нужно изучить. Во-первых, требования к технологиям в разных компаниях очень сильно отличаются. Во-вторых, если главный критерий мидл разработчика — «самостоятельность в решении своих задач», полезнее всего выделить фундаментальные вещи, которые помогут к этой самостоятельности прийти.
2. Это не список «сделай 10 конкретных шагов и стань мидлом». К сожалению, такого волшебного пути нет. У каждого разработчика он свой. Советую читать требования ниже так: «Чем больше галочек я набрал, тем более вероятно, что я мидл».
3. Вы можете переработать этот список в свой чек-лист действий для роста до позиции мидла. Для этого вам понадобятся навыки приоритизации и декомпозиции цели. Небольшой спойлер: это и есть важные навыки мидл-разработчика.

Какие качества ждут от мидл-разработчика

Понимание используемых технологий

Для мидла инструменты, которые он использует в работе, и разработка в целом не должны быть магией. Джуниору простительно не задумываться над тем, как работают какие-то конструкции языка, а просто писать рабочее решение. Мидл должен задаваться вопросом, как работает программа, которую он пишет. Он должен уметь объяснять её простыми словами, чтобы другой человек понял.

Чтобы прокачать этот навык, как можно чаще задавайте себе вопрос, как работают вещи, которые вы используете. Вопросы должны начинаться со слов «как» и «почему». Приведу пример с базой данных:

• Почему <название базы данных> подходит для решения поставленной задачи?
• Как работают индексы в <название базы данных>?
• Почему они работают именно так?

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

Прохождение и проведение code-review

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

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

Проведение код-ревью, напротив, — во многом техническая задача. Умение разобраться в чужом коде распадается на два навыка: понять общую структуру программы и увидеть места, где решение можно сделать более оптимальным, лаконичным и красивым. А ещё код-ревью — это отличная возможность поделиться своим опытом.

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

Умение декомпозировать задачи

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

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

Насмотренность

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

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

Понимание алгоритмов и области их применения

Алгоритмы ― это очень холиварная тема, потому что в повседневных задачах они используются очень редко. Тем не менее это единственная фундаментальная вещь, которая остаётся неизменной в быстро меняющемся мире разработки.

Рассматривайте алгоритмы и структуры данных именно как фундаментальную базу. Не мучайте себя академическим подходом — приземляйте алгоритмы на практику, изучайте их применение в коммерческих технологиях. Понимайте причинно-следственные связи, почему те или иные вещи работают именно так, как работают. Не зазубривайте бинарный поиск просто потому, что «надо знать алгоритмы».

Умение писать скучный код

Задумайтесь, насколько код, который вы пишете, будет понятен человеку, который видит его впервые. Помогут ли ему ваши нестандартные решения? Мидл всегда выберет простое решение, вместо того чтобы выпендриться.

Soft skills мидла

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

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

Какие мягкие навыки ждут от мидл-разработчика

Самостоятельность

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

Мидл не требует микроменеджмента. Контроля раз в день с формулировкой «как у тебя дела, что делаешь сейчас?» достаточно, чтобы быть уверенным, что задача будет выполнена.

Умение видеть проблему бизнеса в технической задаче

Мидл должен понимать, что его главная задача ― не просто писать код. Разработчику платят за техническое решение бизнес-задачи.

Бывают ситуации, когда нужно донести до команды факт, что задачу делать вообще не нужно. Или нужно, но не с поставленными изначально требованиями.

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

Увлечённость разработкой

Покажите будущему тимлиду, что разработка вас драйвит. Объясните, почему вы делали проекты и задачи, которые записаны у вас в резюме. Даже тривиальные и обыденные вещи можно раскрыть через призму выводов и полученного опыта, а не с позиции «я просто писал код на Django на последней работе».

Как рассказать о задачах, которые вас действительно не драйвили, и не обмануть собеседника? Расскажите о том, какими задачами вы точно не хотите заниматься. Это тоже выводы и опыт, которые показывают вашу осознанность. Это ещё и возможность показать свои собственные pet-проекты, где вы реализовывали интересные вам задачи.

Саммари и заключение

1. Единого понимания грейдов разработчиков в индустрии нет, и это нормально: разные команды выдвигают разные требования в зависимости от своих задач.
2. Главный критерий роста разработчика — ответственность и сложность задач, которые он может решить самостоятельно.
3. Мидл должен быть самостоятельным разработчиком и решать большинство падающих на него задач без помощи старших разработчиков.
4. Фундаментальные навыки вроде умения разобраться с новым инструментом часто важнее, чем опыт работы с конкретной технологией.
5. Сейчас век командной разработки, поэтому софты не менее важны, чем харды.