Грейды: что на самом деле отличает junior, middle, senior и lead

Почти каждый, кто недавно начал писать код, рано или поздно задаёт один и тот же вопрос: «Сколько нужно лет / фреймворков / решённых задач на LeetCode, чтобы стать мидлом?» Вопрос неправильный, и именно поэтому на него никто не даёт нормального ответа.

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

В этой статье: из каких осей на самом деле складывается грейд, как выглядит одна и та же задача на четырёх уровнях, чем занимаются junior/middle/senior/lead в реальные рабочие дни, почему «сеньор» в стартапе и «сеньор» в банке — это разные люди, как работают грейдовые сетки и калибровки, и как честно оценить себя, не занижая и не завышая.

Роли и грейд — разные вещи; про роли было в Кто есть кто в команде. Контекст компаний — в Энтерпрайз изнутри и Стартап изнутри. Деньги, привязанные к грейду, — отдельная тема в Зарплата и своя цена; здесь про деньги будет только в той части, где они влияют на устройство сетки.

Что такое грейд формально

У слова три разных значения, и их постоянно путают.

1. Грейд как элемент системы оплаты труда. В HR-смысле грейд — это ступень в сетке должностей, к которой привязана вилка (диапазон зарплат), уровень бонуса, иногда — размер опционного пакета, лимиты согласований, право на определённые льготы. Это то, что реально записано в кадровой системе: «Инженер-программист, грейд 12».
2. Грейд как титул на визитке. «Senior Software Engineer» в подписи письма и в резюме. Может совпадать с внутренней ступенью, а может быть чистым маркетингом — особенно в аутсорсе и стартапах.
3. Грейд как оценка зрелости инженера. То, о чём говорят коллеги, когда говорят «он на самом деле крепкий мидл». Неформально, но именно это определяет, какие задачи вам достаются.

Здоровая компания старается свести все три к одному. На практике они расходятся, и первое, что стоит понять на новом месте: какая из трёх шкал здесь главная. В энтерпрайзе — почти всегда первая (сетка). В маленьком стартапе — третья (что о вас думают четыре человека, с которыми вы работаете).

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

Оси, по которым реально отличаются грейды

Если выкинуть из матриц компетенций всю корпоративную лексику, остаётся шесть осей.

Заметьте, чего в списке нет: количества языков, знания конкретного фреймворка, числа лет. Это входные ресурсы, а не результат. Человек может знать пять языков и оставаться джуном, потому что не умеет довести задачу до продакшена без няньки. И наоборот, человек с одним языком может быть сильным сеньором, потому что понимает, как система живёт в проде, где она ломается и какие решения обойдутся дорого.

Вторая полезная картинка — как меняется сама структура рабочей недели.

Ключевой момент: доля времени, потраченного на написание кода, с ростом грейда падает, а ценность растёт. Это ломает интуицию новичка («мне же платят за код»), но объясняется просто: компания платит не за произведённый код, а за снятый риск. Сеньор, который за час обсуждения отговорил команду от неверной архитектуры, сэкономил три месяца — и не написал ни строки.

Автономия и масштаб: карта

Две самые предсказательные оси — автономия (насколько за вами надо следить) и масштаб (насколько большой кусок реальности вам доверен). Почти все остальные производны от них.

Два квадранта в углах — реальные, часто встречающиеся патологии:

• Высокая автономия, малый масштаб — человек всё делает сам и никого не спрашивает, но работает только над своим уголком. Часто это «незаменимый» разработчик легаси-модуля. Автономия есть, роста нет.
• Большой масштаб, недостаточная автономия — человека повысили под давлением рынка или потому что «больше некому», и теперь он отвечает за подсистему, но каждое решение тащит на согласование. Это не его вина: так выглядит промоушен без подготовки.

Одна и та же задача на четырёх грейдах

Абстракции надоели. Возьмём конкретную задачу и посмотрим, как её проживают разные люди.

Задача: «В личном кабинете список заказов грузится по восемь секунд. Почини».

Junior. Открывает эндпоинт, видит запрос в цикле, добавляет JOIN, замеряет локально — стало 200 мс, радуется, отправляет PR. На ревью выясняется: (а) на проде другой объём данных, (б) JOIN сломал пагинацию, (в) у части пользователей заказов десятки тысяч, и новый запрос кладёт базу. Джун чинит, узнаёт три новые вещи. Это нормальный, ожидаемый исход. Задача была выдана как «почини N+1 в этом методе» — то есть уже разобранной за него.

