Как джуну перейти на мидл-позицию и оценить свою квалификацию

Максим Калик

---

iOS Engineer в Triumph Lab.

---

Ссылки

---

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

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

Поэтому есть несколько распространённых вопросов, по которым чаще всего оценивают претендента на повышение:

• Сложность задач. Какие задачи решает джуниор-разработчик? Создаёт ли новую функциональность?
• Качество кода. Как часто после код-ревью или тестирования джуну приходится дорабатывать решение?
• Скорость выполнения. Какое количество задач джун закрывает за спринт?
• Бизнес-модель. Может ли специалист ответить на вопросы развития и цели бизнеса?
• Коммуникация. Принимает ли участие в обсуждении проблем с коллегами и предлагает ли варианты их решения?

Также работодателю важно понять ещё несколько важных нюансов:

• Продолжает ли будущий мидл-специалист учиться.
• Есть ли у него стремление сделать больше, чем от него ждут прямо сейчас.
• Как много джун задаёт вопросов (если относительно немного, значит, джуниор уже что-то понимает в продукте и процессах). Хотя лично я считаю, что вопросы у разработчика должны быть всегда. Questions are good.

В момент промоушена есть достаточно полезная практика — письменно проанализировать и дать ответы на три вопроса:

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

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

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

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