Comments 78
За всеми компетентными специалистами охотятся.Указанных просто больше нужно.
За системных аналитиков идет кровавая битва: офферы перебивают, кандидатов заваливают деньгами и плюшкам.
Срез зарплат системных аналитиков:
- Junior (опыт 1–3 года): 140 000 ₽
- Middle (опыт 3–6 лет): 250 000 ₽
- Senior (опыт 6+ лет): 300 000 ₽
Указанные цифры расцениваю, как недостаточно стараетесь. Не очень-то вам аналитики нужны.
Один аналитик обеспечивает работой примерно трех разработчиков. То есть компании готовы потратить около миллиона денег на разработчиков и всего 300 на аналитика, который сформирует им всем фронт работ.
ну почему же? Если посмотреть зарплатные срезы ниже (мобильные разработчики, go-разработчики), то выйдет, что аналитикам предлагают столько же, сколько разрабам востребованных стеков. На мой взгляд, это очень даже хорошая вилка. Они же не могут получать, как тимлиды, например.
Аналитик обычно имеет более низкий рейт, чем разраб. Исключение - уровень бизнес-стратегии и "визионер" отрасли. Там да, ЗП может уйти в космос
Пока аналитик имеет более низкий рейт, чем разработчик, готовый результат будет обходиться заказчику значительно дороже.
Таково мое видение отрасли.
Пока аналитик имеет более низкий рейт, чем разработчик, готовый результат будет обходиться заказчику значительно дороже.
Я думаю, так вы аналитика не продадите :) Заказчику общую цену продает менеджер/сейл, поэтому - сорян. Внутри - ну, большой удачи обосновать аналитику свою ценность, которая выше разраба того же "ранга"
Что до остального - тут, скажем так, это интересная тема для обсуждения на ссобеседовании, только наверное надо красиво подать. Смотрите:
Аналитик работает либо так как может (т.е. на уровне своих компетенций) либо осознанно хуже (так как разработчик получает на штуку баксов больше)
Дальше два варианта:
Если аналитику дать больше денег и мы имеем вариант (1) - тогда мы просто потратим больше денег из бюджета команды впустую.
Если аналитику дать больше денег и мы имеем вариант (2) - тогда смысл держать "гардеробщицу" в команде. Человек либо работает, либо голосует ногами. Потому что если сегодян он работает спустя рукава, поэтому что ЗП ниже чем у разраба, завтра протому что ниже чем у ПМа/архитектора, послезавтра - меркурий не в той фазе.
Вообщем-то все :) С конретным аналитиком, который сейчас стоит Х денег - мы разобрались. Денег давать смысла нет, лучше работать он не станет
Теперь смотрим на рынок. Как я писал, люди которые могут разрабытывать "бизнес стратегию" стоят дорого. "Визионеры" вообще стоят бесконечно. Даже если это не аналитик уровня "бизнес стратегии", но сильный "продакт", который может продать проект - тоже стоит хорошо. Все остальное предсказуемо стоит меньше разраба, так как банально без аналитика можно жить (и таких примеров много, и даже все там хорошо), а без разраба даже 100500 не сделают даже Home page
Но я не могу вам запретить жить и дальше с вашим виденьеми отрасли :)
Хорошо сказано, спорить не буду, хотя останусь при своём мнении.
Одно замечание: разрабатывать бизнес-стратегию - это к бизнес-аналитикам, которые в скоуп нашего обсуждения не входят. Системные аналитики имеют видение развития системы и разрабатывают масштабируемые технические решения.
Системные - вообще без шансов. Любой лид/архитект знает не меньше, а часто и больше, и делать может как работу системного аналитика, так и свою
Наоборот - нет
Видимо, вам везло с архитекторами и не везло с системными аналитиками.
И в дальнейшем также будет.
Да нет, были самые разные. Но вот увидеть архитекта (который реально архитектор, а не пустое место), который не может заменить системного аналитика - так не бывает
Но это такое, тут вопрос в стоимости
Ну и надо понимать, что если пилится большая система, то через время тим лид куда лучше знает систему, так как знает и "потроха", и внешку. Аналитик просто лишен этого. А иногда даже не знает, как оно работает в реале :)
Это не попытка там принизить, но ... ожидать что человек, который писал систему, знает ее хуже того, то писал к ней доку?
Но это такое, тут вопрос в стоимости
Так я про что и говорю. Сколько платите, столько и получаете.
Так я про что и говорю. Сколько платите, столько и получаете.
Тогда смотрим логическую дилему из комментария выше :)
Все ж просто.
Рынок цену определил
Работник от того, что получит больше - качественнее работать не начнет
Для найма есть собеседование
Те кто хотят получать больше - веклам обосновать почему именно они
Тут зависит от команды, ситуации и продукта. Есть команды, в которых аналитик описывает только пользовательские сценарии и ui. Есть где аналитик расписывает все таблицы, все api, все внутренние вспомогательные сценарии (типа того как отбирать задачу в очереди задач) и весь ui. В последнем случае аналитик в целом владеет картиной по системе на достаточном для понимания и объяснения (!) другим людям уровне.
Про выполнение роли аналитика архитектором имхо есть пара нюансов:
Вот не все могут качественно. Лично переделывал требования за двоих архитекторов - у одного образовалась жуткая помойка из фич с кучей "воды", которой при масштабной переделке системы оказалось невозможно пользоваться. У другого был просто поток сознания и проблемы с орфографией и пунктуацией. В основном до аналитиков надо просто дорасти с точки зрения масштаба проекта, либо необходимости человека с глубокими познаниями в специфичной области.
Архитекторы часто могут начать трактовать требования заказчика "в свою пользу". Вот тут как раз и может пригодиться аналитик, который более нейтрален и для которого архитектор является только одним из источников требований.
. Есть где аналитик расписывает все таблицы, все api, все внутренние вспомогательные сценарии (типа того как отбирать задачу в очереди задач) и весь ui.
Я думаю, это редкий случай
Описывать API - вообще несколько странно, так как backend банально это выдаст как побочный продукт. Разве что для интеграционных проектов, когда выдаете другой команде или вообще, как конечную точку продукта
Но тут, скажу честно, большинство аналитиков на банальный вопрос "как будем передавать массив в JSON" обычно склеивает ласты либо просит пояснительную бригаду
расписывает все таблицы ... все внутренние вспомогательные сценарии
Опять же, сомнительно. Большинство аналитиков, к сожалению, банально сядет в лужу при просьбе на собеседовании написать запрос "выбери самый дорогой товар". Не, есть исключения, которые сидели прям на базах и они могут писать аналитические запросы на раз два и даже читать план запроса. Я таких видел. Но это редкость, чем правило. И такой скорее всего засыпется на вопросе "чем принципиально отличается GET от POST".
Просто по опыту scrum-танцев, на обсуждении задач часто вылезает куча вопросов, которые вроде очевидны, но в описании из нет, и заказчика тоже спросить забыли :(
Конечно, люди, которые задают эти вопросы, не обязательно владеют навыков "ревью самомго себя и скорее всего тоже налажают", но почему этими навыками часто не владеют аналитики, принося в команду сырые требования - неясно
--------------
Но я еще раз подчеркну - есть исключения и да, те кто должны стоить много денег. Но они обычно и так очевидны.
Про выполнение роли аналитика архитектором имхо есть пара нюансов
Ну я обычно пишу технические таски, либо что-то вроде фреймвока. Вот на этой неделе в новом проекте описал как и где вы ведем логи, и с какими еще задачами мы эту задачу увяжем
Может ли такую таску написать аналитик - наверное, но обычно это считается что появляется в проекте само собой
Писать бизнесовые - это просто долго. Проще показать кому-то и дальше пусть пишет по шаблону
Плюс, как я писал выше, для написаная доки, любой, важен скилл "перепроверь себя сам". Он может быть, или его может не быть у любого писателя доки
Большинство аналитиков, к сожалению, банально сядет в лужу при просьбе на собеседовании написать запрос "выбери самый дорогой товар". Не, есть исключения, которые сидели прям на базах и они могут писать аналитические запросы на раз два и даже читать план запроса.
Аналогично можно критиковать фронтендеров в неумении писать SQL. Или критиковать бэкендоров в непонимании Shadow DOM. Но так никто не делает, потому что понимают специализацию разработчиков.
А почему то системным аналитикам в специализации отказывают.
ОК - согласен. Бывают системы, когда есть условно бэк. Какой нибуть опер день, к которому прикрутили условно oCRM как фронт. Тогда системный аналитик по опер дню должен знать к примеру SQL (но очень хорошо) и, к примеру MQ (потому что event bus). Ну и логику системы.
Но многие системы часто имеют и фронт, который Web. Тогда - ну это уже не системный аналитик, а "модуль"-аналитик :)
-----------------
Ну и надо понимать следующее
Такой "системный" аналитик стоит мало на рынке, так как по сути нишевая позиция, привязанная к системе. Да - часто такие люди думают, что они незаменимы, так как они сидят на ОЧЕНЬ ВАЖНОЙ системе и без них все сломается.
Но я знаю кучу примеров (даже в личной практике были), когда спеца и даже всю команду увольняли и ничего, компания не шла ко дну. Да, это стоило денег, брали спецов от производителя системы, срочно учили - но не шли на "шантаж" или на "поводу обстоятельств".
-------------------------------------
Бывают и дорогие системы типа SAP. Есть аналитики по конкретным модулям. Но тут их стоимость скорее идет от того, что системы стоят дорого и сервис от "вендора" стоит просто космос. А подготовить спеца нелегко, надо и авторизованные курсы, и опыт, так как системы неочевидны, сложны и часто надо еще чего-то в бизнес части шарить.
Но для таких систем тоже есть свой рынок, и любая "птица гордая" может резко стать "летающим ежом", если начнет просить больше рынка. Потому что сложность и распространенность ведет к некой стандартизации
Но тут есть привязка к технологии. Если чего-то с ней пойдет не так - системный аналитик быстро понимает, что за пределами уютной экосистемы он никто и звать его никак
Такое себе, я бы такого карьерного пути себе не хотел
большинство аналитиков на банальный вопрос "как будем передавать массив в JSON" обычно склеивает ласты либо просит пояснительную бригаду
Большинство аналитиков, к сожалению, банально сядет в лужу при просьбе на собеседовании написать запрос "выбери самый дорогой товар"
И такой скорее всего засыпется на вопросе "чем принципиально отличается GET от POST"
Вы где с такими системными аналитиками работали, может это вовсе и не системные аналитики? Это совершенно базовые навыки и знания, которые проверяют на каждом собеседовании для этой позиции. Посмотрите хотя бы на те же собесы у Тинька
у нас в компании нет системного аналитика, но есть разрабы, и вы не поверите, уже не один проект подняли и ведем. Как думаете, что было бы если было наоборот ?:) Это конечно примитивный пример, но суть он доносит не плохо. Где-то они нужны, но далеко не везде как показывает практика.
Поверю. Более того, в том же Scrum нет аналитиков, есть только Developers.
Как думаете, что было бы если было наоборот ?:)
Кому-то пришлось бы стать разработчиком. Или отдать реализацию на аутсорс - тоже бизнес-модель.
У нас тоже так было когда-то. Но с ростом численности и объёмов работ аналитик, который "даёт" работу 3-5 программистам становится необходимостью.
Работал в компании где было наоборот - делали ПО для управления расчетами ГТД. Все аналитики и инженеры были у нас, разработки не было, ей занималась другая компания. Но конечно совсем без разработки не бывает, это факт)
Я думаю, так вы аналитика не продадите :)
Разрабам (особенно современным) в большинстве своём всё равно что делать. Им кинули задачку, они взяли, сделали, отправили на тестирование. Думать наперед, проектировать, зачем? У тебя горящий спринт!... Аджайл культура, насаждаемая, приводит к деградации разработчиков.
Поэтому отсутствие хорошего аналитика приведет к тому, что подсистемы будут переписываться по нескольку раз - еще до релиза, потому что бизнес требования непроработаны толком, как и решение.
Написать код один раз, или несколько? Имхо, уже в группе с 3 разрабами системный аналитик может окупиться, а если их больше - окупится точно.
Сколько работал, приходилось делать аналитику за аналитика. А где-то и вовсе аналитика не было (за неимением, либо ненужностью). Кажется, найти действительно полезного аналитика намного сложнее, чем крутого программиста. Я даже таких не встречал, а крутых программистов встречал не раз. Однажды был неплохой аналитик, но все равно местами приходилось инфу вытаскивать из него, чтобы принести пользу продукту на основе той инфы (единичный случай). Остальные аналитики если и были, то просто знали область очень плохо, самому разработчику приходилось протаптывать путь к знаниям в области. То есть некоторым программистам надо платить еще и за аналитика.
приходилось делать аналитику за аналитика
Печальная правда жизни.
У меня похожий опыт. Если аналитика нет, то информация о бизнес требованиях идёт напрямую разработчикам, минуя сломанный телефон. Если аналитик есть, то его нужно поймать, вытащить инфу и надеяться, что он ничего не забыл, не перепутал и не добавил от себя.
Как шутили некоторые мои коллеги-разработчики - аналитик это недопрограммист. 😀
Ну а серьёзно, и как уже ниже сказали - естественно, любой опытный разраб, при желании, аналитика заменить сможет.
Заменить сможет, но при этом еще и свою работу работать - нет.
Не всегда. Тут разделение ролей работает - многие хорошие разрабы не готовы общаться с заказчиком, особенно неадекватным (читаем - из госов и корпов). И потому буфером работают аналитики, они же берут на себя весь стресс от обратной связи )
Плюс экономим время дорогого разраба на придумывание решения пользовательской задачи (и здесь качество решения сильно зависит от квалификации аналитика, в том числе - от знания технических возможностей системы, т.е. от понимания, что можно и чего нельзя разработать в принципе).
А еще проф.болезнь разрабов - они любую задачу пытаются решить разработкой, хотя иногда возможно применить нестандартным способом типовые инструменты и либо исключить разработку вообще, либо существенно ее упростить.
Есть еще результат работы аналитика, который разработчикам особо не виден - это то, что не пришлось разрабатывать или что сильно упростилось в результате смены подхода или изменения взгляда на проблему или решение. Выявить и показать, что проблема не стоит решения, что предлагаемое решение не убирает проблему, что тактическое решение окажется слишком дорогим с течением времени, выработать решение при конфликтующих интересах, уговорить убойтись простым решением, убирающим 80% проблем и т.д. Потому что кривое решение это еще ладно, а вот псевдо-решение, не решающая реальную (реальную!) проблему бизнеса - это даже не нейтрально, это вредно и вредно вдвойне. Даже если все массивы в JSON офигенные и JOINы как у DBA c 15-опытом. Ну, там и зп соотвествующая, и проблем с поиском нормального места работы нет - такие люди нужны, нужны на хорошие деньги. Другое дело, что есть тонны аналитиков, которые по верхам нахватались рестов, кафок и прочих джейсонов, и концентрируются на имитации того, что они во всем этом разбираются. В лучшем случае генерируя полупропеченные требования для правильных задач, в худшем - такие же для того, чего вообще делать не стоит. Для меня загадка, зачем их нанимать, хотя как секретари для програмистов и архитекторов вроде годятся.
Ключевое слово "при желании". Лично у меня не возникает желания вникнуть в тонкости бизнес процессов заказчика, не интересно от слова совсем. Тратить время и забивать голову ненужной ерундой.
Т.е., сейчас крупные отечественные коорпорации вовсе не ищут сеньоров на з/п мидла и мидлов на з/п джуна? 🤔
Порог входа в Go довольно высокий. Кстати, часть компаний готовы брать
на позицию Go‑разработчиков хороший питонистов, готовых переучиваться.
Тут получилось противоречие. Да, порог входа на позицию Go-разработчика высокий, но при этом знать Go не обязательно: переучивают с PHP, Python и даже Java (хотя, казалось бы, кто из джавистов пойдёт - но случаи есть). Достаточно показать уверенный уровень на своём текущем языке.
А почему порог на GO высокий, ведь сам язык вроде как и задумывался что бы быстро въехать и начать грести? Или вы имеете ввиду что нужна хорошая computer science база для задач, которые с помощью GO решают? Если так, то а где база не нужна?
А почему порог на GO высокий, ведь сам язык вроде как и задумывался что бы быстро въехать и начать грести?
Это вопрос философский) Возможно потому, что пока Go идёт в комплекте с highload, а в небольших проектах встречается относительно редко. Получается, это скорее наблюдаемое свойство вакансий, а не самого языка.
нужна хорошая computer science база для задач
Да, это и хотел сказать. Не смог корректно мысль сформулировать.
ведь сам язык вроде как и задумывался что бы быстро въехать и начать грести?
Но при этом создавался скорее на замену C/C++ (возможность сгенерировать нативный код без лишних накладных расходов) и по сравнению с ними порог поменьше. Но тут сравнивают скорее с Pyhon/Java/JS...
Статистика интересная, но на хх в рядовых компаниях все же почему - то зарплата меньше, чем у вас. Прямо сейчас открыл и посмотрел
Здравствуйте! Расскажу немного, как мы собирали статистику по зарплатам:
1. Искали из открытых источников - то есть брали резюме с открытой информацией по ожидаемой ЗП (проверяли, чтобы навыки соответствовали опыту и тд)
2. Из собственных данных - у нас внутренняя статистика по нашим кандидатам и их ставкам
Поэтому наша статистика может немного отличаться от других. Так как она составлена на основании зарплатных ожиданий соискателей. Кстати, у нас есть бесплатный телеграм-бот -- там собраны зарплатные ожидания по популярным стекам и позициям. https://t.me/HitchInfoBot
На хх у хорошо платящих компаний зарплата обычно вообще не указана, так что нет смысла по этому делать выводы.
Не очень соглашусь с выводами по импортозамещению и ключом роста спроса на системную аналитику по этой причине, скорее культура разработки в стране растет относительно быстро, как и популярность разработки продуктовыми командами, что провоцирует естественный рост спроса. И тут снова хочу отметить, что поиск бизнес-аналитиков ушел не далеко, но при средней медианной зарплате существенно ниже и малом количестве мидлов на рынке ситуация выглядит удручающей, где бизнес вынужден тащить на эти роли перепрофилированный средний менеджмент из текущего состава.
3 года - всё ещё джун? Серьёзно?
Джун джуну рознь. Если человеку повезло вкатиться в IT после условных полугодовых курсов, и вкатился он в какую-нибудь компанию полуэникеем, где он плюс пара человек и есть весь IT отдел, и задач у него условно сайтик допиливать, выполняя +- одни и те же задачи - то да, вполне джун. Ну а если там профильный вуз закончил и попал в крупную IT компанию, то за год спокойно можно и до мидла дойти такому человеку.
Вы же не хотите сказать, что IT это армия, и у нас мерилом являются не знания и опыт, а количество отпаханных лет?
Не хочу, конечно, но вы это скажите HR'ам
Если человек закончил профильный вуз, и реально быстро воспринимает, то до мидла можно дойти за три месяца (это с запасом), если нагрузить человека задачами. Мидл, обычно, не может даже задеплоить свой реактик или разобраться с вебхуками, если он бекендер.
Сеньор сеньору - рознь. Но часто они на уровне мидла и больше опыта. Сейчас типо надо шарить ТС, если ты сеньор, а от ТС в проекте - только расширение файла. В лучшем случае any тип. И вечные оправдания, что заказчику надо было вчера и мы тут нашкодили.
Никого не хочу обидеть - я +-мидл фуллстек, если неделю не пишу код, то деградирую в Джуна, который может заставить сеньора фронтендера плакать. Бекендеры всё-таки посильнее теоретически подкованы.
до мидла можно дойти за три месяца (это с запасом)
А через год - сеньор, еще годик и готовый техлид, бггг.
Вы тут иронизируете, а на хабре даже статья была:
6 вещей, которые мешают IT-специалисту расти и продвигаться в карьере / Хабр (habr.com)
Сын маминой подруги: сеньор за 1.5 года, техлид за 4.
если неделю не пишу код, то деградирую в Джуна
Вот поэтому и не дойти за 3 месяца. За это время знания не успеют стать опытом. Это как перед экзаменом выучить все билеты а через день уже их забыть. Должны образоваться нейронные связи, а это достигается постоянной практикой.
Помимо набивки опыта есть две вещи. Долгосрочные последствия принятых решений и банальное сравнение разных подходов к разработке и аритектур ПО. Для первого время необходимо по определению, для второго нужно работать на сильно разных проектах, может и в рамках одной компании. Но и в разных компаниях тоже неплохо поработать - внутренняя автоматизация, аутсорс и продуктовая разработка отличаются друг от друга.
Да, такое же удивление вызвало)
До 3-х лет, серьезно. Есть какие-то другие соображения?
«Нужен системный аналитик с опытом работы в металлургической сфере, знающий технологические процессы обогащения металлов» - ну вот раньше меня звали консультантом и это больше отражало действительность. Понять бизнес ценности и цели, провести изменения процессов и ИТ систем для их достижения. Только системный, который скилово пишет маппинги между микросервисами - это немного другое.
Срез зарплат Android:
Это предлагаемые организацией или то, на сколько нанимают фактически?
Это до налогов "на руки" или после ?
С обещанной премией потом или чистый оклад?
Последние четыре года поработал в четырех компаниях. И вот кого реально везде не хватало это ДевОпсов. Иногда очереди на решение твоих вопросов нужно было ждать 2-3 дня.
Согласен. И постоянно эта девопсовская рутина наваливается на тимлида
Разве девопс - это не про автоматизацию?
А что это за автоматизация такая, когда автоматизатор постоянно что-то делает, а не один раз настроил и ушел? Может такую автоматизацию надо выкинуть в помойку и не пользоваться? И ждать 2 дня не нужно и 200К экономии...
Вот так выкинули непонятную автоматизацию, уволили кого попало девопсов которые хрен знает чем занимаются, а теперь вдруг приходиться ждать по 2-3 дня ради рутинной таски. 😂
Как-то так
А разработка ПО в целом это не про автоматизацию? А что это за разработка ПО такая, когда постоянно находятся баги, появляются новые фичи, выпускаются релизы, а не один раз разработал и ушел? Может такую разработку надо выкинуть на помойку и не пользоваться?
А бухгалтерия это не про автоматизацию? А что это за бухгалтерия такая, когда постоянно требуется рассчитывать зарплату, а не один раз подсчитал и ушел?
А менеджмент это не про автоматизацию? Почему нельзя один раз все вопросики порешать и уйти?
Вы точно в it работаете с такими вопросами?
Давайте начнем бухгалтерии. В ней роль девопса выполняет программист 1С.
Если законодательство не сменилось, то для расчета ЗП бухгалтеру требуется указать количество дней, когда сотрудник был на рабочем месте (или поставить пропуски дней=0) и нажать кнопочку. Законодательство меняется у нас не каждый день, и большинство 1Сников на аутсорсе - как раз пришли, перенастроили под новые тенденции и ушли.
Теперь про программистов - полно программ, которые разработал и ушел. Рар 2.+ и современный - отличаются косметически, вполне можно было не выпускать новую версию вовсе.
Допустим, большой проект выносит часть функционала в микросервис - тут нужен девопс. Ок. подождали его 2 дня, он пришел, настроил развертывание контейнеров/виртуалок под фичу.
Через неделю - новый кусок на новый микросервис - еще 2 дня подождали...
Еще через неделю ... возникает вопрос - почему у нас нет скрипта, которому передается имя функции и начальное развертывание происходит само? Этот вопрос задают программисты, а девопс после второго раза должен был спросить - а сколько еще раз повторится эта задача?
А если таких вопросов не возникло - они точно в it работают?
Называйте девопса системным инженером - и пусть он сидит в штате, ради бога. Но автоматизирование - процедура с четким финалом - либо теперь всё (этот кусок) работает само, либо нет.
Прикольно вам жить.
Автоматизация "сразу всего" возможна только в реальности не очень умного менеджера.
Само наличие и использование инструментов автоматизации не может вам гарантировать идемпотентность
К примеру, уменя на нескольких проектах только для одного условного "базаданных-нейм-сервис" может быть разных типов в разных количествах, поставляться либо со стороны разных клауд провайдеров, в каждом из которых своя специфика реализации и среды, либо в виде наборов кубер ресурсов, которые тоже могут быть разные например в случае использования опеншифта, либо как сервисы в опенстэк инстансах, сетевая часть варьируема, механизмы контроля доступа варьируемы, механизмы деплоя варьируемы, сорадж вообще отдельная история, и все это дополнительно еще периодически может быть частично или полностью переданно сторонним вендорам, или заказчику. Вы можете обмазаться скриптами, и так скорее всего и будет, но рано или поздно обязательно появляется дополнительное условие под которое нужно что-то менять, переписывать и так далее.
Автоматизация это отсутствие повторений. А их тут и нет. В живой и развивающейся компании постоянно возникают новые задачи требующие участия девопсов. Новые конфигурации стендов, телеметрии, смена вендоров, сбои у вендоров и на собственных фермах итп.
Про аналитиков соглашусь:
На профиль в хабре со статусом "Не ищу работу", з/п 300к, лычкой senior и опытом примерно 4 года в один февральский день написали 5(!) рекрутеров разом (в среднем в феврале-марте порядка тех же 5 в неделю, преимущественно финтех и ритейл, сейчас поток подсхлынул)
В итоге пара офферов на эту сумму
В целом, кажется, что указанные суммы более-менее в рынке, сужу по своему опыту и боту getmatch. На hh не ориентировался вообще
За кем сейчас охотятся крупные работодатели в IT?