Два инженера, у обоих пять лет в DevOps и одинаковый стек в резюме: Kubernetes, Terraform, GitLab и вот это вот всё. Весной оба ходили по собеседованиям, но первый собрал офферы уровня “мидл, 200”, второй ушёл с “сеньор, 300” (алгоритмические секции первый, к слову, проходил лучше). Разница больше миллиона в год при неотличимых резюме. Ниже рамка, которая по моему мнению объясняет за что доплачивают, и три вопроса, чтобы найти в ней себя.
За что доплачивают 160 тысяч в месяц
По калькулятору Хабр Карьеры медиана мидл-девопса сейчас (10 августа 2026) 197к рублей, сеньора - 298к рублей. Рынок который год платит сеньорам ощутимо больше, хотя списки требований в вакансиях обоих грейдов - я ради интереса прошёлся по двум десяткам - почти под копирку.
Такие деньги не платят за “знает больше тулзов”. На собеседовании разница между этими двумя инженерами вскрывается не на вопросе “как настроить ingress”, оба настроят. Она вскрывается на трёх других вопросах: почему выбрали именно это решение? что будет, если оно упадёт в пятницу вечером? сколько это стоит компании? Первый инженер уверенно отвечает на вопросы типа “как”. Второй ответит на все три.
Выглядит это примерно так.
Почему Kafka, а не managed-очередь у облака?
Ну… она уже стояла, когда я пришёл.
Честный ответ мидла, ничего постыдного. Сеньорский вариант звучал бы примерно:
Считали. Managed выходила дешевле по эксплуатации, но нам нужен replay за неделю, и по хранению это ломало весь бюджет. Так и остались на Kafka… расчёт где-то в ADR лежит, могу поднять.
Причём второй ответ мог привести ровно к тому же выбору - платят не за выбор, за расчёт. Рынок покупает право не проверять за человеком решения и цену ошибки, которую ему можно доверить.
Рамка, по которой нас меряют, стоит на трёх гнилых ногах
Откройте любую вакансию: “Senior DevOps-инженер: от 5 лет опыта, экспертное знание Kubernetes, самостоятельность, ответственность” (цитата собирательная, но вы её узнали). Это и есть традиционная рамка: годы, глубина стека, самостоятельность.
Годы опыта. Резюме не отличает “пять лет разных задач от одного года, повторённого пять раз” - шутка старая, но фильтруют по годам до сих пор всерьёз. Я работал с инженером, у которого было много лет стажа и ни одного самостоятельно выбранного инструмента - всегда исполнял чужие решения, причём исполнял хорошо. А парень со вторым годом опыта в одиночку прожил пять проектов заказчика с нуля: сам выбирал, сам обосновывал, сам потом разгребал. По резюме первый старше. По типу решений - младше на голову!
Самостоятельность. Определение замкнуто само на себя: самостоятельный это тот, кто работает без присмотра. А если он без присмотра уверенно делает не то? Хуже: в зрелой команде самостоятельность выглядит как правильные вопросы в правильный момент - то есть внешне неотличима от “постоянно спрашивает”. Спросите трёх тимлидов, что такое самостоятельность, и получите три несовместимых ответа.
Глубина стека. Обнуляется при смене стека. Компания переехала с Jenkins на GitLab CI - и “глубокое знание Jenkins” осталось в прошлой жизни вместе с частью зарплатных ожиданий. Знание внутренностей инструмента это прокси-метрика: собеседующие любят её, потому что она проверяется парой вопросов. Тип ответственности одним вопросом не проверяется, только историей решений, поэтому про него почти и не спрашивают.
Грейд - это тип ответственности
Рамка, которой стал пользоваться я (и которую рынок, судя по вилкам, применяет не формулируя): грейд определяется типом решений, за которые ты отвечаешь, и ценой твоей ошибки. Стаж и стек - обёртка.
Формулы такие:
Мидл - “делаю надёжно”. Задачи класса “один сервис, известный контекст”: исполнить выбранное решение так, чтобы оно не разваливалось. Артефакты: работающий пайплайн, конфиг, стенд.
Сеньор - “проектирую и обосновываю”. Задачи класса “несколько систем, неполная информация”: выбрать решение и защитить выбор. Артефакты: ADR (architecture decision record), дизайн-док, расчёт стоимости.
Руководитель - “управляю рисками и экономикой”. Задачи класса “организация”: решить, что мы вообще делаем, что это стоит и какие риски несём. Артефакты: бизнес-кейс, SLO как контракты, план и цена миграции.
Различия удобно раскладывать по трём осям:
Ось |
Мидл |
Сеньор |
Руководитель |
|---|---|---|---|
Scope - на что влияет твоё решение |
Задача, один сервис |
Система, несколько команд |
Портфель систем, организация |
Risk ownership - чей риск ты несёшь |
Свой таск: ошибку поймает ревью |
Прод целиком: ошибку увидят все |
Бизнес: ошибку заметит клиент или регулятор |
Economics - считаешь ли ты деньги |
Не обязан |
Обосновываешь стоимость решения |
Управляешь бюджетом и ценой простоя |
Один тикет, три головы
Тикет в бэклоге: “Переехать на новый container registry”. Повод обычный - уходим с Docker Hub из-за лимитов и рисков вендора.
Мидл читает тикет как план работ. Зеркалирует образы, перенастраивает аутентификацию в CI, обновляет values во всех чартах, гоняет тестовые сборки, пишет план отката, проводит миграцию в ночное окно и ничего не роняет. Это “делаю надёжно” - работа, на которой держится вообще всё. Плохой мидл на этом же тикете положит деплой на сутки.
Сеньор читает тикет как вопрос. Зачем едем - лимиты можно закрыть прокси-кэшем за день? Если едем: managed registry облака, self-hosted Harbor или кэш поверх старого - что из этого мы потянем эксплуатировать? Кто будет чистить старые теги, когда хранилище доползёт до 4 ТБ? Что случится с деплоями, когда registry ляжет - а он ляжет! На выходе - ADR со сравнением, ценой каждого варианта и планом отката. Иногда на выходе “не переезжаем, ставим кэш” - и это тоже результат, сэкономивший три недели работы.
Руководитель читает тикет как строку в бюджете рисков. Registry - единая точка отказа всех деплоев компании. Что дороже: миграция сейчас, силами двух инженеров на три недели, или риск, что вендор закроет доступ в самый неудобный момент? Едем до пикового сезона или после? Какой SLA нужен новому хранилищу и сколько мы готовы за него платить? Решение может звучать как “едем в сентябре, после очередного релиза - и вот почему не сейчас…”.
Одна тема. Три разные работы. Эта разница и продаётся как грейд - а списком технологий в резюме её не предъявишь. Те двое (из заголовка) отличались ровно этим. (Джун в рамке тоже существует: он исполняет шаги мидлового плана под чужим ревью. Ось та же, что у мидла, просто короче.)
Почему в одной компании ты сеньор, а в другой - мидл
Грейд ходит за масштабом рисков компании, человек тут вторичен. В стартапе на сотню клиентов цена твоей худшей ошибки - день простоя и десяток недовольных писем. В финтехе с миллионом транзакций в сутки тот же самый промах - регуляторный штраф и заголовки в СМИ. “Сеньор” стартапа и “сеньор” банка - разные профессии с одинаковым названием: им доверяют разную цену ошибки.
Отсюда два неприятных следствия.
Первое: титул не переносится. Переходя в компанию с бОльшим масштабом рисков, ты опускаешься на ступень - не потому что стал хуже, а потому что местную цену ошибки тебе ещё не доверяют. На Хабре в прошлом году описывали обратный ход - опытные разработчики сами просят грейд ниже: кто-то банально ради второй работы, но чаще - чтобы снизить ожидания и цену ошибки, которую на них повесят. В рамке ответственности этот парадокс исчезает: люди торгуются не за название, а за риск, который готовы нести.
Второе: спорить “я же сеньор, у меня в трудовой написано” бессмысленно. Покупают не строчку в трудовой, а способность нести местный риск. Может и обидно, но так устроена система - и кто это принял, тратит на собеседованиях меньше нервов.
Обратная сторона того же правила: в маленькой компании легко “стать сеньором” за год, потому что ты несёшь весь прод. Скоуп при этом - три сервера и пятнадцать контейнеров. Приходишь в компанию, где один только мониторинг больше твоего бывшего прода в несколько раз и выясняется, что сеньорского в тебе была строчка в оффере.
Знакомый инженер проходил это на себе: ушёл из аутсорс компании в крупный финтех, и его бывший “весь прод” оказался там долей нагрузки одного кластера из десятка. Полгода “мидловых” тикетов и нытья в личке, что каждый его MR ревьюят по три дня. Через полтора года - сеньор уже по местной шкале. Я называл бы это перекалибровкой.
Три вопроса, чтобы найти себя на карте
Самооценка грейда врёт в обе стороны - у сильных в минус, у остальных в плюс. Поэтому дальше только факты за последнее время.
1. Вопрос про деньги (ось Economics). Какое моё решение последним стоило или сэкономило (или заработало) компании заметную сумму - и знаю ли я хотя бы её порядок? Решения есть, сумм не знаешь - работаешь мидлом, что бы ни было написано в оффере. Считал деньги до принятия решения - сеньор. Есть своя строка в бюджете - руководитель.
2. Вопрос про чужие ошибки (ось Risk ownership). Когда я в последний раз останавливал чужое техническое решение, письменно объяснив почему? Мидл отвечает за свои ошибки. Сеньор - за ошибки системы, включая чужие: увидел, что коллега тащит в прод бомбу - остановил и обосновал. Если всё, что ты когда-либо останавливал это собственный код, ось риска у тебя пока мидловая. Как у большинства, к слову: у меня самого она сдвинулась году эдак на пятом, и то после предотвращенного инцидента.
3. Вопрос про формулировки (ось Scope). Задачи приходят ко мне как “сделай X” или как “разберись с Y”? Кто превращает жалобу “у нас медленно деплоится” в конкретные тикеты - я или кто-то до меня? Превращение боли в план - сеньорская работа. Исполнение плана - мидловая, даже если план сложный.
Профиль почти наверняка выйдет неровным: сеньор по Scope, мидл по Economics - обычное дело. Зато сразу видно, какую ось качать.
Качаются оси скучно. Economics - узнай, во что обходится час простоя твоего главного сервиса; одна цифра, а разговор с бизнесом будет уже другой. Risk ownership - напиши ADR задним числом на решение, которое живёт в вашем проде без обоснования, и отдай старшему коллеге на растерзание. Scope - возьми следующую жалобу (“пайплайн постоянно падает”, “стейдж вечно разломан”) и сам преврати её в план из тикетов, раньше, чем это сделает твой лид.
Границы рамки
Оговорка, без которой рамка превратится в ещё один культ. Во-первых, это модель, чтобы планировать свой рост, а не оружие для спора с работодателем. Грейд в отдельно взятой компании определяет компания - у неё на это есть причины (см. выше про масштаб рисков). Приносить эту табличку на перформанс-ревью как ультиматум - очень плохая идея.
Во-вторых, “выше” не значит “обязан”. Осознанно работать мидлом, который делает надёжнее всех в округе - нормальная карьера. Рамка нужна, чтобы выбор уровня был выбором, а не дефолтом, случившимся сам собой.
И честная дыра в модели, чтобы вы не думали, будто она объясняет всё: куда класть стафф-инженеров без команды, я до сих пор не знаю - у меня они висят где-то между сеньором и руководителем и слегка ломают табличку.
Расскажите в комментариях про самое дикое несовпадение грейда и человека, которое видели: сеньор, “нанятый” исполнять чужие тикеты (в моей практике это случилось недавно), или джун, в одиночку тащивший прод банка. Особенно интересно, чем кончилось.
Комментарии (56)
aloginovpro
10.08.2026 07:20Часть, которая касается денег - это ожидается только от девопсов, или у других смежных специальностей (иб, разработчики, аналитики) тоже спрашивают?
vitaly_il1
10.08.2026 07:20(Я сам DevOps, к тому же очень стар)
ИМХО требуется от всех начиная с какого-то уровня "сеньорности". Потому что в технике в принципе можно все что позволяют законы природы. Но многие решения не выдерживают проверки экономики. И понятно, что разработчик не обязан иметь MBA, но понять что покупать сервер за $1000 в месяц для бесплатного или $10 пользователя неправильно.
Markscheider
10.08.2026 07:20можно все что позволяют законы природы
Да вы, батенька, опасный анархист! :):):)
gmplays Автор
10.08.2026 07:20Сосед по ветке прав - спрашивают у всех, и чем выше грейд, тем настойчивее. Девопс-специфики в оси нет, у нас она просто виднее всего (счёт от облака приходит каждый месяц, час простоя тоже считается в деньгах). У разработчиков тот же вопрос звучит как "почему переписали X на Y и что это дало", у ИБ вся профессия построена на цене ущерба, аналитики считают деньги чужих решений по должности. Рамка про любую роль, где у ошибки есть цена. То есть про все роли :)
Aitd
10.08.2026 07:20Могу написать что мы как то взяли на работу джуниора который должен был быть под крылом сеньора для роста.
В рамках обычных работ у него в основе деятельности были не только мысли о том "как делать", но еще и решать "что" и "зачем" и буквально через год его уже звали на созвоны с заказчиками, а сеньор взял его в свои заместители, причем иногда как раз "как" страдало, но это решалось общими обсуждениями.В общем в течение буквально 2-х лет работы проявилась звездная болезнь - все кроме сеньора стали по умолчанию "не понимающими", а реализация мидла который пахал как лошадь стала высмеиваться.
В общем по итогу пришлось уволить так как реальная выработка страдала, а решения хоть и принимались никогда не были жестко обоснованыЕсли исходить из таблички в статье - человек частично выполнял роль сеньора, но то была внешняя оболочка которая на длительной дистанции рассыпалась стоило сеньору оставить его одного - он стал делать всё сам и все работы подгонять так, что все другие стали не понимать что и зачем он делает и лишь сеньор мог разобраться и сместить это в адекватную сторону.
Вот такая короткая история, где вроде как синдром самозванца оказался правдой.
Вывод по статье это самооценка, а вот оценивать других можно только по реальным эффектам от работы, который я бы обозначил как "стабильность принятых решений" и "сколько ресурсов человек привлекает" чтобы эти решения придумать (то есть он мог сам придумать архитектуру и отдать мидлу, но в процессе они строятся на домыслах и рушат работы всех смежных людей, не позволяя им корректно вписаться, либо его решение потом становится бомбой с полным рефаткорингом экономически необоснованным)gmplays Автор
10.08.2026 07:20Спасибо за историю! Это ровно то, что я просил в финале, причём с "чем кончилось", которое обычно остаётся за кадром. По рамке твой герой взял половину сеньорской формулы "проектирую" есть, "обосновываю" нет. А обоснование это нифига не бюрократия, это то, что даёт смежникам встроиться в том числе, а решению жить, когда автора нет рядом. Кмк ровно это и рассыпалось, стоило сеньору выйти из комнаты. С разделением согласен: табличка это самооценка, чужой грейд меряется только реальными эффектами! "Стабильность принятых решений" как метрика мне нравится, беру! Но собеседованием её не снять к сожалению, только дистанцией. И редкий же случай - синдром самозванца дал верные показания.
Aitd
10.08.2026 07:20Мы вообще взяли этого человека как раз после собеседования и спец. тестовых которые были составлены для поиска и раскрытия талантов не только в плане кода, а в плане вот такой деятельности - чтобы человек явно думал, пытался именно решать.
Всё выглядело радужно, пока не оказалось что за внешней деятельностью нет реального выхлопа (очень похоже на деятельность "эффективных менеджеров")
Кстати ирония в том, что у тим-лида\сеньора как раз таки начинают преобладать навыки менеджмента и именно этот навык стал тем что закрыло его путь к эффективности
ShIV03
10.08.2026 07:20>пришлось уволить
"надеюсь" обоих (шутка - одного-то пришлось оставить. Не взирая, на рассказанную историю)Aitd
10.08.2026 07:20Я понимаю что без большого контекста и примеров звучит утрированно, но увольнение было необходимо в силу новой экономической реальности, и в рамках мозгового штурма оказалось что обычный джун на проекте приносит чуть больше чем такой прокачанный человек.
Т.е. со стороны может казаться что история однобокая, но это не умаляет того факта что по сути человек скакнул с джуна в сеньора сразу и смог в целом проработать так больше года.Проблема была в том что человек именно зазвездился, смешно ли сказать но когда эффективная выработка примерно равна полутора неделям работы в месяце - это уже не шутки
ShIV03
10.08.2026 07:20Спасибо! (понял, вроде)
1. Но, я-то, писал (по крайней мере, старался) про другое:
- (у меня - ощущение, что) Вы - много слов "опустили" (опираясь на контекст). И (местами) - стало (некоторым) непонятно "кто на ком стоял". Так, я - тупил "кого уволили?";
- и (я), вспомнив фразы "под крылом сеньора", "сеньор - взял его в свои заместители", обратил внимание, что у Вас, "осталась нераскрытой" роль Сеньора (испанский вариант - по нашему "помещик"; Фигаро и граф Альмавива) в этом "винигрете";
- и (с печалью) написал: "надеюсь" обоих.
Ваш ответ (вижу как): "мы - поступили практично" ("пнули" Фигаро, за ... "проделки графа").
Хотя - могу и ошибаться: меня смущает, что я не могу еще и однозначно понять вложенный смысл в "зазвездился" - "возгордился (остальные - ему не указ)", "стал лезть, куда не спрашивали", "решил, что теперь - будет заниматься только Большими делами".2. >когда эффективная выработка - примерно, равна полутора неделям работы в месяце
"А вдруг!" ("Покровские ворота"), вы - не распознали! Пророка (который "в своем отечестве") (или "распознали", но он вам - "просто надоел"):
- он - разработал новую Концепцию (причем, по контексту - согласованную с Сеньором), которая (где-то там, в далеком будущем) - принесла бы команде Большие дивиденды;
- и свои работы - дополнительно обкладывал (с ведома Сеньора) "накладными затратами" (необходимыми, на начальном этапе), подстраивая под нее;
- другие (джуны, и "ждуны") - этим не заморачивались;
- при такой трактовке, решение вашего Руководства - неоднозначно ("Ветер - переменится", "Попал - под раздачу");
- но вопрос (почему молчал, не фиксировал "промежуточные результаты") - по прежнему, к Сеньору!(хотя, за год - не выйти на видимый результат ... - по чьей вине? -- Нестыковка с гипотезой)
Aitd
10.08.2026 07:20Да, я писал немного отстраненно чтобы не вдаваться в детали и специфику - получилось как получилось :) ( я могу графоманить поэтому стараюсь себя сдерживать)
Если прям совсем четко - конечно я писал только об одном человеке, остальное совсем пропущено так как (на мой взгляд) не несет большого практического смысла.
В данном случае наш Джун чем-то занимался примерно полгода (сложно сказать чем).
Пример - когда его (как заместителя) оставляли на дежурстве - оказывалось что он не только не помогал, но и говорил что занят важными вещами который обсудил ранее и героически их делает - это ломало надежду на него как раз в плане ответственности и его экспертизе.
Вы верно уловили мысль, но суть истории не в том что он просто начал смотреть на всех с высока, а в том что человек на этой позиции находится в связке с другими, а он эту связку сознательно игнорировал, создавая внешний вид того что она улучшается (выглядит как создание видимости в бурной деятельности), причем мне кажется он сам в это верил, но полгода работ показывали что итогов у такой деятельности не было совсем.
Aitd
10.08.2026 07:20Отвечаю на п.2
У нас в целом коллектив человеческий, на обум холодно мы такое не делаем.
Фиксации были, как я говорю - результатов не было.
Все фиксировалось и делалось именно с внешней стороны - человек взял себе кредит доверия и ему дали все карты в руки чтобы он Самостоятельно делал (при этом со сверками со старшим).
Но как оказалось - его работы были просто текучкой обычных задач в которых он видел смысл разбираться, хотя на нем висели те самые большие Концепции и только общение со старшим выводило его на 1-2 дня в нужное руслов, где всё шло по новой.
Именно поэтому полгода (так долго) - кредит доверия, наличие таланта, и попытка дать человеку ту саму свободу выражения, но вышло как вышло.
Сверка со страшим была, всё выглядело иделаьно, но итогов не было.
Именно поэтому когда настала пора кого-то убрать было принято такое решение (отнюдь не холодное и быстрое).
Andrey_Solomatin
10.08.2026 07:20Все фиксировалось и делалось именно с внешней стороны - человек взял себе кредит доверия и ему дали все карты в руки чтобы он Самостоятельно делал (при этом со сверками со старшим).
У меня был такой опыт. Дали карты и все забили на меня болт (сверки со старшим формально были). Получилось плохо, но вышло хорошо, так как проект закрыли по другой причине и меня не спалили.
Jijiki
10.08.2026 07:20ну возьмём в пример анриал, который сначала имел какие-то идеи в основе, что там привлекалось что не привлекалось, по итогу это всё рефакторить будут по мере выхода стандартов С++, а и еще поиск идей и выработка нового.... получается горизонт в технологиях имеет какую-то класификацию по таймингам, что если прыгаешь в последний вагон, и станция через минуту, то надо выходить и перегрупировываться как не крути получается...
Aitd
10.08.2026 07:20Хороший пример, но выражу его как свое мнение без претензии на на то что так должно быть.
На каждой роли у людей может быть свой критерий того что является тем самым ожидаемым итогом работы.
Так вот, если мы говорим про анрил - этот продукт является платформой, и решения которые были там приняты не содержат цели писать так, чтобы не надо было переписывать (хотя на длинном горизонте это важная вещь). Поэтому (на мой взгляд) при хорошей работе всех людей в команде будет продукт который будет работать и решать задачи, иметь такой запас прочности и эффективности, что внешние потрясения любого рода не приведут к панике, а только к необходимости пересмотреть свой взгляд и планомерно рефакторить.
Т.е. мой тезис в том что рефакторинг зависит от контекста)
Бывает тот рефакторинг без которого можно получить кирпич и провал продукта, а бывает тот что обоснован тем самым поиском идей и выработкой нового (но не как критика или отвращение к тому что уже сделано)
Поэтому, да тайминги наверное есть, как без них - всё развивается, но вот чтобы увидеть тайминг нужно обладать долей экспертности чтобы начать перегруппировываться.
Melonom
10.08.2026 07:20Лично для себя недавно понял что стало вообще пофигу на лычки. Мидл, сеньёр, лид, пофигу. Главное чтобы по ЗП устраивало и задачи.
gmplays Автор
10.08.2026 07:20"Зэпка и задачи" это и есть грейд кмк, только без ярлыка: какие решения тебе доверяют и сколько за это платят. Лычка всего лишь производная от этой пары, и пока пара устраивает, производная не важна. Следить за ней стоит ровно в одном случае: когда лычку начинают продавать вместо прибавки или интересных задач, а-ля "поднимем до сеньора" вместо денег :)
Markscheider
10.08.2026 07:20чтобы по ЗП устраивало и задачи
Есть еще один вектор, правда не у всех*. У Пратчетта в "Невидимых академиках" герой-орк как мантру повторяет фразу: "Должен становиться лучше, должен быть полезным".
И вот эта полезность, как по мне, является очень важным куском мотивации. Не перекрывая, естественно, з/п :):):). Если я вечером, уходя домой, смогу сказать, что помог кому-то или сделал жизнь пользователя (внешнего или внутреннего) лучше, то это очень поддерживает.
---
* Сложно с этим сотрудникам огромных компаний / либо тех, где плохо выстроены процессы
Melonom
10.08.2026 07:20ну это я запихнул в понятие "задачи" =)
Markscheider
10.08.2026 07:20Это немного шире. Я не столько про закрытие тикетов, а больше про карму. Если вы что-то за 30 секунд пофиксили или коротким сообщением дали коллеге направление, в котором копать, он копнул и все получилось - на такое задачу в жире заводить нет смысла.
А когда в ответ прилетает: "Спасибо, помогло!" - это оч.греет.
Melonom
10.08.2026 07:20полностью согласен.
Но я имел под словом "задачи" имел в целом рабочий процесс.
JustTry13
10.08.2026 07:20Мне кажется, что это больше про рост внутри компании, а не про собеседования. Потому что на собеседованиях в ряде компаний, особенно больших, большую роль будут играть другие моменты. Например, для программистов - то, как хорошо знаешь теорию, как прошел алгоритмическую секцию или дизайн.
А в целом с идеей грейд = ответственность, а не только навыки, согласен.
gmplays Автор
10.08.2026 07:20Соглашусь с поправкой. Уверен, что в больших компаниях хорошее знание базы (теория, алгоритмы) это ворота, они решают "возьмут или нет". А вот уровень и вилку скорее решает другая часть процесса, например систем-дизайн, поведенческая, левелинг-комитет и там меряют ровно тип решений: какой scope тянул, что выбирал сам, за что отвечал. Внутри компании рамка, конечно, виднее всего, тут стопроц.
Akon32
10.08.2026 07:20Дело в том, что эти "... должен ...", подразумеваемые за каждой должностью и вакансией, во всех компаниях разные, и о них редко говорится в вакансии (и хорошо, если хотя бы в должностной инструкции). Так что ваш список обязанностей применим только для вас. Но его возьмёт HR из другой компании, загонит в промпт в дополнение к уже существующим пунктам, и будет фильтровать всех направо и налево.
gmplays Автор
10.08.2026 07:20Согласен наполовину. Наполнение "должен" в каждой компании своё и в статье про это так и написано: грейд ходит за масштабом рисков компании, поэтому и титул не переносится. Но оси общие для контор всех масштабов: на что влияет решение, чей риск несёшь, считаешь ли деньги. Между компаниями различается цена деления, а не оси
gmplays Автор
10.08.2026 07:20Опасение про HR-промпт, возможно, уместно...
Утешает только, что отфильтровать по этой рамке промптом не выйдет, все три вопроса проверяются только историей решений в живом разговоре. В промпте она выродится обратно в "от 5 лет, экспертный Kubernetes, и тд" - фильтр, который и так стоит у большинства. Кажись хуже сделать сложно :/
MrBrooks
10.08.2026 07:20Время решает. 5 лет - все ещё мидл.
То, что вы ему больше платите - это ок. Но это не повод ему грейд теперь повышать.
Проблема именно в том, что вы это сделали. И это ещё раз доказывает мелким дурочкам с 2 месяцами опыта, что они могут стать лидами уже через 1 час.
Понимаете идею?
А то, что кто-то может ответить лучше, чем другой, менеджерит себя лучше - это лишь повод порадоваться за чела и действительно предложить хорошие условия, чтобы он остался с вами
gmplays Автор
10.08.2026 07:20Платить больше за то, что решает лучше это уже пол-рамки из статьи. Осталось выяснить вторую половину: человеку начали доверять решения дороже? Если да - изменился тип ответственности, почему бы и не повысить грейд. Если нет - то согласен - это не повод повышать грейд. Можно не называть это грейдом, суть не поменяется.
MrBrooks
10.08.2026 07:20Тогда сразу, чо уж, до лида кидайте чувака, что пол года в программировании, просто шарит за ответы. Команда будет рада.
ShIV03
10.08.2026 07:20Отличная статья, нужная - ясные условия, для обеих сторон.
Вот бы ими обновить ГосПрофСтандарты. Я - "за"!
Но, (в это) "не верится":
- как никто "не знал" (профстандарты) и "не знает"/не использует/не придерживается - "изобретает колесо" (чаще, профанируя, да, еще и с нервами, если спросишь "откуда вы это взяли - этого нет в стандарте профессии?");
- так, и что (в ближайшие, лет 10) в них, это, внесут - увы!-
(пока, в комментах, никто не отметил) Меня - многократно "били" (вгоняли в рамки) за овершифтинг (как раз, за отношение, согласно концепции статьи - одним или больше грейдами выше).
Пример ясности вашей статьи:
- если в вакансии - ищут мидла, примут - мидлом, но выбрав - "самого" (или "скрытого") синьеристого;
- ему - придется "шагать (со всеми) в ногу" (и "не лезть, со своими расчетами" и, тем более, "концепциями").
Отсюда вывод: "вырасти", между грейдами - не дадут.
И следствие: на собеседовании - не получится, говорить "Считали ..."
(может так: "я - думал, в свободное время, проработал и проверил. Получил: ...".Но (по личному опыту):
- прозвучит - бледно;
- а себестоимость/затраты - большие;
- и "отдачи" - ноль (фирма, даже зная перспективную наработку - "пройдет мимо": отдаст тему другому, "изобретать (колесо) с нуля". Или бывало, что даже вредили - удаляли, конечно "случайно").
Пытаться добавлять "чтобы лучше работало/работалось" - тоже "мимо".
Текущие рекомендации кадровиков - "обязательно, оценивая полученный эффект".)
ShIV03
10.08.2026 07:20Еще нюанс: пару раз (но хоть "всего" - за десятки лет) "попадал" на внутренние недоговоренности при приеме (между директором и непосредственным начальником, либо - по уровню, либо даже - по профессии):
1) директор - считает меня Синьером, и сразу (еще на собеседовании) выдает Архиважную Задачу по Стабилизации (еще и на митинге, в первый день, представляя меня, всем рассказывает "сейчас - заживем". А начальник - считает подсобным, учеником (как только директор - в командировку, получаю задание от начальника. И на мое удивление "Директор же сказал - делать ..., вот - согласованный с тобой план", слышу "Я - тебе сказал: Иди - и пробуй/учись/покажи, разверни комплекс (за сисадмина) и протестируй (за тестировщика)", что в мои должностные обязанности - не входило, и задачи по стабилизации - не касалось совсем, и откладывало - на неделю, две);
2) директор - считает меня разработчиком (и заключаем ТД - разработчика). А "начальник" (неофициальный, "старший") - инженером (как себя). Вот - "чехарда" была в заданиях (оценке результатов, чем должны заканчиваться работы, и "рамки грейдов").
gmplays Автор
10.08.2026 07:20Спасибо!Отдельно "улыбнуло" "били за овершифтинг": к сожалению, такое тоже бывает. Замечу только, что "вырасти не дадут" это свойство конкретной компании, не рынка. Есть команды, где решение выше твоего грейда рассматриваются как угроза, и есть где это заявка на следующий. Рамка тут помогает не потолок пробить, а увидеть его раньше: если тип решений, которые тебе доверяют, годами не меняется - расти придётся переходом в другую...
gmplays Автор
10.08.2026 07:20А "считали…" совсем не про наработки в свободное время. Это про решения внутри рабочих задач, пусть маленьких, даже "поставили прокси-кэш вместо переезда" на своём участке уже история решения. Если таких не доверяют совсем это и есть главный звоночек о текущем месте работы.
Void-Cowboy
время таки решает
опыт и насмотренность - нейросети вон тоже могут и проектировать и "бюджеты решать", но как только начинается реальность на дистанцию хотя-бы в пол года как тут же вылазит разное
понятное дело что влияет и качество потраченного времени, но все равно девять женщин не родят ребенка за месяц
gmplays Автор
С девятью женщинами спорить не буду - время не сжимается, и статья сеньора за месяц не обещает. Календарь условие необходимое, но не мерило. Иначе те двое из первого абзаца (реальные люди если что), с одинаковыми пятью годами, ушли бы с одинаковыми офферами. Девять месяцев сами по себе никого не рожают, важно, что́ росло все эти месяцы; ты это сам сказал словами "качество потраченного времени".
А нейросети, по-моему, аргумент за рамку, а не против. Насмотренность у них максимальная - весь гитхаб и все постмортемы разом, но вместо сеньоров их никто не "нанимает": спроектировать могут, отвечать за решение через полгода, когда "вылазит разное" - нет. Ровно этот зазор рынок и оценивает: покупают не способность выдать дизайн, а готовность прожить его последствия
Void-Cowboy
ну так офер тоже не мерило
вон сколько историй про "зайчиков" что умеют только собеседования проходить и им противопоставляются истории от реальных спецов что не могут месяцами найти работу даже на половину от ожидаемой ставки
gmplays Автор
Соглашусь, причём легко, офер не мерило, а показания "прибора" под названием "собеседование". Прибор кривой в обе стороны: пропускает натасканных на интервью зайчиков и бракует сильных, чья история решений в формат часа/полутора не влезает. Офером в статье и комменте выше я размахиваю слишком уверенно, на отдельных людях он шумит, всерьёз расходятся только медианы по рынку.
Но зайчика ведь вскрывает ровно то, что ты сам назвал выше - полгода реальности. Натаскать можно артефакты, например рассказ о себе, дизайн на доске, нейросетки опять же в помощь... круг замкнулся. Ответственность на дистанции не натаскивается. Похоже, тут мы оба согласны в том, что мерило это что человеку реально можно доверить. Годы, стек и офер тут на самом деле три кривых прибора вокруг этой величины. Смотреть стоит на измеряемое, а не на стрелки.
maxnoosphere
Отличная статья! Особенно ценю таблицу с осями — Scope, Risk ownership, Economics. На практике именно "обосновываешь стоимость" отличает сеньора: мидл может отлично реализовать решение, но сеньор заранее просчитывает, во сколько обойдётся его падение и сколько стоит time-to-market. Это то, чему сложно научить без реальных проектов.
maxnoosphere
Про ADR — ключевой момент. Architecture Decision Record это не бюрократия, а живая история: почему выбрали именно этот вариант, какие альтернативы рассматривали, какие риски приняли. Когда через полгода кто-то спрашивает «а почему у нас Kafka, а не RabbitMQ?» — ADR отвечает на этот вопрос без привлечения авторов.