Как вы выросли в Senior?

 Публичный пост

Привет Клуб, внезапно, не сумел по поиску найти подобных вопросов или постов с похожей формулировкой.
Хотя казалось бы, наверняка каждый Senior проходит этап когда надо будучи мидлом окуклиться и назвать себя синьором для того чтобы и остальные тоже начали.

В моём случае с джуна до мидла рост оказался довольно простым: я просто работал, читал книжки, проходил курсы по отдельным инструментам.
Будучи Data Engineer это соответственно были инструменты для ETL/ELT, повышение скиллов кодинга, чуть более глубокое понимание работы баз данных в OLAP-сценарии, немного изучение того что из себя представляет data modelling и зарплата как-то сама по себе с парой сменой работ выросла до уровня когда джуном называть себя неприлично и дискредитирует старания других джунов.

А вот с синьором всё уже кажется сильно туманнее. Поиск по hh выдаёт порой кардинально разные требования.

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

И всё +/- меняется от вакансии к вакансии. Не уверен, специфика ли это молодого data-направления, или это норма и разрабы сталкиваются с той же ситуацией?

Как с этим бороться? Идти и ботать всё что перечислено во всевозможных требованиях? Или смириться и развиваться в одном направлении где уже достиг каких-то успехов?

Как этот этап прошёл конкретно у вас?

39 комментариев 👇

Победил предыдущего сеньора

  Развернуть 1 комментарий

Senior это когда ты перестаешь хуесосить менеджеров и \ или заказчика и понимаешь что вы с ним на одной стороне.
Остальное сразу придет.

  Развернуть 1 комментарий

@mikebutrimov, а как ты ощущаешь общую лодку? Я к тому, что я был там, где ощущал общую лодку (прямая работа с заказчиком, полный контроль и доверие), и где не ощущал (размытые зоны ответственности, отсутствующий вижн, недоверие и т.д.). Получается я был синьором, а потом даунгрейднулся.

  Развернуть 1 комментарий

@kraiz, я рад, что ты спросил. Я, как разработчик, ощущаю общую лодку в первую очередь в себе, в команде и, в лучшем случае - на уровень выше.
И общая лодка состоит ровно в одном вопросе: "а не хуйню ли я делаю". И если у меня возникает ощущение что хуйню, я обсужу это с командой, с PM и (через него) с заказчиками (если они есть) а если нет, то прошу уже PM ответить на вопрос "а не хуйню ли он делает и почему нет".

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

Более цивильный вариант этого вопроса (он же - вопрос для того, чтобы выводить всех из себя на собраниях, обсуждениях, планированиях, докладах и тд.): Какова цель проекта?

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

  Развернуть 1 комментарий

@mikebutrimov, или начинаешь хуесосить не за спиной, а на митингах

  Развернуть 1 комментарий

Короную тебя в сеньйоры этим комментарием.
Можешь указывать это в резюме.

Вообще, не существует никаких логичных и объективных критериев для этих лычек.
В одной компании сеньйор это человек с N годами опыта, в другой со знанием технологии X, в третьей просто самый опытный сотрудник.
При смене компании их грейд может поменяться относительно местных метрик, как в верх, так и вниз.

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

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

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

  Развернуть 1 комментарий

@filinsrg, ну вот подход с "пусть сами решают нравлюсь я им или нет" я тоже сейчас практикую.

Другое дело что чтобы на хлеб мазать больше вкусностей хочется иметь какое-то целеполагание, понимать куда расти чтоб лычка синьора не только звучала круто, но ещё и оплачивалась.

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

  Развернуть 1 комментарий

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

Так думаю.

  Развернуть 1 комментарий

@achevozerov, вот тебе пища для размышления, про типы даже не сеньоров, а стафф инженеров https://lethain.com/staff-engineer-archetypes/

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

  Развернуть 1 комментарий
Yury Katkov в шаббатикале 22 октября 2023

Мне показалось, что составляющие следующие:

  • ты себя так называешь и не краснеешь,
  • где-то написано, что у тебя N лет опыта, и этому верят
  • ты не проебываешь задачи слишком уж откровенно
  • ты не слишком бесишь окружающих, а потому ловко договариваешься насчет того, какую задачу решать надо, какую не надо, а какую можно решить на полшишечки
  Развернуть 1 комментарий

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

На примере DE:

  1. Если большая часть твоих задач это что-то типа: напиши вот такой ETL в AirFlow с вот-такими заданными input/output - то ты скорее всего джун, ну или по крайне мере делаешь работу джуна.

  2. Если ты можешь работать с задачами вида: нам нужно настроить кафку таким образом, чтобы бы обеспечена персистентность и чтобы события при этом максимально быстро долетали до аналитической БД - то это уже больше похоже на мидла. Кто-то уже определил инструмент и задачу, но не вдавался в детали реализации, так как ты и сам разберешься, даже если с самим инструментом раньше не сталкивался.

  3. Если тебе можно сказать что-то из серии: мы стали много платить за сервера БД, причем динамика очень неприятная, нужны идеи как это можно было бы оптимизировать - то вот это уже сеньорская задача, так как тебе озвучивают конкретную цель, оставляя выбор инструментов и вариантов реализации полностью тебе.

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

  Развернуть 1 комментарий

@askazimirov2, хороший и простой способ определения сеньорности.
Я бы ещё добавил к твоему третьему уровню способность самому искать и находить высокоуровневые задачи, как признак сеньорности.

  Развернуть 1 комментарий
Yury Kuznetsov DevOps, недорого. Выезд к вам/ удаленка / любые допы за € 21 октября 2023

Случайно увидел что у кого-то из бизнеса был записан в табличке как Senior support engineer.
Подумал, что я достаточно стар для этого дерьма, и в резюме тоже приписал.

  Развернуть 1 комментарий

В продуктовом дизайне сеньорство часто связано со способностью деливерить end-to-end решения и брать за них ответственность.

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

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

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

  Развернуть 1 комментарий

@rdtrifonov, Кстати у бизнес/системного аналитика , по моему опыту, не сильно отличается целеполагание и подход к задаче.

  Развернуть 1 комментарий

@alexbakl, на самом деле в какой-то степени зоны ответственности в продуктовой команде часто пересекаются.

У меня частенько горело от того, что ко мне бизнес-аналитики (по смыслу CIT) приходили с уже каким-то однобоким решением, совершенно не учитывающим особенности пользовательского взаимодействия и в целом поведения людей в цифровой среде. Мытьем и катаньем, но научил их приходить ко мне с задачей, а не с решением.

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

Кажется, CIT бизнес-аналитики остались только в агентствах и галерах, где нет собственного продукта.

  Развернуть 1 комментарий

@rdtrifonov,

бизнес-аналитики (по смыслу CIT) приходили с уже каким-то однобоким решением, совершенно не учитывающим особенности пользовательского взаимодействия и в целом поведения людей в цифровой среде

В шею таких бизнес/системных аналитиков.

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

Опять же в шею таких бизнес аналитиков.

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

  Развернуть 1 комментарий

@rdtrifonov, не согласился бы с вами в части про кандибобер. То что вы описываете скорее задача продакта (понять а нужен ли вообще кандибобер клиенту). Найти ответ на этот вопрос он может как раз с помощью сеньора-помидора, потому что может оказаться, что кандибобер будет делать дольше и дороже, чем кепку, а заказчику тупо надо чтобы голову не напекало.

Задача сеньора отвечать на вопрос «как» а не «что».

  Развернуть 1 комментарий

@ofilinyuk, потому я и говорю про продуктовый дизайн. Продакт может задать направление мышления для дизайнера, но не может прийти с решением и сказать "надо вот так".

В случае с кандибобером продакт не может прийти и сказать "клиент хочет кандибобер, но на самом деле ему нужна шапка-ушанка, приступай к пошиву". Продакт может прийти с постановкой задачи "клиент хочет кандибобер, потому что считает, что ему морозит уши". А дальше уже задача лида проекта/сеньора разбираться, что там кто считает, морозит ли или нет и все такое.

Решение принимает как раз либо сеньор, либо лид, если он есть.

  Развернуть 1 комментарий

@rdtrifonov, а вот и нет. Это все задачи продакта. Если продакт сам не может понять нужен ли клиенту кандибобер или шапка-ушанка, то грошь такому продакту цена.

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

  Развернуть 1 комментарий

@ofilinyuk, тут на самом деле двоякая ситуация. Я готов согласиться с тем, что продакт тоже принимает некоторе участие в том, чтобы придумать решение, но он делает это далеко не единолично.

Мне повезло работать с продактами, на плечах которых была аналитика и общение со стейкхолдерами (в прямом смысле стейкхолдерами типа акционеров и C-level), а также верхнеуровнеая продуктовая стратегия. И ко мне всегда приходили с проблемой, а не с решением.

