Об исследовании
Введение
В этой статье речь пойдет о про-джуниорах — разработчиках, которые уже состоялись в одной из технологий, и выбрали развитие в профессии через смену профильного стека. О том, как про-джуниоры меняют работу, с какими трудностями сталкиваются, и как их воспринимают потенциальные работодатели. Точно определить количества про-джуниоров достаточно трудно, но на основании имеющихся данных, я предполагаю, что в эту категорию попадают от 0.2 до 2% популяции разработчиков.
про числа
Если числовое значение не подкреплено ссылкой на источник, значит оно является средним арифметическим экспертных оценок, полученных от респондентов в ходе интервью
Возможно, по причине относительной малочисленности этой группы специалистов, ни специфика их опыта переобучения, ни особенности трудоустройства и найма, до сих пор не являлись предметом содержательного обсуждения или исследования. Однако, отсутствие явного интереса к про-джуниорам трудней объяснить, как только мы переходим от относительных величин к абсолютным: даже 0.2% от 24 млн — это почти половина от общего количества разработчиков в Чехии, а 2% или 480 тысяч девелоперов — это уже значительно больше количества разработчиков в России.
Полгода назад я начал работать над исследованием в рамках выпускной работы, чтобы понять из чего складывается профессиональный опыт про-джуниоров. Ниже, я бы хотел поделиться основными сюжетными линиями, которые были выделены в ходе серии интервью с про-джуниорами, рекрутерами и HR-ами.
про дизайн исследования
Исследование состоит из 2 фаз:
- Серии качественных интервью для формирования понимания проблемного поля. В ходе работы над фазой 1, мной было проведено 31 интервью с разработчиками, рекрутерами и HR-ами продуктовых и сервисных IT-компаний (преимущественно, в Воронеже и в Санкт-Петербурге).
- Количественного исследования, для сбора и анализа статистически значимых данных.
Для того, чтобы проверить, являются ли выделенные сюжеты статистически значимыми для более широкой аудитории, я запускаю опрос. Если у вас есть опыт смены стека, вы только планируете освоение новой технологии, или по какой-то причине откладываете переобучение, я приглашаю вас принять участие в исследовании.
Основные сюжеты
Резюме и общие соображения
- Суперспособность про-джуниора в глазах работодателя — личная мотивация.
- В ходе общения с потенциальным работодателем желательно выяснить пересечения в зарплатных факторах и навыках/опыте соискателя. Это может стать значимым подспорьем при обсуждении уровня компенсации.
- Опыт решения бизнес-/технических- задач, актуальных для работодателя, важнее знания модного фреймворка (если сам фреймворк не является жизненной необходимостью для работодателя).
Про-джуниоры в глазах работодателя
В ходе интервью были выделены 3 группы факторов, которые задавали ожидания работодателей относительно найма про-джуниоров.
- Базовые качества и ожидания — отсутствие или наличие этих качеств у кандидата определяло решение о найме специалиста.
- Зарплатные факторы влияли на принятие решения об уровне компенсации и определяли зарплатную “вилку” про-джуниоров. При этом, информация о Зарплатных факторах собиралась как у представителей работодателя, так и у самих про-джуниоров.
- Неустойчивые ожидания, то есть те, которые по-разному оценивались респондентами-рекрутерами и HR-ами.
Базовые качества кандидата и ожидания работодателя
- Мотивация сотрудника
В качестве основного преимущества про-джуниоров перед другими кандидатами, HR-ы устойчиво выделяли высокий уровень личной мотивации: специалист, готовый снова оказаться в ситуации с высоким уровнем неопределенности, и возможно, просесть в зарплате (об этом ниже) — оценивался HR-ами как сотрудник с высоким потенциалом развития, готовый приложить максимум усилий к работе и развитию на новом стеке. Что особенно важно, каждый из HR-ов смог подтвердить устойчивость связи “состоял(-ся/ась) в старом стеке -> переход на новый стек = высокая мотивация” конкретным примером из профессиональной практики, и испытывал затруднения в приведении контр-примеров. - Общая компетентность и универсальные навыки = высокая скорость переобучения
Предыдущий опыт позволял про-джуниорам уделять больше внимания особенностям нового стека, и в меньшей степени отвлекаться на освоение базовых вещей (например, работу с Git или написание тестов). Поэтому, основные усилия про-джуниоров уходили на то, чтобы “набивать руку” на новом стеке, и решать проблемы, специфические для осваиваемой технологии, и за счет более прицельной фокусировки, расти быстрее. И если первое прохождением пути от трейни до мидла занимало 2-4 года, то повторное движение по тому же маршруту обычно занимало полгода-год.
Зарплатные факторы
Особый интерес для меня представляли те случаи, когда разработчикам удавалось сохранить уровень зарплаты или получить бОльшую компенсацию при переходе на новый стек. Я выделил две подгруппы факторов, отмеченных респондентами, как наиболее важные при согласовании условий компенсации.
Личные способности
важное условие
Личные особенности могли иметь решающее значение только в случае, если работодатель нуждался в конкретных качествах и навыках соискателя
- Наличие опыта тех-лида у соискателя
- Техническая экспертиза
Про-джуниор обладал специфической технической экспертизой, полученной в ходе работы на предыдущем стеке, но крайне важной для работодателя (например, создание и поддержка видео-стримминг систем). - Бизнес-экспертиза
Глубокое понимание бизнес-отрасли работодателя (например, знание особенностей регулирования health-care сервисов в штате Арканзас). - Универсальность
Если соискатель мог работать сразу с несколькими технологиями, используемыми в инфраструктуре заказчика. - Продвижение бренда работодателя
Про-джуниор обладал навыками и опытом презентации на крупных конференциях, что помогало формировать HR-бренд работодателя. - “Аффект” работодателя
Пример влияния личных предпочтений работодателя, рациональность которых трудно объяснить с точки зрения возможной бизнес-ценности найма сотрудника. Например, респонденту удалось произвести впечатление необычным биографическим фактом — переезд из более популярной локации, в менее популярную. При этом, сама смена локации не была связана с поиском работы, но послужила аргументом при обсуждении ожиданий относительно уровня компенсации
Внешние факторы
- Переход из малооплачиваемой технологии в высокооплачиваемую
- Специалистов в новой технологии крайне мало на рынке труда, а спрос не закрывается “аборигенами” стека
- Низкий спрос на предыдущую технологию среди работодателей на рынке труда (ограниченном географически, культурно, языком коммуникации и т.д.)
- Опыт работы на узко специализированной, локально ориентированной технологии, спрос на которую падал и/или в полной мере удовлетворялся “аборигенами” стека
- Предыдущий стек устарел и не оставил после себя достаточного количества support-проектов
- Смена трудовой локации
Физический переезд или работа на зарубежных заказчиков. - Инициированные работодателем переход в отраслевые гиганты
Если по какой-то причине работодатели замечали талантливого разработчика, и тот соглашался на смену стека.
Неустойчивые ожидания
Экономия на ФОТ
Вопреки нулевой гипотезе исследования, экономия на ФОТ не являлась базовым ожиданием работодателей при найме про-джуниоров, и либо не упоминалась вовсе, либо описывалась как краткосрочный дисконт на период переобучения специалиста. С учетом инвестиций в обучение, менторство, и общие расходы на онбординг нового сотрудника, подобный дисконт составлял 10-15% от стоимости найма готового мидла на рынке, или одной месячной зарплате специалиста за год.
Личный опыт про-джуниоров
Вопрос о профессиональной трансформации, адресованный к разработчикам, раскладывался на 3 сюжетные линии: получение навыков и освоение новой технологии, уровень компенсации и особенности прохождения собеседований.
- Получение навыков: Может ли про-джуниор вырасти до мидла, не получив реального опыта работы?
Если коротко, то вряд ли. Можно ли “продать” себя как мидла — да. Причем, для претендентов на “удаленку” эта стратегия выглядела выигрышной. По опыту респондента, Middle-разработчик выигрывал у Junior-соискателя из-за большей самостоятельности в глазах работодателя.
Можно ли “прокачаться” занимаясь с pet-проектом — да. Особенно эффективными были прохождение через код-ревью или “бета-релизы” pet-проектов, то есть ситуации при которых про-джуниоры получали обратную связь, как с технической, так и с пользовательской точек зрения. Однако, по мнению самих разработчиков, значительно быстрее набор опыта происходил при регулярном решении бизнес-задач: Upwork и эпизодические подработки, устройство на работу. - Уровень компенсации на новом стеке
Дельта в уменьшении уровня дохода между последним местом работы на старой технологии и первой работой на новом стеке -20-30%. Могу предположить, что двукратная разница в оценке уровня компенсации разработчиков и зарплатного дисконта, как его понимают представители работодателя, обусловлена сопутствующими найму расходами, а также стоимостью онбординга и обучения внутри компании.
Однако, при личном упорстве и прозрачности в отношениях с работодателем, этот стэп-бэк отыгрывался примерно за год (по мере роста уровня компетенций в новом стеке), что соответствовало оценкам продолжительности переподготовки, данным HR-ами. - Презентация предыдущего опыта
Как презентовать свой предыдущий опыт и определить собственный профессиональный статус: “понимает ли интервьюер, что я не такой уж “зеленый”? как раскрыть свои стороны? на что я могу претендовать?”
Для того, чтобы ответить на эти вопросы у респондентов-разработчиков уходило от года до пяти с момента начала изучения новой технологии.
Я выделил три стратегии поведения, которые, вероятно, могли бы комбинироваться по-другому, но встретились мне в следующих связках:
- Стратегия “Без затей”
Самый простой, но наиболее рискованный вариант:
- Фокус на опыте работы со старой технологией
- Перечисление навыков в новом стеке
- “Путь хитреца”
- Убрать упоминания о старой технологии из резюме
- Сделать фокус на решенных бизнес-кейсах, чтобы не напугать работодателя-стартапера излишне глубокими познаниями в энтерпрайз-технологии
- Через новый стек
- Рассказать о текущих результатах в изучении новой технологии
- Сделать акцент на универсальные навыки, наработанные в старом стеке
Об источниках, респондентах и ревьюерах
Мне не удалось найти открытых данных или каких-либо свидетельств более ранних исследований, посвященных смене стека, кроме результатов, полученных Эриком Бернхардссоном. В 2017 Эрик провел попарное сравнение поисковых запросов в Google и получил матрицу миграции девелоперов между наиболее популярными ЯП.
Другой количественный подход был предложен Уораном Лонгом, который, в отличие от Бернхардссона, построил свою работу на анализе коммитов в Git. Несмотря на очевидные методические различия в подходах и полученных результатах, и Бернхардссон, и Лонг были сфокусированы на самом факте смены стека, и, в меньшей степени, интересовались личным опытом разработчика в момент перехода на новую технологию.
На русском языке, тема смены профильного стека также является достаточно маргинальной, и возникает при обсуждении “Full-stack vs Single-Stack”, смены работы, или “как не растерять ценность на рынке труда/избежать выгорания”. По этой причине, основным местом поиска респондентов-разработчиков стали комментарии к заметкам и статьям на профильных ресурсах (в первую очередь, на Хабре).
В ходе сбора данных для первой фазы исследования, я был приятно удивлен открытости респондентов — разработчики охотно делились своим опытом, а HR-ы и рекрутеры часто рекомендовали своих коллег для следующих интервью. В свою очередь, я хочу выразить слова благодарности.
- Хабр-контрибьюторам за личные исследования, статьи и обсуждения, которые позволили мне найти респондентов и глубже погрузиться в контекст проблемы (varanio, SergioPredatore, igor-sheludko, stilic, 0xd34df00d, tmn4jq, fillpackart, Gorthauer87)
- mclander, jehy и Денису Неклюдову за участие в комментировании и ревью первой версии этой заметки, а также Color, рассказавшего про личный опыт перехода с ABAP на Go (видео)
- всем тем, кто уже успел принять участия в исследовании и тем, кто только собирается пройти опросе
- Стратегия “Без затей”
DrPass
Мне даже сам термин «про-джуниор» категорически не нравится. Он не отражает суть. Человек, который состоялся в какой-либо технологии разработки, в принципе не будет джуниором при смене платформы. Это имеет смысл, только если кто-то с пайтона и хаскеля ушёл в хирургию или там в пчеловодство. Человек, который с одной платформы, будучи там хотя бы миддлом, перешёл на другую, уже де-факто не джуниор, его вливание в полноценную работу занимает дни и недели, а не месяцы и годы. И тем более не
abyssSoft
Полностью с вами согласен. Паттерны программирования никуда не денутся же (умение применение того же многострадального MVC и т.д.). Да, в зависимости от стека они могут немного измениться, но вот чтобы разработчик прям из мидла в джуна, как то я себе это не представляю, он же не поглупел сразу на порядок.
Да и профессия разработчика подразумевает постоянную учебу и изучение нового стека и технологий, как он может стать джуном?
usego
Если бросаться в крайности, то сениор c десятками лет опыта на условном Cobol может совершенно не ориентироваться в паттернах, принятых при современной разработке. Более того, «человек, который писал на фортране, на любом другом языке будет писать на фортране» — такое тоже наблюдал.
SpiderEkb
Тут тоже спорно. На мой взгляд.
Человек с опытом разработки уже обладает как минимум навыками алгоритмического мышления.
Кроме того, имея опыт разработки на условном cobol, человек знает как его сильные, так и слабые стороны. И, переходя на новый стек, такой человек найдет там для себя то, чего ему не хватало в старом. И будет этим пользоваться.
smartello
Вот я начал с PHP, потом ушёл в C# и JS (Sencha), потом нырнул в ABAP и всё шло хорошо. В SAP появились нормальные интерфейсы на JS, ABAP закрыли одатой и тоже всё хорошо. Потом стали переносить логику в БД и пришлось перестраиваться, тоже прошло относительно безболезненно. В конце концов, как говорили в университете: «есть всего два типа программистов — те, которые понимают как работают указатели и те, которые не закончат третий курс.»
Но вот пришёл день и я стал по ночам писать для себя вспомогательные штуки на Vapor и мозг сдался: надо в цикле достать файл из внешнего сервиса (асинхронность), распарсить (асинхронность) и вернуть результат. Я уже три дня (а вернее ночи) не могу понять как мне дождаться результата перед тем, как завершить запрос. возможно, если бы я работал в команде, — мне бы показал сеньор как делать такую штуку и я бы всё понял за пять минут. Но текущая перестройка САМАЯ болезненная из всех что у меня были. Паттерны, наверное, никуда не делись, просто они другие!
PS: да, у Vapor есть Discord где реально быстро отвечают даже на глупые вопросы. Просто я люблю сначала сам попробовать понять.
PPS: я нашёл, надо собрать массив ELF и вызвать .flatten
yudinetz
Не многие работодатели с вами согласятся. Поэтому у таких работодателей работают условные senior React developer'ы, и у них всегда трудности с наймом людей, потому что «если у человека нет 5 лет опыта в реакте, то он не сеньор, и если он работал эти 5 лет с ангуляром, то он нам не подходит. Ну, или мы можем его нанять забесплатно интерном, ведь он никогда не работал с реактом!»
Nikobraz
У нас просто не готовы нанимать настоящих инженеров и платить им настоящие деньги. А так дали лычку сеньора и человек рад.
mudriyjo
У каждого работодателя свой подход. Некоторые психологически не готовы инвестировать в только что пришедшего сеньора.
Ну и в ту же копилку человек проработавший 2-3+ года на определенном стэке знает все ограничения и неочевидные места фреймворка.
Я очень давно интересуюсь вопросами и подходами найма, но внятной статистике мне найти не удалось. Может быть у вас есть корреляция условий найма и скорости?
nikitaag Автор
DrPass, спасибо за комментарий!
Мне кажется, что вы правы в том, что наработанные за годы базовые скиллы не теряют ценности достаточно долго. По крайней мере, это очень похоже на то, что я слышал от респондентов. Но цитата, которую вы использовали относилась к тому, как много времени уходило у респондентов-разработчиков для того, чтобы разобраться в самих себе.
Для того, чтобы проиллюстрировать ваш пример лучше подойдет цитата
Разница между двумя фрагментами в том, что в первом случае речь шла о самоощущении разработчиков-респондентов (на что я могу претендовать?), а во втором — о том, как быстро прогрессировали разработчики, меняющие стек (по оценке представителей работодателя).
Keynessian
Это с точки зрения тупой кадровчики, и не менее тупого манагера, человек при смене не то что языка, а даже просто фреймворка становится «джуниором».
Это ТУПОЙ термин, подразумевающий менее ТУПОЙ подход, как в известном анекдоте про найм столяра: