Это рубрика, в которой эксперты отвечают на актуальные и волнующие вопросы об IT-профессиях, будущем сферы и ее перспективах.
Что отличает джунов от мидлов?
Первый критерий — срок работы
Рекрутеры при просмотре резюме автоматически определяют специалистов мидлами, если они работают от трех лет на одной должности и с одним стеком. При этом техническое интервью может показать, что соискатель еще не достиг этого уровня или же, наоборот, уже находится на ступень выше.
Второй критерий — взаимодействие в команде
- Джун знает базу или теорию, имеет небольшой практический опыт, но нуждается в поддержке наставника. Старшие коллеги помогают решать задачи, обучают работе со стеком, координируют и проверяют конечный результат.
- Джун+ — это сотрудник, который уже частично автономен в работе, но еще нуждается в поддержке наставника. Если смотреть по сроку работы, то обычно он варьируется от года до трех лет.
- Мидл и мидл+ работают автономно, уже успели реализовать проекты и знают, где найти нужную информацию, чтобы восполнить пробел в знаниях. Главные отличия от джунов — самостоятельность и скорость закрытия задач.
Как оценить свой уровень?
1. Честно ответьте на вопросы:
- Как часто обращаетесь за помощью к наставнику?
- Увеличилась ли скорость работы?
- Допускаете ли меньше ошибок в процессах?
- Улучшилось ли качество работы?
- Нужно ли еще обращаться к материалу, по которому обучались профессии, или основная информация уже в голове?
Если большинство ответов направлено в сторону ускорения, улучшения и автономности, то с большой долей вероятности вы выросли из уровня джун.
2. Пройдите технические задания, которые предлагают соискателям уровня мидл в вашей профессии. Примеры найдете в интернете. По мере выполнения заданий вы поймете, дотягиваете ли до повышения.
3. Посмотрите, как решают задачи коллеги на уровне выше. Ваш ритм и формат взаимодействия соответствуют их работе? Если да, то вам пора задуматься о повышении.
4. Иногда себя сложно оценить, поэтому запрашивайте обратную связь у руководителя или наставника. Опытные коллеги помогут определиться и понять уровень должности.
Как попросить повышение, если осознали, что вы больше не джун?
Шаг 1: оцените свои желания и возможности
Честно ответьте на вопросы: готовы ли взять ответственность за младших специалистов? Какой уровень оплаты ожидаете при переводе на новую должность? Хотите ли расширить социальный пакет?
Шаг 2: докажите, что готовы к повышению
Подготовьте данные для руководителя, которые подтвердят ваш уровень: реализованные проекты, скорость закрытия задач, степень автономности, отзывы коллег и количество доработок. Докажите числами и статистикой, что готовы взять больше ответственности.
Не сдавайтесь, если вам отказали в повышении. Уточните у руководителя, почему он принял такое решение и какие навыки важно подтянуть. Вместе подготовьте план «Что сделать, чтобы через полгода продвинуться по карьерной лестнице».
Лично я оцениваю уровень специалиста по следующим критериям.
1. Насколько разработчик самостоятелен при реализации задач?
Дело в том, что в работе начинающих разработчиков часто возникают моменты, когда человеку нужна помощь старших товарищей. Причины могут быть разные:
- незнание тонкостей проекта;
- недостаточно опыта для решения данной задачи;
- непонимание требований и т.п.
Если в команде есть процесс code-review, то разработчики более высокого уровня тратят время на проверку кода. И зачастую выходит так, что у более опытных сотрудников уходит больше времени на помощь и проверку задачи, чем на ее самостоятельное решение. В этом случае можно сказать, что команда заплатила дважды за одну и ту же работу. Это нормальная практика для получения в долгосрочной перспективе еще одного хорошего программиста в команде.
Однако, пока старшие товарищи тратят на помощь, проверку и обучение времени больше, чем на самостоятельную реализацию задач, не стоит бежать за повышением. Лучше сосредоточиться на развитии и начать приносить команде реальный профит и разгружать сотрудников.
Что для этого можно сделать?
- Разбирайтесь в специфике и пользовательских сценариях проекта, над которым работаете.
- Потратьте дополнительное время для углубленного изучения инструментов, которые используются в проекте.
- Выясните, кто за какую часть проекта отвечает, и познакомьтесь с аналитиками, которые ставят задачи. Таким образом вашему руководителю не придется водить вас за руку, вы сможете самостоятельно находить правильного человека, который будет готов ответить на ваш вопрос. Это может сильно сократить время поиска нужных ответов.
2. Какова сложность задач, которые разработчик начал решать самостоятельно?
Это довольно субъективная оценка, однако она является одной из ключевых. Очевидно, что задачи могут иметь разную сложность: бывают мелкие баги или доработки — например, опечатка или необходимо переименовать кнопку. Но есть и задачи, которые будут очевидно лучше соответствовать уровню middle. Если говорить про backend, то такие задачи будут включать в себя:
- изменение API;
- работу с базой данных в виде написания новых запросов или даже изменения структуры хранения;
- изменение или расширение бизнес-логики приложения.
Если вы уверенно выполнили несколько задач такого уровня самостоятельно, то вам точно стоит запланировать разговор с руководителем о повышении.
3. Как разработчик подходит к решению задачи и насколько глубоко продумывает решение?
Если при получении задачи вы видите какие-то слабые места в реализации или неучтенные факторы в постановке и предлагаете способ решения, задумываетесь о том, как будет поддерживаться ваш код в будущем и закладываете в реализацию возможность расширения, то это будет огромным плюсом при принятии решения о повышении.
Конечно, кроме этих критериев не нужно забывать о навыках коммуникации и хорошо общаться с другими членами команды, потому что вряд ли вы получите повышение, если будете конфликтным человеком.
Теперь давайте поговорим о том, как лучше разговаривать о повышении.
Попробуйте сначала выписать для себя, чему вы научились и какую пользу принесли команде за период работы в компании. Если вы понимаете, что у вас достаточно достижений по ранее перечисленным критериям, то просто попросите звонок или встречу с руководителем один на один.
Конечно, не стоит начинать диалог с ультиматумов. Лучше показать в диалоге, что вы хотите не только повышения, но и дальнейшего профессионального роста. Например, можете сказать: «Я хорошо погрузился в проект, уверенно выполняю задачи и хотел бы поговорить о дальнейшем росте. Что мне нужно сделать и на чем сфокусироваться, чтобы получить повышение?»
Если вы уже соответствуете более высокому уровню, то, скорее всего, вам скажут: «Окей, я попробую согласовать твое повышение» — и дадут рекомендации, на чем стоит фокусироваться дальше, расскажут про наиболее слабые места. Если же вы еще немного не дотягиваете, то получите четкие критерии вашего повышения, достигнув которых, можно будет провести разговор повторно.
Некоторые люди пытаются получать повышение, принося оффер другой компании или сразу заявление на увольнение. Это точно не лучшая практика. Да, если вы ценный сотрудник, то вам поднимут зарплату, но в дальнейшем будут относиться с осторожностью, потому что будут понимать, что вы можете в любой момент снова решить покинуть команду. Ставку на ваш профессиональный рост будут делать менее охотно.
Бывают и компании, которые ставят перед человеком нереальные критерии роста или очень неохотно говорят про повышения и постоянно меняют условия. Если вы попали в такую компанию, то, возможно, поиск новых возможностей для вас наилучший вариант.
