Как джуну перейти на мидл-позицию и оценить свою квалификацию
Ура, вы устроились на первую работу в IT. Но чтобы зарплата выросла до 300K в наносекунду, надо вначале перейти из джунов в мидлы.
Иллюстрация: Artroomstudio / Freepik / Annie для Skillbox Media
Сейчас просто суперконкурентное время, и грань между джунами и мидлами всё больше стирается. Даже если поработать в разных компаниях, то получится выделить лишь самые общие критерии, по которым джуниор может определить, что он готов претендовать на мидл-позицию, и которые он может попробовать примерить на себя.
В карьере разработчика один из самых сложных и нервных этапов — это первый промоушен, когда вы организуете своё повышение. Чаще всего джуниоры не чувствуют, что уже пора выдвигаться на новый уровень. Чтобы понять, в какой момент можно получить оценку качества своей работы, необходимо знать специфику компании, в которой вы работаете. Обычно компании рассматривают наём джуниор-специалистов как инвестицию в будущее. Если коротко, то команда, в которую попал разработчик, скорее всего, ожидает, что через какое-то время джун разберётся в модели бизнеса и будет решать конкретные проблемы, обеспечивая как минимум такое же качество кода, которое уже принято в продукте.
Поэтому есть несколько распространённых вопросов, по которым чаще всего оценивают претендента на повышение:
- Сложность задач. Какие задачи решает джуниор-разработчик? Создаёт ли новую функциональность?
- Качество кода. Как часто после код-ревью или тестирования джуну приходится дорабатывать решение?
- Скорость выполнения. Какое количество задач джун закрывает за спринт?
- Бизнес-модель. Может ли специалист ответить на вопросы развития и цели бизнеса?
- Коммуникация. Принимает ли участие в обсуждении проблем с коллегами и предлагает ли варианты их решения?
Также работодателю важно понять ещё несколько важных нюансов:
- Продолжает ли будущий мидл-специалист учиться.
- Есть ли у него стремление сделать больше, чем от него ждут прямо сейчас.
- Как много джун задаёт вопросов (если относительно немного, значит, джуниор уже что-то понимает в продукте и процессах). Хотя лично я считаю, что вопросы у разработчика должны быть всегда. Questions are good.
В момент промоушена есть достаточно полезная практика — письменно проанализировать и дать ответы на три вопроса:
- Что я сделал хорошо и почему? Тут нужен список задач, которые были решены быстро и качественно. Важно, чтобы эти задачи были достаточно сложными и решали конкретные проблемы бизнеса.
- Какие ошибки я допускал и что не очень хорошо получилось? Тут можно описать моменты, когда у вас что-то не получилось, а также проанализировать, почему так вышло и как вы решили проблему.
- Что я планирую в рамках компании делать или изучать в будущем? Какие конкретные технологии вы будете изучать или какие задачи вы собираетесь брать на себя в ближайшем будущем.
Вообще, вы в любой момент можете пройтись по этим критериям и понять, какой у вас уровень. Я рекомендую начать оценивать себя ещё в первый месяц работы. Если, скажем, через месяц вы зафиксируете рост по первому и третьему пунктам — это уже хороший признак.
Кроме того, можно попробовать самостоятельно оценить по этой методике кого-то из коллег с уровнем Middle или Senior, а потом сравнить их оценку со своими показателями. В некоторых компаниях во время промоушена почти все сотрудники проводят ревью, чтобы определить уровень джуниор-разработчика на фоне всей команды.
Помните, если джун пытается оценить себя сам — это уже хорошо. Это значит, что он стремится развиваться и расти в команде.