Middle. Сразу спрашивает: «на каких данных восемь секунд, у всех или у крупных клиентов?» Смотрит трейс/APM, находит два места: N+1 и отсутствующий индекс. Чинит оба, добавляет тест на количество запросов, проверяет план запроса, проверяет пагинацию, катит за фичефлагом и смотрит метрику p95 после релиза. Задачу закрывает целиком, включая проверку в проде. Никто не напоминал ему про тест и метрику.

Senior. Сначала спрашивает зачем: сколько пользователей это задевает, сколько это стоит бизнесу, есть ли инцидент. Обнаруживает, что восемь секунд — только у 0,4% пользователей, зато у остальных 1,2 секунды, и это уже месяц медленно деградирует. То есть настоящая проблема не в этом эндпоинте, а в том, что размер таблицы заказов растёт быстрее плана и через квартал упрётся в потолок. Быстрый фикс делает за час, а параллельно пишет короткий документ: варианты (партиционирование, архивирование старых заказов, вынос в отдельное хранилище), их цена, что будет, если не делать. Приносит это на обсуждение, не решая в одиночку. Заодно ставит алерт, чтобы такое не находили через жалобы.

Lead. Смотрит на всё это как на сигнал о процессе: почему деградацию заметили только через месяц? Почему у нас нет владельца перформанса? Договаривается с продактом о том, что квартал включает работу по хранилищу, торгуется за скоуп, объясняет команде контекст, следит, чтобы сеньор не сделал всё сам (иначе никто больше не научится), и отдаёт часть задачи мидлу с явным «приходи, если через два дня не сойдётся».

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

Обратите внимание на стрелку 8: мидл превращает задачу сеньора в задачу джуна. Это и есть «декомпозиция», о которой пишут в матрицах компетенций, — не абстрактный навык, а конкретное действие: отрезать кусок такого размера, чтобы человек справился и чему-то научился.

Junior: что реально ждут и чего не ждут

Ждут: что вы доведёте выданную задачу до конца, зададите вопрос, если застряли, и не сломаете прод молча. Всё.

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

Практические критерии, по которым вас на самом деле оценивают в первые месяцы (подробнее — в Первые 90 дней):

• Скорость обучаемости, а не текущий уровень знаний. Одну и ту же ошибку дважды — плохо, три раза — тревожно. Новую ошибку каждый раз — отлично, вы двигаетесь.
• Качество вопросов. «Не работает, помогите» — плохой вопрос. «Падает вот с такой ошибкой, я проверил A, B и C, гипотеза — вот эта, где посмотреть?» — хороший. Правило «застрял на 30–60 минут — спроси» экономит команде больше, чем ваша гордость.
• Предсказуемость. Сказали «к четвергу» — либо сделали, либо в среду сказали, что не успеете. Молчаливая просрочка — самая дорогая для команды вещь, потому что рушит планирование.
• Реакция на ревью. Не спорить ради спора, но и не соглашаться молча со всем. Про культуру ревью — Разработка.

Типичные ошибки джуна:

• Сидеть день над проблемой, чтобы «не выглядеть глупо». Вы выглядите не глупо, а дорого: день вашей работы стоит компании денег, а ответ занял бы десять минут.
• Писать «умный» код, чтобы впечатлить. Впечатляет читаемый код.
• Считать, что задача закончена, когда код написан. Она закончена, когда изменение работает в проде и это видно. См. Definition of Done в Разработке.
• Копировать решение из интернета, не понимая, что оно делает. Это всплывёт на первом же инциденте.
• Оценивать себя по чужому резюме в соцсетях. Там витрина, а не рабочий день.

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

Middle: главная рабочая сила

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

Что отличает мидла от джуна на практике:

• Держит в голове весь путь фичи, а не только свой файл: миграция БД, обратная совместимость API, что скажет тестировщик, что увидит поддержка, как это откатывать.
• Сам находит недостающие требования. Читает тикет, видит дыру («а что если у пользователя нет адреса?»), идёт к аналитику или продакту до того, как написал код. См. Требования и аналитика.
• Оценивает сроки с приемлемой точностью — не потому что умеет предсказывать, а потому что научился резать задачу на куски и закладывать время на неизвестное.
• Умеет читать чужой код быстрее, чем переписывать. Это, пожалуй, главный водораздел: джун хочет переписать, мидл сначала понимает, почему так сделано.
• Спокойно живёт в легаси. Не любит его, но не парализован им.

