Как не остаться джуном навечно: дорожная карта к мидлу
Привет-привет! С вами Оля Чеснокова, HR-директор Right line, и эстафетная палочка блога вновь у меня. Это значит, что мы возвращаемся к обсуждению карьеры и внутрянки работы программистов.
Сегодня особенно важная тема для тех, кто только начинает свой путь в IT или работает в этой сфере от пары месяцев до полугода. Как вырасти в грейде и перейти от джуна к мидлу?
Сразу обрадую: сделать это можно довольно быстро! В среднем специалисту для такого перехода требуется от года до трех (в зависимости от направления, компании и внутренней мотивации самого человека!). Главное — грамотно выстроить план действий и не выгореть по дороге🙊
Начнем с определения грейдов
В первую очередь система грейдов нужна, чтобы упростить жизнь рекрутерам и самим айтишникам. Конечно, грейды в компаниях устанавливаются через использование матриц компетенций, которые позволяют оценить уровень как уже работающего сотрудника, так и кандидата. И эти матрицы свои для каждой должности.
Матрица компетенций — это инструмент, который помогает визуализировать уровень навыков, знаний, умений отдельных сотрудников или целой команды. Матрица помогает hr-менеджерам и руководителям принимать решение о повышении специалистов или о переводе их на другие должности.
В разных компаниях свои системы составления матриц. При обсуждении карьеры внутри компании можете попросить рекрутера познакомить вас с их системой оценивания компетенций.
Я приведу упрощенный и обобщенный вариант описания уровней, который подходит плюс–минус всем направлениям разработки. Но помните, что у разных компаний разные стандарты, матрицы компетенций и методы оценки грейдов.
Стажер — подготовительный этап перед полноценным вступлением во взрослую жизнь айтишника. У стажеров, как правило, нет коммерческого опыта работы. Это выпускники курсов по программированию «с нуля».
Устраиваются в компании на стажерские позиции (часто даже неоплачиваемые) как раз ради получения коммерческого опыта или же ищут любые другие форматы сотрудничества: парт-тайм, договор подряда и т.п
Джун — это уже полноценная единица команды разработки. Джуны неплохо разбираются в языке программирования, могут самостоятельно писать базовые конструкции и простые части проекта. Они хорошие исполнители, но из-за недостатка опыта требуют контроля со стороны «старших» коллег и пошаговой инструкции к работе – им пока еще нужно говорить «что» и «как» делать, мониторить в процессе написания кода.
Мидл — наша золотая середина. Как правило, они выполняют ключевые задачи команды, берут на себя больше ответственности, понимают основы архитектуры проекта. Именно они обеспечивают поддержку более опытным коллегам и часто берут менторство над стажерами и джунами. Их не нужно контролировать в процессе работы — достаточно сказать, что нужно сделать и как это видят лиды и продукт-оунеры.
Синьор – это «маг высшего уровня», «легендарный персонаж» в любой команде. Ему не нужно говорить, как сделать проект и уж тем более контролировать правильность выполнения задач. Часто шутят, что синьор появляется на работе на 5 минут, за которые выполняет самые сложные задачи, и исчезает. От него ожидают не просто глубокого знания фреймворков и библиотек, но и понимания архитектуры сайта или проекта. Если синьор захочет, он может стать лидом или развиваться в архитектора.
Дорога от Джуна к Мидлу
Пожалуй, этот переход самый волнительный и важный в жизни программиста. Чтобы вас позвали на долгожданный one-2-one разговор, где торжественно сообщили «Теперь ты мидл, Гарри!», советую включить в to-do list следующие задачи:
- Изучать новое, но не забывать про базу. Возможно, чтобы показать себя с лучшей стороны, вы захотите быстрее перейти к более сложным задачам, но без уверенной базы, увы, — никуда. Оттачивайте знания, а потом переходите к новому. Чтобы при вопросе, как устроен HashMap, у вас не начинал дергаться глаз:)
- Общайтесь с командой. Это и есть ваш главный источник новых знаний. Попросите старших коллег рассказать вам, как принято писать, тестировать и отлаживать код в этой команде, тестировать. Как доставлять его на прод и какие программы стоит изучить на следующем этапе.
Задавайте вопросы. Много! Даже если кажется, что они глупые. Просите фидбэк от руководителя или коллег и делайте корректировки на основе комментариев. Чем больше информации вы получите, тем более подготовленным специалистом вы будете.
Если чувствуете в себе силы взять дополнительные задачи без ущерба основному пулу работ – обязательно предлагайте такую помощь команде. Помните, что больше решенных задач = больше опыта.
- Развивайте самостоятельность. Да, первое время у вас будет ментор, который укажет на ошибки и будет чекать ваш код перед релизом и т.д. Но старайтесь выполнять работу так, будто у вас нет «страховочного троса» в виде наставника. Старайтесь сразу писать хороший код без постоянного контроля со стороны старших коллег, потому что часто от мидлов требуют именно этого.
Старайтесь познавать что-то новое и выходить за рамки своей задачи. Например, изучайте смежные области: аналитику, тестирование, devops. Одно из главных качеств, которое отличает хорошего специалиста, — при возникновении сложностей он пытается их преодолеть, даже если они лежат в плоскости компетенций других специалистов. Естественно, на старте свои решения нужно верифицировать с более опытными коллегами.
Однако, если как специалист вы растете не только в своей области, но и «вширь», то вам проще претендовать на более высокие позиции.
- Читайте и разбирайте чужие коды. Перейдя на уровень выше, вам придется не только проверять работу новичков, но и работать с чужим кодом. На технических собеседованиях для middle-специалистов часто дают задания на поиск ошибки в чужом коде, к этому надо быть готовым. Для этого полезно участвовать в код-ревью.
- Изучайте бизнес-требования. Задача конечного продукта не только стабильная работа кода, но и закрытие всех потребностей заказчика. Смотрите на свойства и функции, которые должен выполнять продукт, и как ваша команда их закрывает – на логику и структуру, а не только правильный код.
Задания со звездочкой:
- Заведите пет-проекты, где можно в спокойном режиме практиковать свои навыки, нарабатывать опыт и создавать то, что нравится только вам.
- Регулярно смотрите сайты и каналы с вакансиями, чтобы отслеживать, какие hard-скиллы сейчас актуальны для вашей специальности и какие требования предъявляют к мидл-специалистам.
- Вступайте в профессиональные сообщества. Задачка не для интровертов, согласна! Но хорошо, что сейчас это можно (и нужно!) делать онлайн. Там вы познакомитесь с такими же джунами или мидлами, которые подняли свой грейд не так давно и могут поделиться советом. Посещайте хакатоны и конференции для вашей специальности.
Моя практика показывает, что переход от джуна к мидлу занимает от года до двух лет в зависимости от компании и специальности. Если по истечению этого времени ваш руководитель не поговорил с вами о переходе, то ответьте на несколько вопросов для себя:
- Сколько задач я довел до прода за последние полгода?
- Какой был процент моей работы от общего проекта? Сколько было закрыто тикетов и эпиков?
- Сколько багов было в моем коде и почему они появились?
- Сколько задач релизят старшие коллеги в нашей команде и готов ли я брать на себя такой объем?
Если после честных ответов на эти вопросы, вы почувствуете, что готовы к разговору о переходе на новый уровень — инициируйте общение с руководителем самостоятельно👍
Финальный чек-лист перехода на мидл
- Крепкая база в языке программирования
- Самостоятельность и развитие в смежных областях
- Новые хард скиллы, необходимые для сложных задач
- Умение мыслить на продуктовом уровне
- Способность читать чужой код и подхватывать чужие задачи
- Умение работать в команде
Переход от джуна к мидлу требует времени, усилий и настойчивости. Развивайте свои навыки, учитесь на практике и не бойтесь обращаться за помощью к более опытным коллегам.
Если вам интересно узнать, как вырасти из стажера в джуны или из мидла в синьоры, пишите в комментариях😉
Больше полезных советов в нашем ТГ-канале.
Мыслить как пользователь!!! А то некоторые увлекаются кодом и структурой, но не тем, что из этого выйдет
100%
Пет-проекты в принципе интересная штука: знакомый делал приложение просто для себя (тоже только начинал в айти), а в итоге оно неплохо раскрутилось
Гуд👍 Я матрицу компетенций стала использовать для собственного трекинга достижений в профессии. Не везде она есть, но штука полезная.
Про нее можно вообще отдельно поговорить😉
Про то, что надо сторонние скиллы развивать и смотреть, что другие делают – в точку. Только спустя время стала понимать лучше, что надо другим спецам в команде, почему коммуникация не идет у некоторых. Понимать, что делают другие - да да да )))