Два инженера, у обоих пять лет в 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 - возьми следующую жалобу (“пайплайн постоянно падает”, “стейдж вечно разломан”) и сам преврати её в план из тикетов, раньше, чем это сделает твой лид.
Границы рамки
Оговорка, без которой рамка превратится в ещё один культ. Во-первых, это модель, чтобы планировать свой рост, а не оружие для спора с работодателем. Грейд в отдельно взятой компании определяет компания - у неё на это есть причины (см. выше про масштаб рисков). Приносить эту табличку на перформанс-ревью как ультиматум - очень плохая идея.
Во-вторых, “выше” не значит “обязан”. Осознанно работать мидлом, который делает надёжнее всех в округе - нормальная карьера. Рамка нужна, чтобы выбор уровня был выбором, а не дефолтом, случившимся сам собой.
И честная дыра в модели, чтобы вы не думали, будто она объясняет всё: куда класть стафф-инженеров без команды, я до сих пор не знаю - у меня они висят где-то между сеньором и руководителем и слегка ломают табличку.
Расскажите в комментариях про самое дикое несовпадение грейда и человека, которое видели: сеньор, “нанятый” исполнять чужие тикеты (в моей практике это случилось недавно), или джун, в одиночку тащивший прод банка. Особенно интересно, чем кончилось.
Комментарии (44)
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Спасибо за историю! Это ровно то, что я просил в финале, причём с "чем кончилось", которое обычно остаётся за кадром. По рамке твой герой взял половину сеньорской формулы "проектирую" есть, "обосновываю" нет. А обоснование это нифига не бюрократия, это то, что даёт смежникам встроиться в том числе, а решению жить, когда автора нет рядом. Кмк ровно это и рассыпалось, стоило сеньору выйти из комнаты. С разделением согласен: табличка это самооценка, чужой грейд меряется только реальными эффектами! "Стабильность принятых решений" как метрика мне нравится, беру! Но собеседованием её не снять к сожалению, только дистанцией. И редкий же случай - синдром самозванца дал верные показания.
ShIV03
10.08.2026 07:20>пришлось уволить
"надеюсь" обоих (шутка - одного-то пришлось оставить. Не взирая, на рассказанную историю)
Jijiki
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Платить больше за то, что решает лучше это уже пол-рамки из статьи. Осталось выяснить вторую половину: человеку начали доверять решения дороже? Если да - изменился тип ответственности, почему бы и не повысить грейд. Если нет - то согласен - это не повод повышать грейд. Можно не называть это грейдом, суть не поменяется.
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 отвечает на этот вопрос без привлечения авторов.