Ловушка «вечного мидла». Самая частая карьерная остановка выглядит так: человек пять лет отлично закрывает задачи, его все любят, задачи ему дают комфортные, и он ни разу не оказывался в ситуации, где непонятно, что делать. Рост в сеньора требует именно этого опыта — работы с неопределённостью, а не с объёмом. Если вам никогда не давали задачу вида «разберись и предложи», грейд не вырастет сам по себе, сколько бы тикетов вы ни закрыли. Это надо просить, и об этом — в Как расти.

Senior: платят за снятый риск

Сеньор — это человек, которому можно отдать плохо сформулированную проблему и получить обратно решённую проблему. Не решение задачи, а решённую проблему — включая выяснение, какая проблема на самом деле.

Что конкретно делает сеньор, чего не делает мидл:

• Ставит под сомнение задачу. «Мы можем это сделать за месяц. Но, кажется, проблема пользователя решается настройкой, которая уже есть. Давайте проверим?» Самый дешёвый код — ненаписанный. Умение аргументированно сказать «не надо это делать» — один из самых недооценённых сеньорских навыков.
• Мыслит компромиссами, а не правильностью. Не «микросервисы лучше монолита», а «при нашем размере команды и таком профиле нагрузки разделение даст вот это и будет стоить вот столько». Про такие решения — Проектирование.
• Думает про эксплуатацию заранее. Как это мониторить, что будет в 3 часа ночи, как откатить, что случится при двойной нагрузке. См. Релиз и эксплуатация.
• Делает других сильнее. Ревью как обучение, а не как фильтр. Парная отладка. Документ, который прочитают десять человек, вместо ответа одному в личке.
• Считает техдолг в деньгах и рисках, а не в эстетике. См. Поддержка и техдолг.
• Переводит между техникой и бизнесом. Может объяснить продакту, почему это две недели, так, чтобы продакт согласился, а не обиделся.

Чем сеньор НЕ отличается: он не знает всё, не пишет код быстрее всех и регулярно ошибается. Разница в том, что его ошибки дешевле — потому что он раньше их замечает и заранее оставляет себе путь отступления (фичефлаг, обратимая миграция, возможность откатиться).

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

Lead: это не следующий уровень, а другая работа

Главное, что нужно понять про лида: это не «сеньор++». Это смена профессии, в которой ваш прошлый профессиональный навык остаётся полезным, но перестаёт быть основным.

Под словом «лид» скрываются как минимум три разные роли, и их важно различать:

В маленькой компании все три роли — это один человек. В крупной — три разных. Про распределение ответственности между ролями подробно в Кто есть кто в команде, а про менеджерский трек как таковой — в Карьерных треках и в материалах трека project management.

Что реально меняется в первый месяц лида:

• Ваша производительность больше не измеряется вашими коммитами. Мучительно для многих: вечером кажется, что вы ничего не сделали, хотя разгребли три конфликта и спасли релиз.
• Появляется работа, которую нельзя отложить: 1:1, планирование, чужие проблемы.
• Всё, что вы говорите, весит больше. Ваше «а может, попробуем Kafka?» команда услышит как решение, даже если вы просто размышляли вслух.
• Возникает конфликт лояльностей: вы одновременно защищаете команду от компании и представляете компанию перед командой.

Честно про минусы: значительная часть людей, ушедших в лиды ради денег или статуса, через год-полтора возвращаются в инженеры — и это нормальный, здоровый исход, а не поражение. Чарити Мейджорс описала это как «маятник инженер-менеджер»: charity.wtf/2017/05/11/the-engineer-manager-pendulum. Если в вашей компании ход обратно не предусмотрен — это плохой признак самой компании, а не ваш.

Что выше сеньора: параллельные ветки

В большинстве современных сеток над сеньором ветвление, а не одна лестница.

Важные оговорки к этой картинке:

• Сроки специально не указаны. «Три года до мидла» — миф; всё зависит от плотности опыта. Год в команде с ревью, продом и инцидентами даёт больше, чем три года правки форм в изоляции.
• Остановиться на senior — это полноценный выбор, а не потолок неудачника. Большинство сильных инженеров именно там и остаются, и рынок за это платит хорошо.
• Staff/Principal есть далеко не везде. В компании из 40 человек такой уровень просто не имеет смысла: не над чем работать в масштабе нескольких команд. Канонический разбор технического трека — Уилл Ларсон, staffeng.com и его блог lethain.com.

Почему грейды не сравнимы между компаниями

Это самая практичная часть статьи. Один и тот же человек может быть «senior» в одном месте и «middle» в другом — и обе оценки будут честными.

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

