Как и зачем вы Senior? (2_финал_финал)
Недавно я опубликовал статью «Как и зачем вы Senior?», которая получила неоднозначные оценки (хоть может и весьма понятные). Какое-то время я не трогал её и перечитал позднее. Кажется, что она действительно не особо раскрывает моё видение вопросов грейда и сущности требований к кандидатам в разных компаниях. Так что было решено сделать лонгрид, в котором я в деталях разверну своё мнение.
Введение
Эта статья будет полезна тем, кто начинает свой путь в индустрии, пытается разобраться в требованиях к грейдам или просто хочет порефлексировать на тему перипетий карьерного трека в сеньора. Я не претендую на конечную истину, просто делюсь своим видением, как учатника найма с обеих сторон. Важно: статья полностью состоит из личного мнения, рассуждений и полезных ссылок. Я на меренно не буду давать временных рамок нахождения в каждом из грейдов, так как это весьма индивидуальная штука и длительность развития в роли может быть очень разной. Мы будем рассуждать о признаках, по которым вы можете понять, что находитесь в той или иной роли (скорее всего), например вас недооценивают или переоценивают (это тоже нужно вовремя заметить, иначе рынок потом больно окатит вас обухом по голове).
Давайте сразу договоримся, что как бы нам не было противно текущее состояние нейминга грейдов специалистов и дико размытая грань мидлов и сеньоров от компании к компании, выбора у нас с вами не особо много, так как это неотъемлемая часть рынка. Причём проблема обесценивания нейминга есть не только в грейдах разработчиков. Так Александр Поломодов классно подсветил в своём посте проблему нейминга C*O. Ещё одним хорошим примером является вымирание шильдика Евангелиста. Так сейчас эту роль во многих компаниях выполянет Developer Advocate (как сказал один мой знакомый DA: прежнее название настолько потеряло авторитет, что пришлось придумать новое). Ещё можно посмотреть подкаст на эту тему.
На самом деле эта проблема не нова и касается не только айти. Так в какой-то момент все внезапно стали менеджерами. Помните эту историю, что везде стали не продавцы-консультанты, а менеджеры по продажам? Или вместо консультантов по турам появились менеджеры в туризме? В какой-то момент эта история дошла до абсурда и менеджерский шильдик прилеплялся через тире почти ко всему.
Про формирование грейдов
Базово грейды в разработке всегда состояли из цепочки: Junior –> Middle –> Senior. Позднее индустрии их стало не хватать, поэтому для нижней плашки выделили Trainee (он же стажёр). Это было сделано для явного отделения совсем нулей от уже прошедших базовыую школу жизни и разработки джунов. К этому моменту рынок порешал, что хороший Junior имеет примерно 1 год опыта и уже способен самостоятельно ориентироваться в пространстве разработки.
Через некотое время сетку грейдов снова начали дробить. Было ли это сделано в угоду урезания расходов на изменении ФОТа или просто для удобство значения для статьи не имеет. Так что просто имеет данность того, что в среднем по больнице грейды разделились следующем образом:
Trainee: тут без изменений, но эта практика вымирает (ИМХО)
Junior: jun- –> jun –> jun+
Middle: mid- –> mid –> mid+
Senior: sen- –> sen –> sen+
Expert?: exp- –> exp –> exp+
Что это вообще за странная сетка такая? В целом вы далеко не всегда встретите именно такую цепочку. Например после сеньора в компаниях не везде применяется шильдик Expert, его так же называют Staff Engineer. Кто это в сущности такой? Мы с вами знаем, что существует ветка развития в менеджерском деле, то есть когда после сеньора вы становитесь лидом и далее уходите в пипл‑менеджмент и управленчество. Но в множестве компаний в нашей стране довольно плохо развита ветка Individual Contributor (IC). В сущности это не менеджерский путь, в котором вы становитесь глубоко погруженным в специфику специалистом, способным принимать стратегические решения. Например это пути в те самые программные архитекторы, fellow и прочие редко втречающиеся у нас позиции. По сути этот трек коротко назыают S+. В целом я часто встречаю истрию, что эта ветка в компаниях ведёт к тому, чтобы не потерять сотрудника, чтобы исключить так называемый стеклянный потолок (этот термин довольно давно ушёл от классической трактовки барьеров для женщин ¯\_(ツ)_/¯).
Почему каждый грейд делится на вот такие -+ шаги? На мой взгляд это происходит из-за неспособности внятно описать ветки грейд-равзития, то есть компания с трудом понимает специфичность сотрудника для себя, не имеет внятной матрицы компетенций и интереса к глубокой проработке оценки. Вы можете вспомнить систему грейдов в EPAM’е, там вообще чёрт ногу сломит от обилия шильдиков, но я не уверен, что это хороший путь. Ну и это отличный способо изменения зп не более чем на 5–10%.
Trainee
Хочу сразу сказать, что я очень расстроен тем, что эта позиция потихоньку стагнирует на нашем рынке. Связано ли это с засильем курсов, накруткой опыта и т.д. я рассуждать не буду. Но происходящее очень пугает. Если вы хотите попробовать стандартизировать развитие Trainee у себя в компани, то можете присоединиться к инициативе JEDI-Framework, где мы пытаемся описать требования рынка к таким кандидатам, методологию их подготовки и развития. Почему вымирание trainee плохо? На мой взгляд рынку нужно вырастить хороших специалистов, понимающих специфику и важные подходы, но при этом не имеющих раздутое самомнение (уж извините, но я тут довольно давно и часто приходится делать какие-то невероятные кульбиты, чтобы удержать тонкое душевное равновесие сеньоров, особенно во фронтенде (ﾉ´ヮ`)ﾉ**).
Отказ от трейни (они же нули) итеративен, то есть происходит с регулярностью стагнации рынка, турбулентных условий и прочих умных слов для ситуция, когда всему капец, держитесь за поручни. По сути трейни — это когда у вас примерно нулевой уровень индустриального опыта и знаний технологий. То есть вы имееть достаточный запас знаний в CS, возможно имеете профильное образование и в вас видят переспективу. Последнее специфично, так как если вас не берут на курс с последующем устройством в ту же компанию, то скорее всего в конце будет печаль.
В целом Trainee может имеет какой-то запас знаний по технологиям, это не всегда обязательно. Базово работа будет строиться вокруг учебных проектов, минимальное участие в реальной поставке фичей в прод. Понимание процесса разработки, поставки и раскатки — это один из основных вызовов для нулей. Туда же включается освоение инструментов и формирование навыков работы в команде, понимание принципов взаимодействия. Основной сложностью тут будет нахождения баланса между обучением и продуктивностью. Примерами задачи на этом уровне могут быть:
Написание небольших тестов для существующего кода.
Исправление каких-нибудь опечаток в интерфейсе.
Документирования кода (классно для понимания проектов в целом).
Разработка простых модулей под полным руководством наставника.
Тут хочется добавить, что я очень люблю нанимать трейни, делал 2 программы обучения «маленьких» фронтендеров. Очень часто на этом этапе встречаются довольно талантливые люди. Я опишу основные качества, которые ищу в кандидатах:
Обучаемость, тут важным показателем является хороший бэкграунд базы в виде CS, понимания синтаксиса языков и т.д., для меня это показатель умения адаптироваться к новой информации.
Умение задавать вопросы, например если не ясна задача (а это нормально) или каких-то вводных недостаточно. Очень круто, когда кандидаты вовремя подсвечивают свои пробелы, например если я оперирую непонятным им термином и они не оставляют это на потом, а уточняют сразу.
Усидчивость. Это сложно передать примером, но условно я бы описал это так: когда в рамках задачи видна системность в попытках решить проблему, возможно это подход к упаковке коммитов, итеративное внесение изменений, спокойный разбор непонятных мест.
Junior
Это этап, на которым вы становитесь полноценным участником команды, то есть вы уже освоились в процессах разработки и поставки, свободно ориентируетесь в системе версионирования и способны самостоятельно выполнять средней сложности задачи. Ваше взаимодействие с наставником превращается в pull-подход, а анализ вашего кода происходит только на этапе ревью. Важно, что с этого момента у вас появляется ответственность за раскатываемый код, появляются доступы и вам нужно быть кратно внимательнее.
Этот грейд наверное находится сейчас в самом плохом состоянии. Требования в разных компаниях имеют какой-то максимальный разлёт. Так в некоторых местах джун — это чуть ли не полноценный мидл. В этот грейд напихивают максимально всё, на любой дуде игрец, ум гибкий, процессы все знает, но делает это непременно недорого. Много где нет какой-то внятной границы куда он там растёт и как. Часто встречается явление джоб-хоппинга для смены зарплаты и грейда. Давайте снова перечислим примеры задач:
Разработка новой фичи или модуля самостоятельно, изучая требования.
Участие в обсуждениях архитектуры и/или процессов.
Внедрение небольших оптимизации, повышение качества кода в проекте.
Исправление багов средней сложности, требующие анализа кода.
В целом для джуна классным качеством является инициативность и самостоятельность. Так многие с большим одобрением встречают людей, которые активно изучают вопрос, формируют наброски того, как и что будет работать и приходят с сформированным списком уточнений. Технолический запрос тут скорее в том, чтобы человек понимал свою платформу и имел представление об экосистеме вокруг. Так хорошо, когда кандидат умеет в тесты, понимает их ценность, имееет представление о том, что такое паттерны проектирование не по статья, а экспериментирует с их внедрением.
Middle
Мидлы — это эдакая «рабочая лошадка». На мой взгляд это ключевые участники команд в разработке. Не забрасывайте сразу минусами камнями, сейчас поясню. Мидл — это опытный профессионал, который обладает глубоким пониманием своего стека технологий и способен решать сложные задачи автономно. Если проще, то он знает ответ не только на ворпос «как», но и «почему» работает так, а не иначе в разрезе кода, а иногда и архитектуры проекта.
На этом этапе вы вносите в свою работу ясность зон ответственности, ролей и послдетствий тех или иных решений. Так же вы начинаете уверенно ориентироваться в методологиях, например Agile. Технический стек вас больше не пугает, вы переходите их уровня «кодера» в разряд «полноценного» инженера. В частности умеете в глубокие оптимизации, спокойно разбираете сложные задачи. Большая ошибка считать, что проектировать архитектуру могут только сеньоры и архитекторы, на самом деле мидлы часто готовят полезную «базовую» архитектуру в рамках проекта, так как они в большинстве ближе к коду, чем сеньоры, как бы парадоксально это не звучало.
Так же тут к вам приходит гораздо большая самостоятельность, то есть вы уже формируете бэклог, занимаетесь приоритезацией задач, можете вести рабочую группу и т.д. Кмк, мидлов крайне не хватает на рынке, это действительно важная часть в дизайне любой команды. Более того, они намного реже толкаются локтями друг с другом, нежели сеньоры. Снова попробую привести примеры вызовов, с которыми чаще всего сталкивается мидл:
Любые конечные задачи решаются с оглядкой на общую архитектуру и влияние изменений на систему.
В общие обязанности начинает проникать наставничество, так как у вас уже достаточно опыта и экспертизы.
Декомпозиция проекта на конечные задачи, которые делают не более одного фича-инкремента за раз. Более того, вы можете ставить и объяснять эти задачи другим участникам процесса (речь про управление рабочими группами).
Любые решения существенно влияют на проект, и вы несёте ответственность за них и их прогнозирование.
Senior
Ну вот мы и добрались до этого раздела. Хочется порассуждать, кто в сущности такой этот сеньор. Изначально этимология этого слова сводилась к чему-то типа государя, землевладельца, то есть управляющий, владеющий чем либо. Позднее основным значением стало: старший, руководящий. В целом последняя трактовка описывает текущее положение этой роли. В сущности от компании к компании в эту роль действительно вкладывают примерно всё. То есть он и лид, и архитектор, и менеджер, и тестировщик, и сами придумайте что ещё.
В своей предыдущей статье я начал с мысли, что интересно взглянуть на сеньоров в разрезе эволюции последних 10 лет. Давайте начём с перечисления основных вызовов прошлого десятилетия:
Глубокое знание 1–2 языков программирования, умение писать высококачественный код и разрабатывать архитектуру.
Экспертность в своём, весьма конкретном стеке (например, Java (ง°ل͜°)ง или .NET).
Написание сложного кода, глубокие оптимизации и решение нетривиальных багов.
Управлять техническим стеком, не вовлекаяся в вопросы бизнеса.
Техническая экспертиза приоритетнее, чем софты, умение договариваться, быть наставником и т.д.
На самом деле требования выше на текущем рынке часто применяют к middle+ грейду, а в последние 2–3 года задачи, стоящие перед сеньорами начали менять вектор. На передний план довольно активно выходят софты, умение находить win-win решения и наставлять других. Я бы описал современные вызовы (на основе личного опыта) примерно так:
Помимо глубокого знания ключевого языка, Senior должен быть знаком с несколькими технологиями и подходами (например, клауд, DevOps, микросервисы).
Глубокая экспертиза в одной области, но также сформированные познания в смежных технологиях. Это так называемый T‑Shaped.
Участие в стратегических обсуждених, понимание, как решения влияют на прибыль компании, сроки выполнения проектов и удовлетворённость клиентов.
Активное обучение менее опытных коллег, помощь в росте, погруженное код-ревью и шеринг опыта.
Коммуникации, управление конфликтами, участие в построении процессов и умение мотивировать команду. В целом идея консолидации людей вокруг технологий — это один из билетов в развитие в IC ветке.
Быстрое освоение новых инструментов, технологий и подходов, чтобы оставаться актуальным.
Умение в обучение, изучение новых и смежных техгологий, гибкость к современным решениям. Например умение холодно оценить перспективы Server Actions (⊙ヮ⊙)
В сущности вы заметили, что я вывожу на первый план софтовый аспект, гибкость и умение в широкий спектр знаний. В найме я регулярно ищу в кандидатах не только технологические знания, то есть стек и т.д., ключевое — это системное мышление, умение в планирование и выяснение запросов. Сеньор не должен решать задачи в лоб, а уметь в выстраивание плана, агрегацию требований, обсуждение тонкостей. Важно, что это не отменяет необходимость в специализации в стеке технологий.
Вопросы в заголовке
Как вы сеньор? В целом к этому вас привела квинтэссенция из вашего опыта, знаний и визионерства. Вы начинаете расти в эту сторону из-за желания влиять на процессы вокруг вас, изменять состояние техстека и т.д. Вы научились на основе опыта быстро локализовывать проблемы, делать системы наблюдаемыми и тестируемыми.
Почему вы сеньор? Ваши навыки позволяют вам видеть связь между техническими решениями и бизнес-целями. Вы умеете руководить процессами, решать конфликты и помогать коллегам расти. Смело консолидируете людей вокруг проблем, стартегически мыслите. Можете в траблшутинг. Осознаёте ответственность за результаты и способны решать нетривиальные задачи.
Буду рад обсудить все тезисы в комментариях, личных сообщениях или в формате отдельной статьи.
Нашли опечатку в тексте? Выделите и нажмите
CTRL/⌘+EnterВсем заинтересованным буду рад в своём тг‑канале.
