Junior, middle, senior и lead: чем отличаются грейды разработчика и как расти

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

Ниже — чем отличаются уровни, как оценить себя и что делать, чтобы перейти на следующую ступень.

Грейд, должность и стаж — три разные вещи

• Грейд — уровень по внутренней матрице компании (junior, middle, senior, иногда с подуровнями вроде middle+).
• Должность — роль в штатном расписании: «разработчик», «ведущий разработчик», «тимлид». Одна должность может покрывать несколько грейдов.
• Стаж — сколько лет человек работает. Это самый слабый признак: три года однотипных задач дают меньше, чем год на проекте с ревью и сложной поддержкой.

Единого стандарта грейдов нет. Каждая компания сама пишет матрицу компетенций, поэтому «senior» в стартапе из пяти человек и «senior» в крупной компании с десятками команд — разные ожидания. При переходе уровень может сохраниться, вырасти или понизиться, и это нормально.

Сравнение грейдов в одной таблице

Описание ниже — типичная картина, а не норматив.

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

Junior: кто это и что от него ждут

Junior (младший разработчик) знает базу одного языка и основные инструменты команды: систему контроля версий, трекер задач, запуск тестов. Он решает четко поставленные задачи и регулярно просит помощи — это часть роли, а не недостаток.

Типичные ожидания от джуна:

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

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

Middle: самостоятельный разработчик

Middle получает задачу на уровне цели («пользователи должны получать уведомления о статусе заказа») и сам разбивает ее на шаги, выбирает решение, пишет тесты и доводит до выкладки. Он оценивает сроки и в большинстве случаев в них укладывается.

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

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

• понимает, как устроен используемый фреймворк или библиотека изнутри, а не только его API;
• разбирается в смежных частях системы: база данных, очереди, деплой;
• думает о поддержке: логирование, обработка ошибок, читаемость для следующего человека.

Senior: ответственность за систему

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

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

Lead и что бывает после senior

После senior карьера обычно разветвляется, и названия ролей в разных компаниях не совпадают.

В небольших компаниях team lead и tech lead часто совмещены в одном человеке. Уход в управление — не обязательный следующий шаг: во многих компаниях есть экспертный трек, где растут без подчиненных.

Как оценить свой уровень: четыре оси

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

# Самооценка по четырем осям грейда: 0 - junior, 1 - middle, 2 - senior
AXES = {
    "самостоятельность": "нужны подробные шаги / нужна цель и контекст / сам формулирует задачу",
    "масштаб задач": "функция или баг / фича целиком / система или несколько команд",
    "качество и риски": "код проходит ревью с правками / сам пишет тесты и ревьюит / отвечает за надежность",
    "влияние на команду": "учится у других / помогает джунам / задает стандарты и растит людей",
}
LEVELS = ("junior", "middle", "senior")


def assess(scores: dict[str, int]) -> str:
    missing = AXES.keys() - scores.keys()
    if missing:
        raise ValueError(f"нет оценки по осям: {sorted(missing)}")
    for axis, value in scores.items():
        if value not in (0, 1, 2):
            raise ValueError(f"{axis}: ожидается 0, 1 или 2, получено {value!r}")
    weakest = min(scores.values())  # грейд держится на самой слабой оси
    gaps = [axis for axis, value in scores.items() if value == weakest]
    return f"уровень по слабой оси: {LEVELS[weakest]}; расти в первую очередь: {', '.join(gaps)}"


me = {"самостоятельность": 1, "масштаб задач": 1, "качество и риски": 0, "влияние на команду": 1}
print(assess(me))

Скрипт выведет:

уровень по слабой оси: junior; расти в первую очередь: качество и риски

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

Проверка ввода встроена: если по ошибке поставить оценку 3, функция не выдаст случайный результат, а остановится с ValueError: масштаб задач: ожидается 0, 1 или 2, получено 3.

Дорожная карта: от junior к middle

Сроки зависят от проекта и обратной связи, поэтому ниже шаги с артефактами, а не с годами.

1. Закрыть базу инструментов. Git без страха (ветки, rebase, разрешение конфликтов), отладчик, запуск тестов. Артефакт: несколько своих pull request, принятых без переделки.
2. Писать тесты к своему коду. Артефакт: фича, к которой ты сам добавил тесты, и они ловят регрессию.
3. Взять задачу по цели, а не по шагам. Попросить у лида задачу с формулировкой «что нужно получить» и самому расписать план. Артефакт: план, согласованный до начала работы, и выкладка без срыва срока.
4. Разобраться в соседнем слое. Если пишешь бэкенд — база данных и индексы, если фронтенд — сеть и производительность. Артефакт: исправленный медленный запрос или страница с измерением до и после.
5. Начать ревьюить. Артефакт: комментарии в чужих pull request, которые автор принял.
6. Обсудить матрицу с руководителем. Попросить конкретные критерии следующего грейда и договориться о проверке через несколько месяцев.

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

Если рост не получается: симптомы и что делать

Выводы

• Грейд описывает самостоятельность и масштаб ответственности, а не стаж и число изученных языков.
• Junior работает по постановке, middle — по цели, senior — по проблеме; lead отвечает еще и за работу команды.
• Единого стандарта нет: грейды в разных компаниях не совпадают, сравнивать нужно требования, а не названия.
• Ревью проходят все уровни; разница в том, сколько проблем человек находит сам.
• Для роста полезно найти самую слабую ось и закрывать ее конкретными артефактами.

Где применяется / связь с практикой

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

FAQ

Можно ли сразу устроиться middle без опыта junior?
Формально грейд определяет работодатель по собеседованию, поэтому иногда так бывает, например при переходе из смежной профессии с сильным инженерным опытом. Для человека без коммерческой разработки это редкость: на собеседовании проверяют самостоятельную работу над реальными задачами.

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

Обязательно ли становиться тимлидом, чтобы расти дальше senior?
Нет. Во многих компаниях есть экспертный трек (staff, principal engineer, архитектор), где растут без управления людьми.