Энтерпрайз. Формальная сетка на 10–20 ступеней, привязанная к HR-политике, вилкам и правилам согласований. Плюс: прозрачно, есть письменные критерии, повышение защищено от произвола руководителя. Минус: медленно, требует бюджета и «окна» промо-цикла, и ступень часто отражает стаж и умение работать с процессом не меньше, чем инженерную силу. Подробно — в Энтерпрайз изнутри.

Аутсорс и аутстафф. Здесь грейд — ещё и ценник для клиента: ставка «senior» продаётся дороже. Отсюда системное давление в сторону инфляции титулов. Плюс: широта — много разных проектов за короткое время. Минус: часто нет опыта долгой жизни с последствиями своих решений, а это ровно то, на чём растёт сеньорность. См. Какие бывают проекты.

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

Отсюда два практических следствия.

1. Читая вакансию, смотрите не на слово в заголовке, а на список задач. «Senior» с обязанностями «поддержка форм на React по макетам» — это мидловая работа с сеньорским словом.
2. На собеседовании спрашивайте про уровень напрямую: «Какие задачи в вашей компании решает сеньор, а какие мидл? Приведите пример за последний квартал». Ответ скажет о компании больше, чем всё описание вакансии. Об этом — в Как проходить собеседования.

Обратный кейс тоже стоит знать: «сеньор из стартапа» приходит в крупную компанию и получает мидла. Это не всегда обесценивание — часто ему действительно не хватает опыта работы в масштабе (согласования, совместимость, миграции на живом трафике, процессы безопасности). А иногда это просто консерватизм грейдинга. Различить помогает один вопрос: сможете ли вы назвать три конкретные вещи, которых вы там не умели? Если да — оценка честная. Если нет — торгуйтесь, см. Переговоры об оффере.

Как устроено повышение внутри компании

Механика почти везде одинаковая, различается только степень формализации.

Из этой схемы четыре вывода, которые полезно принять заранее.

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

2. Нужны свидетельства, а не ощущения. «Я стал лучше» не аргумент. Аргумент — «вот проект X, где я сам собрал требования, предложил два варианта, выбрал, реализовал и провёл через прод; вот три инцидента, которые я разобрал; вот два человека, которых я вывел на самостоятельную работу». Ведите такой список сам, весь год, а не за неделю до ревью — детали забываются быстрее, чем кажется. Как это делать системно — в Как расти.

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

4. Бюджет — реальное ограничение. Иногда все критерии закрыты, а промо не случается, потому что фонд на квартал исчерпан. Это неприятно, но это не про вас. Правильная реакция — попросить конкретику: какие критерии закрыты, что осталось, когда следующее окно. Если внятного ответа нет два цикла подряд — вы получили ответ.

Матрицы компетенций: как их читать и не разочароваться

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

Реальные, открытые примеры:

• Dropbox Engineering Career Framework — dropbox.github.io/dbx-career-framework. Пожалуй, самый аккуратный публичный документ: разбито по осям (результаты, направление, талант, культура) и по уровням.
• Monzo Progression Framework — progression.monzo.com. Хорошо показывает, как одна ось растёт от уровня к уровню.
• Kickstarter Engineering Ladder — github.com/kickstarter/kickstarter-engineering-ladder. Компактно и по-человечески написано.
• progression.fyi — progression.fyi — агрегатор десятков публичных фреймворков разных компаний. Полезно посмотреть 3–4 подряд и увидеть, что общего (оси совпадают) и что различается (пороги и названия).

Как этим пользоваться правильно:

• Читайте соседние уровни рядом: ваш и следующий. Ценность не в описании уровня, а в дельте между ними — она и есть ваш план развития.
• Ищите глаголы. «Знает» и «понимает» — вода. «Проектирует», «декомпозирует», «эскалирует», «убеждает» — то, что реально оценивают.
• Не пытайтесь закрыть все клетки матрицы. Реальные люди неравномерны: сильны на двух осях, средние на трёх. Повышают за убедительный профиль в целом, а не за максимум по всем осям.

И честная оговорка: матрица — это описание, а не механизм. Она приводит разговор к общему языку и снижает произвол, но решение всё равно принимают люди на калибровке. Компании, которые верят, что матрица заменит суждение, обычно получают бюрократию и людей, оптимизирующих формулировки вместо работы.

Как честно оценить себя

Самая частая проблема не в том, что человек не знает критериев, а в том, что он оценивает себя не по тем сигналам. Вот рабочий алгоритм.

