Как из джуна стать сеньором и что сделать чтобы их отличить?

Как из джуна стать сеньором и что сделать чтобы их отличить?

Данная статья рискует стать моей самой короткой статьей. В общем виде ответы на эти вопросы очень простые. Выглядят они примерно так:

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

Тезис 2. Гарантировано отличить джуна от мидла и сеньора может ваш тимлид, отправьте специалиста к нему на собеседование. 

Ничего нового в этом смысле в данной статье не будет. Собственно всё :)

И всё бы хорошо, но...:

1. В такой формулировке задача не отделима от тимлида. А точно ли стоит гонять всех без разбора к нему на собеседование или всё таки должен быть адекватный фильтр?

2. У молодых специалистов где-то до 2‑х лет стажа комплекс самозванца и желание самоидентификации просто космического масштаба. Согласитесь, глупая идея каждый месяц бегать к тимлиду и спрашивать: я уже мидл? А теперь? А сейчас? Тем более что во время роста часто возникает проблема пограничного состояния, когда “поди отличи”, то ли это хай джун, то ли лоу мидл. А ведь от этого зарплата зависит. 

3. А ещё если у вас компания 30+ разработчиков неплохо бы определить некие общие правила игры, по которым люди развиваются и повышают себе зарплату. 

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

Мифы и легенды древней программистики

Для того чтобы ответить на поставленные в заголовке вопросы — необходимо разобраться с главным: что отличает джуна, мидла и сеньора. Вопрос мягко выражаясь не новый, поэтому на этом поле накопилось много мифом. Разберемся с самыми устойчивыми из них.

Чтобы быть мидлом/сеньором надо знать…

Вместо трёх точек можете поставить любую технологию или практику. Вот вам несколько вариантов на выбор:

1. Docker

2. TypeScript

3. ООП

4. Фреймворк (Laravel, Django, Spring, etc)

5. Паттерны проектирования.

Совсем одиозные деятели могут сюда даже язык программирования поставить. Типо все сеньоры кодят на Java/C++. Ну тут даже сказать нечего, в этом случае лечиться надо.

Собственно любая концепция роста построена на технологическом стеке обречена на вымирание. Вот решили вы что у вас в конторе мидл должен глубоко знать реляционные СУБД, а потом… Пришла эпоха NoSQL и принесла вам Mongo. И что теперь? Все ваши мидлы больше не мидлы? Или у вас есть отдельно Middle Postgres Developer и Middle Mongo Developer? Допустим. А если ваш бэкендер захочет перейти в проект с Mongo, он что, временно теряет свою мидловость, пока Mongo не освоит? А зарплату ему надо понижать на это время? В общем все подобные методики которые я видел либо требует серьезнейшей постоянной поддержки, либо существуют больше на бумаге чем в реальности.

Немного лучше дело обстоят с теорией. ООП там или Паттерны. Но! Как только мы говорим, что сеньор должен знать ООП все программисты микроконтроллеров 

Ну а что касается паттернов… Я вот понял что за всю программерскую жизнь (14 лет на самых разных проектах, включая highload) ни разу не использовал Абстрактную фабрику. Вот Фабричный метод использовал. Абстрактную фабрику — нет. И что, увольняем меня из сеньоров?

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

Технологический стек — это то, что необходимо знать, для того чтобы работать в вашем проекте на определенной должности. Всё. На ваш уровень он влияет, но только за счёт того, какой сложности задачи вы можете решать доступным вам стеком. Ну и насколько ваш стек актуален. Я в том плане, что мне как-то не встречались последнее время Senior TurboPascal Developer.

Сеньора делает опыт

Ну здесь справедливо обратное утверждение. На мой взгляд вы не можете быть сеньором имея менее 5 лет опыта. Ниже я расскажу почему. Но это работает только в одну сторону - 5 лет опыта не делает вас сеньором. И с одной стороны это должно быть всем очевидно, а с другой… рынок вакансий работает по другому. Как только у тебя появляются 2 года стажа, ты начинаешь подходить под формальные требования HR, особенно корпоративных. А этим ребятам обычно глубоко плевать кого они там наняли, у них KPI строится от количества собеседований и наймов. Если через полгода ты уйдешь из их корпорации перегоревшим и пережёванным — этим ребятам ни жарко ни холодно. Так что молитесь на адекватных тимлидов. Эти героические товарищи, работая в корпорациях, могут либо таки вас не взять на позицию с которой вы не справитесь, либо таки доучить. Слава и хвала как говорится.

Да и что конкретно происходит с человеком за 5 лет? Если товарищ проработал линейным разработчиком 5 лет — он сеньор или нет? От чего это зависит?

