Советы джунам от сеньор-разработчика. Как расти быстро и не убить интерес к работе?

Поговорили с нашим преподавателем Сергеем Самойловым, тимлидом в «Сбере» о том, что отличает джуна от сеньора, как расти в карьере, сохранять интерес к разработке и найти команду, в которой ты будешь развиваться.

В интернете уже есть множество информации о классификации разработчиков по уровням, но четкие требования IT-среды к джуниорам, мидлам и сеньорам не сформулированы.

Крупные компании, наподобие Mail.ru, Яндекс задают вопросы по алгоритмам, архитектуре и другим темам. У них есть условный список вопросов, ответив на которые можно определить свой уровень. Есть другие компании, которым более важен опыт работы — они задают практические вопросы. Важно понять, что это скорее уровень внутри компании, но не рынка. Но можно попробовать выявить некоторые схожие черты.

Если разница между джуном и сеньором зачастую очевидна, то между мидлом и сеньором далеко не всегда. Часто мидл+ разработчик воспринимается как синьор с некими послаблениями.

Аналогичная ситуация с Junior+ и Middle. Например, если для сеньора может быть большим провалом незнание работы технологий в проекте, то для уровня мидл это вполне допускается. При этом большинство вопросов могут быть одинаковыми.

Давайте попробуем выделить 3 фактора, которые зачастую берутся во внимание:

• Уверенность на собеседовании. Этот критерий не совсем справедливый, но таково положений вещей. Важно умение убедить работодателя в том, что ты подходишь на позицию Middle или Senior. Зачастую человек приходит устраивается мидлом, а мог бы пройти сеньором, но он про это не знает или не может в этом убедить. Бывает и наоборот. Человек отлично проходит собеседование, но в работе оказывается на уровень ниже. Уверенность в себе и умение себя показать — одни из самых важных навыков при собеседовании и приеме на работу.
• Опыт и навыки. Если мидлу позволительно чего-то не знать, то сеньору необходимо знать весь проект, его архитектуру. Часто задают вопросы о том, как устроены технологии, с которыми разработчик сталкивался.
• Время работы. Странно видеть претендента на позицию сеньора с опытом работы год. Такое бывает, но крайне редко.

Приблизительное время, чтобы достигнуть определенного уровня такое:

Только начал свой путь в IT — стажер.

1-2 года работы — джуниор.

2-4 года — мидл.

от 4 лет — сеньор.

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

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

Выделили ряд пунктов, которые помогут вам не застревать на одном уровне.

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

К сожалению, бывают и другие случаи. Если вы чувствуете, что не растете и при этом никаких вариантов в рамках компании нет, то приходится менять работу. Зачастую кандидаты на собеседовании так и рассказывают про свое прошлое место работы. Вначале все было хорошо, но потом надоели монотонные задачи и нет никаких вариантов роста.

Самый плохой вариант — просто выполнять монотонные задачи и ждать, пока появятся задачи, на которых ты сможешь развиваться. Такое встречается достаточно часто. Поэтому нужно постоянно спрашивать себя: «Узнал ли я что-то новое за 3-4 недели?». Если нет, то надо подумать, как сделать так, чтобы была возможность заниматься новыми вещами.

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

Если первый проект может быть не так важен, то к последующим нужно подойти более осознанно.

Если ты новичок, круто попасть в команду, которая только начинает проект и выстраивает все процессы с нуля.

Хорошо работать над проектом, где выстроен как технологический процесс, так и социальный. В первом случае это код ревью, DevOps, готовые архитектурные подходы и так далее. Можно быстро развиваться в команде, где уже есть 1-2 опытных разработчиков.

Во втором случае хорошо может подойти Scrum, Agile. Важно, чтобы люди не просто сидели по углам, а постоянно общались между собой, обсуждали доработки, архитектуру, код.

Есть косвенные признаки, который поможет понять обстановку в команде.

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

Почему это важно? Если команда ничего не обсуждает, а за любую ошибку тебя ругают и агрессируют, ты будешь долго собираться с мыслями, это будет сбивать. На такой работе некомфортно и там большая текучка.

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

Понять, как выстроены процессы в команде, можно еще на собеседовании. Для этого нужно отвечать честно на вопросы и спрашивать, что тебе интересно. Так можно быстрее понять, подойдет ли вам компания. Особенно если это не первая работа и приходит множество предложений.

Можно смоделировать различные рабочие ситуации и задать вопросы: как выглядит рабочий день, как и кто распределяет задачи, к кому можно обратиться, если непонятно, как делать задачу. Тут нужно самому думать, что тебе подходит. Можно целиком смоделировать ситуацию реального рабочего дня. Это даст достаточное понимание того, что тебя ждет.

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

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

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

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

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

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

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

Одна из больших преград у людей, которые изучают программирование — профессиональное выгорание. Бывает такое, что человек излишне себя перегружает: сначала 9 часов работает, дома что-то доделывает, потом занимается своим проектом и не высыпается.

Когда люди чрезмерно зацикливаются на одном, им становится просто скучно. Изучают технологии, которые нужны им для проекта и через год теряют интерес. Нет желания читать не только что-то, связанное с работой, но и с программированием в целом.

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

К примеру, ты пишешь на Spring, изучаешь его разные части. В какой-то момент понимаешь, что больше не хочешь. Не надо себя заставлять. Если надоело, то лучше не делать через «не хочу». Гораздо эффективнее будет сделать перерыв и вернуться к этому попозже.

Чаще всего знания, которые ты думал, что никогда не пригодятся, неожиданно помогают найти новое решение. Лучше всего стараться поддерживать свой интерес. Если интереса не будет — не будет и развития.

Со временем и интерес и к старой теме вернется. И можно будет с новыми силами изучать необходимое.

Центральная нервная система у нас одна. Не стоит перегружать себя в сложные жизненные моменты. В долгосрочной перспективе это принесет только вред. Не стоять на месте, а развивать навыки поможет вам OTUS. Здесь вы найдете множество программ по разным направлениям.