Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 17
исследование топ
читая про грейды все чаще встречаешь субъективное мнение людей, поэтому приятно увидеть что то приближенное к объективности
Любопытное исследование, спасибо за статью.
Вердикт: Грейд — это ваша способность управлять сложностью, а не стаж в трудовой книжке.
Осталось понять, как проверить эту способность на этапе чтения резюме. Мне всегда казалось, что это должно неплохо коррелировать со стажем.
Вердикт: Грейд — это ваша способность управлять сложностью, а не стаж в трудовой книжке.
Грейд - это ваша способность зарабатывать деньги.
Можно долго пытаться убеждать себя что в грейдах есть какой то смысл, корреляция с опытом, управлением какой-то сложностью и прочее. Но на деле грейд - это не более чем навык подстраиваться под хотелки конкретной компании, такие как: умение хорошо собеседоваться, умение дружить с руководством и иметь своих людей на правильных позициях, умение подстраиваться под внутренние требования, какими бы абсурдными они не были, для того чтобы получать больше денег.
Да хотелось бы чтобы корреляция с опытом была но нет в современных компаниях этого нет уже давно.
У многих компаний есть свои карты компетенций, где расписано на какой грейд какие технологии нужны. К сожалению, эти карты от компании к компании сильно отличаются, как и предлагаемая зп. Так или иначе нужен инструмент, который бы усреднял требования и давал представление о ситуации.
У многих компаний есть свои карты компетенций, где расписано на какой грейд какие технологии нужны. К сожалению, эти карты от компании к компании сильно отличаются, как и предлагаемая зп.
Потому что все это субъективщина.
Так или иначе нужен инструмент, который бы усреднял требования и давал представление о ситуации.
Вопрос в том кому нужен? Работодателям очевидно не нужен так как никто в этом направлении как не чесался так и не чешется особо.
Ну окей, нужен инструмент, как будем строить систему грейдов? По "стандартной лестнице: Junior, Middle, Senior" ? Ну ок, джун - тот кто еще не самостоятельный а мид тот кто уже самостоятельный а сеньор это вообще кто? Абстрактный опытный разработчик? Ну ок. А мид который еще не сеньор но уже не простой рядовой разработчик это кто? Сеньор с 5 годами опыта и с 10 годами это одни и тот же грейд или нужно делить еще на 3-5 подгрейдов? Итого получим 6-10 грейдов. Дальше выясняется что обычно с уровня условного сеньора идет специализация, когда одни хорошо разбирается в БД, другой в DevOps, третий в многопоточности, четвертый проектирует неплохо а пятый просто решала. Как эти критерии рассчитывать, делать сетку навыков под каждую возможную специализацию? А как оценивать пересечение специализаций когда человек несколько специальностей знает? А как оценить специалиста с хорошей базой и гибким мышлением, который по новой технологии доки за вечер прочитает и на коленке сделает? Ну и наконец, будут ли оцениваться навыки вызывающие споры? Ну например, у кого-то есть навыки в продвинутом ООП, DDD SOLID, чистых архитектурах и прочем а кто-то считает это бесполезным и даже вредным. Есть еще функциональное программирования. Как такое оценивать, чтобы привести всех к общему знаменателю? Кто-то гордится что он чистый код пишет а кто-то пишет эффективный. Как быть?
Рынок считает их «неявными знаниями». Если Senior пишет в резюме, что знает HTML — это как если бы пилот хвастался, что умеет открывать дверь в самолет. Это подразумевается по умолчанию, и писать об этом — только место тратить. Аналогично и с базовыми навыками – linq, ef core и тп.
Можно я немного не соглашусь? Во-первых, чем ниже грейд - тем шире спектр задач. А во-вторых, ."Знать HTML/linq/что угодно" можно совершено по разному. От сеньёра обычно никто не ждёт работы с примитивным HTML. Поэтому и не пишут. Но если нужно глубокое понимание технологии, она будет указана.
На самому деле зависит от работодателя. Кто-то говорит о том, что нужно глубокое понимание технологии, например. А кто-то ждёт, что Джун должен иметь желание копаться под капотом, но не указывает это в вакансии, видела на практике. Поэтому чаще всего можно увидеть вакансию без базовых каких-то навыков, которые подразумеваются в голове
Факт №1. Парадокс стажера: от новичков требуют невозможного
Почему так? Это визуализация «рыночного маркетинга» или «wishlist-а рекрутера». В вакансии Intern/Junior вписывают всё подряд — от SQL до Microservices — просто чтобы отсеять тех, кто боится сложных слов. Типичный стажер .NET в 2026 году должен знать Kubernetes, квантовую физику и уметь варить кофе из зерен, собранных лично Биллом Гейтсом. Зарплата при этом — печеньки и «огромный опыт».
В нашей компании (Квебек, Канада) традиционно есть бюджет на стажёров. Когда мы публикуем вакансию на стаж, там указано всё, с чем стажёр может столкнуться. Вот студент пришёл и я ему предлагаю несколько вариантов, где он может поработать. Объясняю перспективы и ценность для команды.
В итоге, (на примере прошлого года), парень за три месяца практики поработал и с юнит тестами (всё руки не доходили оптимизировать их). И с реализацией несложной бизнес-логики (следуя похожим примерам из кода) и в деплоймент (azure devops, yaml, bisep, gitops) окунулся. На второй стаж позвали его же, но уже в команду embedded программирования. Там вообще .NET нету.
но уже в команду embedded программирования. Там вообще .NET нету.
У меня ностальжи по .NET Compact Framework :)
Есть небольшая разница между тем, с чем можно столкнуться и с тем, что требуется. Одно дело, когда в проекте используется технология, которую можно изучить на практике, и совсем другое, когда стоит понимать какую-то технологию и уметь работать с ней
При большом количестве лет можно столкнуться не с сеньорством, а со старческим слабоумием... Поэтому всё же в качестве критериев можно использовать:
знания архитектуры, проектирование системы (отход от кода)
умение общаться с заказчиками используя термины из их домена
умение залезть под капот используемой технологии,
умение учить юных подаванов
Как нас учат в вузе, разработчик не должен контактировать с заказчиком, это задача аналитика, который формирует тех задание и требования к продукту. Но ситуация диктует свои условия
В вузе учат теории. То есть теоритически да, должно быть разделение в идеальном случае. Но тогда на выходе будет идеальный код в вакууме, который на практике не факт, что будет работать. Помню на одной из бывших работ, всех тимлидов вывезли за границу и показывали как работает оборудование и весь бизнес процесс от А до Я. Важно отметить, что тут от доменной области многое зависит.
Мой поинт был в том, что важен язык и понимание (особенно для международной среды). А то из-за разности культур и различного опыта можно промахнуться серьезным образом. И в целом софтскилы, умение работать команде это тоже обязательные навыки для сеньора.
разработчик не должен контактировать с заказчиком, это задача аналитика, который формирует тех задание и требования к продукту.
Зависит от сферы, наукоёмкости разработки и раздутости штата... Для "типовой автоматизации" - возможно, для разработки "видеокодека" - вряд ли.
А где "такому" учат? В моё время на этом не заостряли внимания.
Плюс. Надо такое же по другим распространённым специализациям.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Эволюция .NET-разработчика: взгляд рынка на грейды и компетенции (анализ 700+ вакансий)