Ну или можно пойти шире и под опытом понимать не просто стаж, а опыт тех или иных проектов. Звучит уже лучше. Можно даже красивые фразы придумать. В стиле “Если ты не деплоил хотфикс на продакшн под вопли пользовательских чатов, то ты не сеньор”. Круто звучит? А если ваша компания специализируется в основном на разработке MVP на заказ? Что, в ней не стать сеньором?

Чтобы стать сеньором тебя должен укусить другой сеньор

С одной стороны иметь наставника который покажет и расскажет, как правильно — понятное и логичное желание. Более того, наличие такого наставника сильно упрощает жизнь. С другой стороны это не работает настолько прямолинейно. Из моей практики самыми лучшими наставниками для джунов являлись… другие джуны! Примерно на полгода имеющие больше опыта. Почему? Да потому что сеньор забыл больше чем, знал джун. Пропасть между ними очень высока. И с одной стороны послушать сеньора всегда полезно, на как решать ваши повседневные проблемы и задачи вам лучше подскажет ваш товарищ, но немного более опытный. Который буквально вчера уже решал те же задачи и проблемы.

В общем никогда не отказывайтесь от того, чтобы пообщаться с сеньором, но сама по себе эта коммуникация вас сеньором не сделает. Хотя и может облегчить ваш путь на определенных участках. Или завести в сеньорские дебри до того, как вы будете готовы. Тут как повезет :)

Чем отличается джун от сеньора?

И так, мы выяснили что:

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

2. Наличие сеньора рядом не гарантирует вам максимально быстрый переход в сеньоры.

3. Стаж и опыт необходимые факторы, но при этом не являются достаточным.

Задача еще усложняется тем что на рынке разные компании, с разными проектами, разными методиками управления, разными бизнес-моделями. И единого универсального фактора “сеньора” вывести невозможно. Однако проведя сотни собеседований и наблюдая их результат, а также ловко подглядывая за коллегами я вывел четыре параметра, которые сильно помогают проводить собеседования, систематизировать работу с ростом людей да и самому ловчее принимать решения в “пограничных состояниях” специалиста. И так, вот они:

1. Алгоритмическая и архитектурная сложность проектов в которых участвовал специалист. 

2. Стадия проектов (MVP, Вывод в prodaction, Развитие и сопровождение).

3. Количество проектов определенной сложности на определенных стадиях, которые он выполнил.

4. Уровень личного влияния на проект.

Ничего нового, да коллеги? Любой нормальный тимлид по сути это спрашивает на собеседовании. Расскажи где работал, в какой позиции, чем конкретно занимался. Ну и конечно тесты на конкретный технологический стек. Собственно от них я и не предлагал отказываться. 

Теперь проверим концепцию, да и покажу как пользоваться. И так. Возьмем товарища который 10 лет занимается фронтендингом лендингов. У него могут быть такие параметры:

И так, сеньор этот товарищ или нет? Сложность у проектов низкая, зато все остальные параметры на высоте. Поскольку выводил в продакшен и сопровождал: знает как те или иные технические решения отражаются на проекте. Сделал более 200, значит действия доведены до автоматизма. Работал один, сам полностью нёс ответственность за результат. В компании которая занимается производством лендингов такой товарищ вполне может быть сеньором и получать очень хорошие деньги. Теоретически. На практике, конечно, может быть по-разному. Может это растрындяй-единоличник. Но это уже проверяется другими методами.

Возьмем другой пример. Товарищ с 1,5 годом стажа.

Уровень технической сложности неплохой. По крайней мере точно выше чем лендинги. Однако товарищ всё время занимался 1 проектом, в рядовой позиции. Скорее всего хай джун.

Ну и третий вариант, товарищ с аналогичным стажем:

Вот этот парень уже может быть мидлом. Участвовал в выводе в продакшн 3‑х проектов. Но тут надо подробнее расспросить про то, чем занимался. А то может он все релизы в носу проковырял.

Именно, кстати, поэтому я не верю в сеньоров с менее чем 5 годами стажа. Вам физически не сделать нужное количество проектов, меньше чем за это время :) Ну или довести до автоматизма работу с мелкими :)

Итого:

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

Работайте на разных стадиях и читайте, читайте, читайте. Не отвлекайтесь на HR-ловушки или всякую дурную рекламу, курсов, информацию с которых вы можете найти в интернете или в документации по языку/технологии. Не бойтесь делать ошибки. Регулярно общайтесь с коллегами и сеньорами, но не увлекайтесь, помните что есть задачи проекта :) Чем больше у вас будет успешно сданных проектов, тем быстрее вы вырастите. Искренне желаю вам успеха на этом пути.

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

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

2. Отдаёте HR, на собеседовании им достаточно дать эту табличку кандидату и попросить отметить нужные пункты.

3. HR делают сводные таблички на кандидатов и вы можете отсеять лишних или лучше понимать что спрашивать на собеседовании.

4. ???

5. Profit.