Так же, как и в твоей ситуации, я готов заявить, что дизайнер (продуктовый), который все принимает на веру от продакта или бизнес-заказчика (если нет продакта), тоже ничего не стоит. Это Photoshop puppy, а не дизайнер продукта.

Тут еще накладывается тотальный обсёр российского рынка, в котором большая часть продуктовых команд не видит разницы между UX/UI-дизайнером (который главный по тарелочкам в области пользовательского опыта и взаимодействия с системой) и дизайнером продуктовым (ответственность которого лежит far beyond собственно интерфейсов и пользовательского опыта).

В моем понимании продуктовый дизайнер — это продолжение продакта, а не его инструмент, и мой опыт это только подтверждает. Но может, мне просто повезло.

  Развернуть 1 комментарий

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

  Развернуть 1 комментарий

Стал синьором, когда прошел собес на вакансию синьора. Для этого ничего особо не делал - просто работал.
На предыдущей работе не было грейдов.

  Развернуть 1 комментарий

Иногда мне кажется, что все дело в неумении держать язык за зубами и чувстве прекрасного. Приходишь на проект, хочешь писать код и чтобы тебя никто не трогал. Проходит неделя, проходит месяц, сдаешься и пишешь "посоны, у нас здесь продуктовое говно проблема" - "ох, блин, действительно так надо исправлять все взорвется". Или просто лезешь разбираться не в свой кусок проекта и начинаешь объяснять, что лучше так, а не так, потому что будут проблемы, и так сделать быстрее, и тд и тп. А потом чинишь.

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

Все это укладывается в умные cхемы развития, о которых уже сказано в треде, но самоощущение именно такое.

  Развернуть 1 комментарий

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

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

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

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

Общий совет - пойми какое направление интереснее, стань хорошим специалистом в конкретной области. При этом уделяй внимание софт-скиллам и подходу к работе.

  Развернуть 1 комментарий

Прокачайте предпринимательское мышление, забудьте о лычках и мыслите терминами рынка. Тогда вам станет понятно, что в мире айти вы обмениваете свои компетенции на деньги. Хардовые, софтовые, бизнесовые -- неважно, какие это будут компетенции, если 1) они у вас есть, 2) если для них есть рынок и 3) вы можете продать их (человеку, компании, инвестору, государству, да и в принципе кому они будут нужны и кто готов за них платить -- на ваше усмотрение).

  Развернуть 1 комментарий

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

Планирование с точки зрения бизнеса упрощенно выглядит так:
Пусть среднерыночная оплата сеньоров за задачу - x, а мидлов - y. Чтобы реализовать определенный проект в определенные сроки, нужно сделать несколько задач разных типов. Допустим, 5 задач посложнее, которые умеют решать только сеньоры, и 6 задач попроще, которые смогут решить и мидлы. Соответственно, стоимость проекта для бизнеса 5x+6y. Требования к грейдам для бизнеса в данном теоретическом примере определяется косвенно, из формулировки что такое задача попроще и посложнее, а на практике - из исторически сложившейся практики, оценок студий, у которых заказывали и так далее. В случае если проект разовый или постоянный, но с небольшой командой, бизнес скорее всего даже не будет точно формулировать требования к грейдам, только вилки.

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

  1. Когда я работал в небольшой студии разработки, грейдов там не было вообще, потому что не было задач, которые можно было бы с помощью них решить. Зарплаты обсуждались с каждым разработчиком индивидуально, потому что так было проще и менее трудозатратно, чем формулировать требования к грейдам для условного десятка человек, а рост разработчиков внутри бизнес не интересовал пока они продолжали решать задачи бизнеса.
  2. Когда я пришел в компанию на активной стадии роста, где в начале работало порядка 30 разработчиков, требований к навыкам для грейдов тоже не было, были только вилки, исходя из которых бизнес планировал найм новых команд и затраты на текущие команды. Оценки грейда нового разработчика на входе работали из логики - вот примеры задач, которые у нас решает сеньор, этот кандидат судя по результатам отбора сможет их решать, значит мы можем предложить ему зарплату сеньора (но опять же формализован этот список задач не был). Когда разработчиков стало больше, и вопросы из категории "что мне нужно сделать чтобы получить повышение" стали звучать регулярно, бизнес решил разработать требования к навыкам для грейдов, потому что это стало менее затратно, чем рассматривать каждый случай отдельно. И эти грейды исходили из типичных решаемых задач и учитывали особенности самого бизнеса - например, структуру команд и обязанности тимлидов, которые от компании к компании отличаются.
  3. В текущей компании уже я взял на себя разработать требования к грейдам. Естественно, я учитываю предыдущий опыт, но я не могу просто так взять грейды из прошлой компании - потому что в этой компании отличаются потребности бизнеса. Например, с технической точки зрения мы используем kotlin multiplatform для мобильной разработки, соответственно, все мобильные разработчики с определенного грейда должны уметь с kotlin multiplatform работать, с софтовой точки зрения - тут отличается зона ответственности лидов, соответственно, в грейдах отличается рост ветки софт скилов.
  Развернуть 1 комментарий

Так получилось.

Я никогда не был джуном или даже мидлом.

Просто работал, менял работы (лычек в названии должности не было), потом как-то попал в Dr Web в качестве тестировщика и сразу стал тимлидом. Меня реально повысили до руководителя группы после испытательного.

А дальше как-то уже ну раз я лид, то минимум синиора мне предлагали в вакансиях.

  Развернуть 1 комментарий
Egor Suvorov Программист/преподаватель C++ 21 октября 2023

Ни малейшего понятия. Ездил на стажировки, учился в университете, потом устроился на работу как программист, потом ещё раз, и — бац — в контракте было написано Senior Software Engineer.

Кажется, что сеньор — безумно размытое понятие и отличается во всех компаниях. Впрочем, я в целом эту градацию перед глазами не видел. Максимум «человек основал проект и вращается где-то наверху», «человек долго в проекте работает и всё знает» и «человек в проекте недавно, знает и умеет мало».

  Развернуть 1 комментарий
Anton Lebedevich Data Engineer | Machine Learning Engineer | AB-testing 22 октября 2023

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

  Развернуть 1 комментарий

У Тарасова есть такие понятия как "горизонтальная карьера" и "вертикальная карьера". Горизонтальная - это про мастерство, вертикальная - это про должность.
Так вот все эти джун/мидл/сеньор — ступени вертикальной карьеры, которые нужно "брать просто, как яблоко с ветки", и "если не получается, значит мастерство ещё недостаточно, надо ещё учиться, ещё шагать по ступеням мастерства".

Соответсвенно, если вы чувствуете, что готовы к сеньорской лычке, то просто приходите к руководителю и говорите "дай мне сеньора". Если не дают, надо узнать причину. Могут например тупо зажопиться (тогда очевидно нужно уходить), а могут и аргументированно разложить, почему не готовы дать (тогда надо качаться). Так что это в любом случае выигрышная ситуация для вас.

  Развернуть 1 комментарий
Alexey Forillon Шоколад, айти, чего? 21 октября 2023

Любопытно-хочется спросить: тут много речи именно о пути к дев-сеньнорской "лычке", интересно узнать, какие качественные изменения происходят с тобой, если ты - опс? :D

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

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

  Развернуть 1 комментарий

Сеньор это hands on специалист, который если он один в своей роли, при нем все равно выпустят хороший продукт

В случае необходимости он даже может повыполнять функции других ролей

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

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

  Развернуть 1 комментарий
Evgenii Kochanov Анализирую данные 23 октября 2023

У меня, продуктового аналитика, выглядело примерно так - работал в компании, «естественным» образом рос в скиллах и зарплате.

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

  Развернуть 1 комментарий
Anna Программист 23 октября 2023

В чем секрет настоящего синьора? Секрет прост: утром таски надо откомментить, а вечером сделать. И так 300 раз.

  Развернуть 1 комментарий

@Doredel, утром и вечером - анжуманя

  Развернуть 1 комментарий

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

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

  Развернуть 1 комментарий

Понятия не имею, сеньор я или нет. Как мне определить? Всегда работал просто как инженер. Я в айти уже лет 8-10 (не коммерческого опыта, а вообще), во всём разбираюсь сам, опыт получал на опенсорсе (в одном мейнтейнер, фаундер второго), сейчас на работе веду проект и менторю (?) товарища, попутно в отсутствие более опытных людей бью шишки.

  Развернуть 1 комментарий

Синьер это лычка для резюме, поэтому стал им сразу, как только начал искать первую после-джуновскую работу

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

В реальной же работе обычно меряют более объективными и измеримыми метриками, которые в основном зависят от команды и её задач

  Развернуть 1 комментарий

😎

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

Что вообще здесь происходит?


Войти  или  Вступить в Клуб