Как из джуна стать сеньором или в чём вообще разница?

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

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

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

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

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

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

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

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

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

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

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

— Docker;

— TypeScript;

— ООП;

— Фреймворк (Laravel, Django, Spring, etc);

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

Совсем одиозные деятели могут сюда даже язык программирования поставить. Типо все сеньоры кодят на 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 на заказ? Что? В ней не стать сеньором?

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

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

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

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

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

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

Теперь проверим концепцию, да и покажу, как ей пользоваться.

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

Уровень сложности: Обычные лендинги

Стадия проектов: Вывод в Продакшн, Сопровождение

Количество проектов (повторяемость): более 200

Личное влияние на проект: Единолично вёл работу по каждому проекту

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

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

Уровень сложности: ERP-системы

Стадия проектов: Сопровождение

Количество проектов (повторяемость): 1

Личное влияние на проект: Рядовой разработчик

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

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

Уровень сложности: ERP-системы

Стадия проектов: Вывод в production

Количество проектов (повторяемость): 3

Личное влияние на проект: Рядовой разработчик

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

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

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

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

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

Последовательность действий такая: