В ноябре прошлого года мы публиковали статью с мнением о том, что сокращения в Twitter — первая ласточка грядущего схлопывания рынка труда в IT. Тогда мнения аудитории разделились: одни соглашались с тем, что сектор вот-вот провалится в глобальную рецессию наравне с прочими сферами деятельности, другие замечали, что инженерам ничего не грозит.
Спустя пять месяцев можно подвести промежуточный итог: как это ни печально, но скептики (и мы в их числе) оказались правы. Рынок труда в IT-сегменте по всему миру начал если не схлопываться, то серьезно сжиматься.
Пока весь мир обсуждает, что отрицательный рост Sillcon Valley Bank не обрушит мировую банковскую систему и является локальной проблемой, IT-сегменту стоит все же напрячься. Напомним, еще в мае 2022 года Y Combinator рассылал своим участникам письма о том, что инвестиций в стартапы без 100% гарантий окупаемости, де-факто, больше не будет.
Дешевые деньги, которые бизнес-ангелы вливали в многочисленные IT-проекты, состоящие зачастую только из модного офиса, целого табуна фаундеров и one-page landing сайта, внезапно закончились. А падение банка Кремниевой Долины — лишь следствие панических настроений и общей нервозности во всей сфере. Да, бытует мнение, что банк обрушили почти случайно, но общая тенденция ясна: сейчас держатели капитала при малейшем намеке на обвал стремятся выйти в такой еще недавно отсталый кэш.
Но все вышесказанное — лишь экспозиция для того, что происходит сейчас на рынке труда. Как мы говорили раньше, даже при падении капитализации IT-компаний на протяжении последних пяти лет, привлекательность работы в отрасли постоянно росла. В первую очередь из-за мифических зарплат в 300кк/наносек и «низкого» порога входа в профессию. Но экономические законы таковы, что бесконечный рост просто невозможен. Рано или поздно наступает этап коррекции (или кризис).
Сокращения по всему миру уже оказали влияние на глобальный IT-рынок труда. Если пять лет назад найти работу джуниору было проблематично, и многие вели собственные пет-проекты на GitHub или стажировались за еду, то теперь наём новичков просто прекратился. Нет, отдельные компании могут якобы нанимать джуниоров, но на самом ли деле требования к кандидату будут соответствовать джуниорской позиции?
С просторов HeadHunter
Число же откликов на подобные джуниор- и даже мидл-вакансии уверенно перешагнуло четырехзначный барьер. До 2000 тысяч откликов на одно место новичка — новая реальность рынка труда IT, как на территории России, так и за ее пределами. Каждый сейчас может зайти на тот же hh.ru: каждую вакансию невысокого уровня прямо сейчас просматривает до полутора десятков человек, а сколько откликов отправлено — известно только эйчарам.
Предвосхищая комментарии, заметим, что мы не злорадствуем: текущая ситуация на рынке труда невыгодна всем и далека от здоровой. А там, где нет здоровой атмосферы, нет и адекватной процедуры найма.
Рецессия ударила и по опытным специалистам. В общем по рынку наблюдается снижение костов для мидл и синьор-разработчиков. Уходят бонусы, комфортные офисы, печеньки и абонементы в качалки за счет фирмы. Сейчас все больше и больше высокоуровневых вакансий в разделе компенсации выглядят весьма сухо: оплата оговоренной суммы с достаточно жестким контролем за сотрудником. Если два-три года назад мидл-разработчик мог за километр обходить откровенные галеры с трекерами экрана и жестким учетом рабочего времени, предпочитая молодую студию web-разработки с настольным теннисом и корпоративным питанием, то теперь выбор сильно сократился. Особенно, если речь идет о валютной удаленке, которой стало драматически мало.
Средняя оплата труда синьоров серьезно просела. Причин тому несколько. Первое — закончились дешевые деньги инвесторов, теперь каждая компания живет «за свои». Второе — гиганты, которые пылесосили рынок и демпинговали, потому что их карман был бездонным, не только прекратили наём, но еще и сокращают своих сотрудников, в том числе не только менеджеров, но и программистов. Предложение на рынке труда со стороны работников неуклонно растет с 2022 года, а это значит, стоимость труда будет постоянно падать.
Еще в ноябре мы писали о советах, который давал опытный разработчик, переживший падение доткомов и кризис 2008 года. Повторим их:
- Постараться отложить денег на 6-12 месяцев, если их нет.
- Отказаться от отпусков, покупок и дополнительных трат в ближайший год.
- Постарайтесь поднять ваши KPI на 20-25%, если в вашей компании планируются сокращения. Возможно, это сохранит вам работу.
- Смахнуть пыль со старых дипломов и корочек, не связанных с IT, если они есть.
- Если корочек или навыков нет — самое время их получить в свободное время, пока вас не уволили.
- Быть готовым уйти в другую сферу на 2-3 года, чтобы пережить обвал.
Исходя из нашей сферы деятельности, мы можем дать еще один, седьмой совет, конкретно для администраторов и DevOps-инженеров: посмотрите в сторону SRE.
Чем SRE отличается от DevOps в общем понимании. Просто и доступно
SRE-инженер (Site Reliability Engineer) и DevOps-инженер (Development Operations Engineer) — это две разные роли, но они имеют много общего и часто используются в схожих контекстах.
SRE-инженер — это инженер, который сосредоточен на обеспечении высокой доступности, масштабируемости и надежности приложений и систем, работающих в production-окружении. Этот подход к разработке похож на DevOps, но более ориентирован на управление рисками. В качестве инженера SRE следует гарантировать, что приложения и системы работают эффективно, безопасно и не прерываются. Для этого инженеры SRE часто используют методологии и инструменты DevOps, такие как автоматизация, контейнеризация, мониторинг и оркестрация.
DevOps-инженер — это инженер, который занимается автоматизацией процессов разработки, тестирования, доставки и развертывания программного обеспечения. Он отвечает за интеграцию процессов разработки и эксплуатации приложений, чтобы повысить скорость и качество разработки. В обязанности DevOps-инженера входит создание, настройка и поддержка инструментов для автоматического развертывания, мониторинга и управления приложениями. DevOps-инженеры работают в команде с разработчиками, системными администраторами и другими участниками команды разработки, чтобы обеспечить непрерывную интеграцию и доставку (CI/CD) приложений.
В обеих ролях есть много общего, поскольку и там, и там используются методологии Agile, инструменты автоматизации и обеспечивается высокая доступность и надежность приложений. SRE-инженеры обычно сосредоточены на управлении рисками и работе в production-окружении, тогда как DevOps-инженеры сосредоточены на автоматизации и интеграции процессов разработки.
SRE-инженер — это инженер, который сосредоточен на обеспечении высокой доступности, масштабируемости и надежности приложений и систем, работающих в production-окружении. Этот подход к разработке похож на DevOps, но более ориентирован на управление рисками. В качестве инженера SRE следует гарантировать, что приложения и системы работают эффективно, безопасно и не прерываются. Для этого инженеры SRE часто используют методологии и инструменты DevOps, такие как автоматизация, контейнеризация, мониторинг и оркестрация.
DevOps-инженер — это инженер, который занимается автоматизацией процессов разработки, тестирования, доставки и развертывания программного обеспечения. Он отвечает за интеграцию процессов разработки и эксплуатации приложений, чтобы повысить скорость и качество разработки. В обязанности DevOps-инженера входит создание, настройка и поддержка инструментов для автоматического развертывания, мониторинга и управления приложениями. DevOps-инженеры работают в команде с разработчиками, системными администраторами и другими участниками команды разработки, чтобы обеспечить непрерывную интеграцию и доставку (CI/CD) приложений.
В обеих ролях есть много общего, поскольку и там, и там используются методологии Agile, инструменты автоматизации и обеспечивается высокая доступность и надежность приложений. SRE-инженеры обычно сосредоточены на управлении рисками и работе в production-окружении, тогда как DevOps-инженеры сосредоточены на автоматизации и интеграции процессов разработки.
Скриншот с парадоксальной вакансией Junior Fullstack developer выше был вставлен в этот текст не просто так. Он — как зеркало — отражает основную сейчас тенденцию рынка, которая заключается в найме как можно более опытного и универсального сотрудника.
Наём — это дорого и сложно. Наём, когда на твою вакансию прилетает 2000 откликов превращается в попытку выбраться из болота, в которое тебя засасывает все сильнее с каждым движением. Работа HR-департаментов по всему миру сейчас практически парализована. Даже если они выбрасывают 50% резюме со словами «неудачники нам не нужны», откликов слишком много. Процесс найма затягивается и усложняется, а это недешевое удовольствие. При этом вал свободных кандидатов не упрощает задачу: HR что-то не рапортуют о том, что начали закрывать позиции за два дня — потому что бизнесу все еще нужно нанять наиболее подходящего человека, а не первого попавшегося под руку.
В том или ином виде подходы из SRE исповедуются во всех крупных компаниях. Google когда-то начала то, что сейчас активно используют практически во всех высоконагруженных системах и сервисах, начиная от AirBnB и Netflix, и заканчивая корпоративными проектами IBM. Так как SRE — довольно высокоуровневая деятельность, то джуниорских позиций в нем нет. Обычно в SRE переходят из тех самых DevOps те инженеры, кто больше внимания уделяют управлению рисками в продакт-сегменте. В условиях растущего спроса на стабильность проектов ради сокращения вероятности технического сбоя, компании все активнее и активнее смотрят в сторону именно SRE.
Для специалистов в сфере DevOps отличный способ повысить свою конкурентность — получить дополнительные знания и навыки и перейти в категорию пока немногочисленной, но востребованной категории SRE-инженеров. В целом, этот совет применим для любых работников IT-сферы: дополнительные или углубленные знания и навыки позволят выиграть конкурентную борьбу, избежать сокращения или найти новую работу в ежедневно ухудшающихся условиях за вменяемый срок, который сейчас составляет, в среднем, от 3 до 6 месяцев.