Пять вопросов, которые дают более честный ответ, чем любая матрица:

1. Когда вы последний раз застревали? Если давно — вы не растёте, задачи слишком лёгкие.
2. Что случится с командой, если вы завтра уйдёте на месяц? Ничего — вы взаимозаменяемы; встанет одна фича — вы мидл; встанет направление — вы уже несёте сеньорскую нагрузку (и, скорее всего, у вас проблема с bus factor, которую надо чинить).
3. Кому вы объясняли что-то за последний месяц и стал ли он от этого самостоятельнее?
4. Какое ваше решение за полгода оказалось неверным и как вы это обнаружили? Не «делал ли я ошибки» (делали все), а насколько быстро сработала ваша собственная обратная связь.
5. Можете ли вы назвать, во что ваша работа обошлась компании и что она принесла? Умение перевести свою работу в бизнес-язык — почти безошибочный маркер уровня.

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

Типичные ошибки в отношении грейдов

• Считать годы. «Мне три года, значит я мидл». Стаж — плохой предиктор: бывает три года опыта, а бывает один год, повторённый трижды.
• Гнаться за титулом, а не за задачами. Титул без соответствующего опыта — это оффер, который вы не сможете отработать, и следующее собеседование это вскроет. Хуже того, вы попадёте в квадрант «большой скоуп без опоры» и рискуете выгореть.
• Путать грейд с зарплатой. Связь есть, но не жёсткая: вилки перекрываются, рынок меняется, а компании с разной моделью платят по-разному при одинаковом титуле. Механика — в Зарплате.
• Идти в лиды, чтобы расти. Если в компании нет технического трека — это может быть вынужденным решением, но тогда честно назовите это сменой профессии.
• Обесценивать «нетехническое». Умение написать понятный документ, провести обсуждение и договориться с продактом — это не «софт-скиллы в довесок», а прямая составляющая грейда. На сеньорских уровнях именно она чаще всего оказывается узким местом.
• Сравнивать себя с публичными звёздами. Вы видите их результат, а не их контекст, условия и десять лет до этого.
• Со стороны нанимающего: грейдить по стеку. «Не знает нашего фреймворка — значит мидл». Фреймворк учится за месяц, зрелость — годами. Про типичные ошибки оценки — в Как проводить собеседования.

Мини-итог

• Грейд — про размер задачи, которую вам доверяют без надзора, а не про годы, стек или объём знаний.
• Шесть осей: масштаб, автономия, неопределённость, влияние на других, горизонт последствий, цена ошибки.
• Junior доводит выданную задачу. Middle закрывает фичу целиком и сам находит дыры. Senior работает с неопределённостью и снимает риск, в том числе отговаривая от ненужной работы. Lead — это другая профессия, а не следующая ступень.
• С ростом грейда доля написанного кода падает, а ценность растёт: платят за снятый риск.
• Грейды несравнимы между компаниями; смотрите на список задач, а не на слово в заголовке вакансии.
• Повышение почти всегда идёт по схеме «сначала делаешь работу уровня — потом оформляют»; копите свидетельства весь год, а не за неделю до ревью.
• Публичные матрицы (Dropbox, Monzo, Kickstarter, progression.fyi) — лучший бесплатный инструмент самооценки; читайте дельту между своим и следующим уровнем.

Источники и что почитать

• Dropbox Engineering Career Framework — dropbox.github.io/dbx-career-framework
• Monzo Progression Framework — progression.monzo.com
• Kickstarter Engineering Ladder — github.com/kickstarter/kickstarter-engineering-ladder
• progression.fyi — агрегатор публичных карьерных фреймворков — progression.fyi
• Will Larson, StaffEng — про технический трек выше сеньора — staffeng.com, блог — lethain.com
• Camille Fournier, «The Manager’s Path» (O’Reilly) — про переход инженер → лид → менеджер
• Charity Majors, «The Engineer/Manager Pendulum» — charity.wtf
• Patrick Kua, «The Definition of a Tech Lead» — patkua.com
• Хабр Карьера, раздел зарплат и грейдов — career.habr.com/salaries — полезно смотреть распределение по грейдам, а не среднее число
• levels.fyi — levels.fyi — как выглядят формальные ступени в международных компаниях и что к ним привязано

Что дальше

Мы разобрали, чем уровни отличаются. Следующий вопрос — как двигаться между ними осознанно: как построить план развития, как получать и давать обратную связь, как устроен performance review и зачем нужен ментор.

Как расти: план развития, обратная связь, performance review, менторство