Как нанять 15 джунов и вытащить проект

Усі статті, обговорення, новини для початківців — в одному місці. Підписуйтеся на телеграм-канал!

Меня зовут Дмитрий Демаков и последние несколько лет я работаю в EPAM в ролях Front-end Team Lead, Front-end Tech Lead и Software Engineering Manager. В определенный момент работы у меня возникла необходимость расширить команду. В итоге, за полтора года мы взяли в команду 21 фронтенд-разработчика, 15 из которых были джуниорами. Почему мы так сделали и как из этой инициативы получился win-win эффект, читайте далее.

Кроме проектов, я всегда был вовлечен в разнообразные «творческие» активности, по типу технических интервью (которых провел более 60), менторинга коллег, чтения лекций о веб-разработке (включая лекции для студентов в КПИ и в Шеве) и др.

Кроме технической стороны моей работы, меня всегда увлекал people management, всегда было интересно помогать людям и бизнесу добиваться целей и находить win-win решения, которые порадуют всех :)

В общем, история началась с того, что на одном из проектов я работал на позиции техлида по фронтенду. Но кроме принятия архитектурных решений, код ревью и решения «творческих» задач, я был ответственен за расширение и сокращение команды, подбор и техническое интервью кандидатов, а также создание условий, чтобы всем членам команды работалось бодро и весело над интересными задачами.

Когда мы начинали, команда состояла из 12 девелоперов (2 джуна, 8 мидлов разной «крепости», 1 синьор и я).

В определенный момент возникла необходимость немного расширить команду и взять двоих новых человек, через несколько месяцев нужно было взять еще четверых, а потом еще шестерых, и еще четверых через пару месяцев, и т.д. В итоге, за полтора года мы выросли до 33 человек, взяв 21 FE девелопера. Из них 15 были джунами, большинство из которых без продакшн опыта.

Звучит как треш и фантастика, но на самом деле все получилось очень хорошо. Опыт получился исключительным. Все детали далее по тексту.

Проект и технологии

Отдельного внимания заслуживают технологии, которые использовались на проекте. Сам продукт представляет собой классический e-commerce, то есть интернет-магазин, а точнее, группу интернет-магазинов разных брендов и языков.

Технологической основой сайтов выступал Hybris — это CMS для интернет-магазинов от SAP, написанная на Java. Он использует SSR (Server-Side Rendering), и из коробки перезагружает страницу чуть ли не на каждый чих пользователя. Понятное дело, UX в таком случае будет не самым лучшим, и поэтому заблаговременно было принято решение развивать клиентскую сторону приложения и переносить туда часть бизнес-логики, опираясь на REST API.

На фронте мы использовали Lit-Element для веб-компонентов, Redux + Saga для управления данными и сайд эффектов, Webpack и немного других вспомогательных технологий для качества, тестов и прочих стандартных процессов. Я не буду сейчас вдаваться в детали описания стека и его причины. Тут хочется просто подчеркнуть, что технологии, в принципе, нормальные, но со своей ложкой дегтя, о которой еще пойдет речь далее.

Также добавлю, что к тому времени, как мы начали активно расширяться, было уже написано несколько десятков тысяч строк кода на фронте, соответственно, всем новым разработчикам приходилось разбираться с текущей архитектурой проекта, всеми технологиями и тем, как мы их юзаем, а также, конечно, с Хайбрисом. В общем, сама разработка была не самой простой.

Сложности с расширением команды

Факторов, которые препятствовали быстрому и легкому хайрингу, было несколько.

1. Пожалуй, один из главных — несмотря на то, что мы использовали Redux+Saga, мы не использовали React. А наша библиотека компонентов Lit-Element далеко не всегда была интересна кандидатам, многие релевантные для нас кандидаты отдавали предпочтение именно React.
2. Еще одним фактором оказалось состояние рынка, он был довольно горячий (мы тогда так думали, но сейчас понимаем, что бывает и жарче). Набрать, скажем, шесть опытных фронтов за 2 месяца было действительно сложно, несмотря на то, что мы использовали разные каналы. А именно:
   
   • Внешний локальный рынок. Исторически, с «доковидных» времен, мы более тяготели к кандидатам из Киева, так как большая часть команды работала в одном из киевских офисов. С марта 2020-го все ушли в онлайн, но мы не знали, когда вернемся в офис, поэтому смотрели сначала местных ребят. В таких случаях меньше вопросов с техникой и ее доставкой, можно встретиться в офисе при необходимости.
   • Внешний ремоут рынок. В EPAM еще до ковида была программа EPAM Anywhere, которая позволяет работать удаленно из городов и деревень, где нет офиса компании. Процесситься такие кандидаты могут долго. У них обычно есть нотис период, то есть срок, спустя который кандидат может выйти в компанию при успешном прохождении входного интервью и принятии оффера. Потом нужно доставить и настроить технику, пройти онбординг и так далее. Короче, процесс обычно занимал минимум месяц, нас это не всегда устраивало, поэтому на этот канал сильно не рассчитывали.
   • Локальный бенч компании. Найти кандидата тут было идеальным вариантом. Мы знали, как человек себя показывал на прошлых проектах, он не требует онбординга в компанию, быстрее вливается в работу, может быть доступен «уже вчера».
   • Ремоут бенч компании. Тоже хороший вариант, но кандидатов тут было мало.
   • EPAM Lab — место, где готовят к продакшну джуниоров. Это единственная возможность для начинающего специалиста стать сотрудником EPAM, поскольку с рынка компания берет только мидлов и выше.
3. Вдобавок, всем девелоперам в команде, включая фронтов, для работы нужно было локально разворачивать и держать актуальным весь сайт, включая бэкенд, базу, поисковый движок и еще пару интеграций. Все бы ничего, если было бы достаточно один раз поднять и использовать, но как бы не так.
   Активная разработка шла не только на фронте, но и на бэке тоже (усилиями более 100 девов в разных командах), соответственно, регулярно приходилось пересобирать и инициализировать весь сайт, чтоб держать его более-менее актуальным. Более того, из-за того, что Hybris — это все-таки CMS (Content Management System), дополнительным источником трудностей порой становился контент, а точнее, состав и конфигурация страниц и компонентов для самой системы, ее тоже нужно было держать «живой».
   И как вы понимаете, периодически что-то ломалось.
   Все эти «бытовые радости» могут не удивить бывалого бэкендера. Но для фронтов, которые в 95% случаев привыкли к SPA (Single Page Application), мгновенным пересборкам и работе с данными только через REST API, это было больно и непривычно.
   Мы, конечно, могли ничего не говорить кандидатам об этом, потом был бы сюрприз :D, но вместе с ним пришла бы и демотивация, чего нам точно не надо было, поэтому мы сразу открыто говорили о преимуществах и недостатках позиции. Для кого-то это было критичным, для кого-то — нет.
4. Также стоит упомянуть кастомер интервью. Дело в том, что на стороне клиента были свои frontend-эксперты, и они хотели интервьюировать каждого кандидата лично. В целом, это интервью было адекватным и не слишком сложным. В 90% случаев претенденты проходили его успешно, однако бывало, что мы теряли хороших кандидатов из-за того, что «кандидат не смог назвать различий между LESS и SASS».
5. Ну и в завершение, English. Разговорный уровень должен быть как минимум B1, чтоб кандидат мог пройти кастомер интервью и работать в команде дальше. Многие команды были смешанными и частично состояли из разработчиков на стороне клиента, соответственно, английский был нужен каждый день.

Данный список дает ясное понимание, что условия, в которых нам пришлось активно расширяться, оказались не самыми сахарными.

Результаты

Всю динамику с привязкой к датам можно понять, взглянув на следующий график:

Весь таймлайн — это период с апреля 2019 года по октябрь 2020-го.

Голубой линией показано общее количество FE разработчиков в командах. Начинали мы с 12 человек и доросли до 33 человек к октябрю 2020-го.

Синей линией обозначено количество джуниоров на проекте. Минимум одномоментно таких ребят было двое, максимум — 10.

Оранжевая линия показывает процентное соотношение джунов к общему числу FE коллег. От 9% до 38%.

Также вертикальными линиями я отметил экстремумы, то есть ситуации, в которых процент джунов был максимальным и минимальным.

Максимальный показатель — это 38%, 10 человек из 26. Такая цифра может кому-то показаться огромной, но я считаю, что она вполне адекватна. В данной ситуации большое значение имеет то, какое количество «старших товарищей» в лице крепких мидлов и синьоров могут качественно саппортить этих джунов, чтобы они успешно заонбордились и нормально перформили. Пирамиду синьорити старались держать сбалансированной. Ну и, конечно, джун джуну рознь, этого момента мы еще коснемся.

Хочется отдельно отметить, что даже в этот период, когда джунов было относительно много, деливери продукта шло стабильно и согласно планам.

Минимальный процент джунов — 9%, то есть три джуна из 32 человека. Несмотря на то, что число джунов падало, за эти полтора года ни один джуниор не покинул проект, общий хедкаунт это подтверждает. Причиной падения показателя стало то, что многие джуны, которых мы взяли примерно за 8-10 месяцев до этого, выросли в мидлов и выпали из этого показателя.

Конечно, мы росли не только за счет начинающих специалистов, наряду с 15 джунами мы за все время взяли 8 инженеров уровня мидл и выше.

Может показаться, что нам просто повезло. Возможно, конечно, без удачи и не обошлось, но я все же считаю, что ключевой фактор — это та система, с которой мы отбирали и тренировали джунов. Об этом и поговорим далее.

Строгий отбор

К отбору джунов мы относились супер ответственно. Как я уже упомянул выше, джунов EPAM берет только из своей лабы, с ней мы плотно и работали. Проанализировали около 80 профилей за все время, смотрели, кто что умеет, с какими технологиями есть опыт, уровень английского, и кто как показывал себя во время обучения. В итоге позвали на интервью 25 человек.

Проверяли JavaScript кор, Redux, верстку, как работает браузер, как что оптимизировать, английский, само собой, также смотрели на мотивацию и обучаемость.

В итоге мы отобрали 17 человек.

Я глубоко убежден, что лаба со своей стороны отбирает и готовит ребят очень хорошо, рынок зачастую оценивает их как мидлов. Дело в том, что студенты в лабе, которые дошли до этапа интервью на проекты, уже предварительно прошли довольно строгую селекцию на своем пути, выучили наиболее актуальные технологии и поработали в командах в production-like условиях, так что можно сказать, что там уже выжили сильнейшие.

Стажировка и менторская программа

Пройдя наше интервью, джуны попадали к нам на «стажировочную» позицию длительностью в один месяц, в редких случаях — два. Основная цель этого периода — помочь ребятам разобраться с нашими технологиями (и проектом), а также подготовить к кастомер интервью, которое определяло их дальнейший путь на нашем проекте.

Для того, чтобы комплексно и качественно подготовить новичков во время их стажировки, я разработал и организовал небольшую менторскую программу, которая состояла из 15 обязательных тем для самостоятельного изучения. Темы были разными, часть из них относилась к технологиям, с которыми мы работаем, часть касалась онбординга на проект.

Вот полный список (на языке оригинала):

• Clone project
• Learn project structure (FE)
• Setup project styleguide env
• WebComponents (Learn and understand how it used in the project)
• LitElement (Learn and understand how it used in the project)
• Redux+Saga (Learn and understand how it used in the project)
• Turbolinks (Learn and understand how it used in the project)
• Learn project webpack builds
• Refresh scss (+responsive)
• Learn Dynamic forms on the styleguide
• Setup local Hybris env
• Learn Hybris components
• Learn Dynamic forms on local Hybris env
• Our Git strategy
• Pair programming with a mentor

Плюс по каждому пункту были описаны простые acceptance criterias и практические задания, чтобы джуны лучше понимали, что конкретно нужно выучить по каждой теме и как проверить, что они действительно в чем-то разобрались.

Одной из ключевых составляющих данной менторской программы, собственно, и были наши менторы. Эту роль играли члены нашей команды, которые уже обладали опытом и экспертизой нашего проекта, плюс, конечно, желанием. Менторы отвечали на вопросы подопечных, проверяли понимание изученной темы, парно программировали и проставляли успеваемость подопечных в эксельку.

Из-за того, что эта нагрузка ложилась на менторов поверх проектной, распределяли изначально по одному джуну на каждого. Однако некоторым наставникам эта активность настолько «зашла», что они брали себе по несколько учеников.

Стоит отдельно отметить, что вся эта программа была абсолютно бесплатной для всех ее участников, джуниоры ничего не платили, менторы ничего не зарабатывали.

Onboarding support

После успешного прохождения кастомер интервью джун попадал на billable позицию и становился полноценным членом команды. Благодаря тому, что во время стажировки новички довольно глубоко погружались в наш проект, настраивали локальный энв, разобрались, что и как работает в коде, а также знакомились с коллегами, они практически с первого дня начинали заниматься простыми, но все же реальными задачами. Это также один из положительных сайд-эффектов пройденной менторской программы.

Конечно, у каждого ньюкамера был свой старший товарищ, который был всегда готов ответить на любой вопрос, обсудить техническое решение и провести предварительное код ревью. Практически всегда это был тот же человек, который был ментором на этапе стажировки. К этому моменту менти и ментор уже хорошо познакомились, поработали вместе месяц, но самое главное, их объединяло общее достижение (успешно пройденное кастомер интервью), и это здорово способствовало более эффективному онбордингу и созданию более дружелюбной атмосферы в команде.

Такой персональный онбординг саппорт обычно длился от месяца до трех, в зависимости от способностей подопечных, и заканчивался, когда старший товарищ понимал, что ньюкамер уже достаточно подготовлен для чуть более независимой работы. Хотя, несомненно, с вопросами можно было прийти всегда и к кому угодно, с этим у нас все было в полном порядке.

Воронка кандидатов

В итоге наша воронка кандидатов выглядела примерно вот так:

Было проанализировано около 80 профилей джунов, 25 человек мы позвали на наше техническое интервью, 17 из них мы взяли на стажировку и, в итоге, 15 ребят успешно прошли кастомер интервью и стали частью команды.

Этими результатами мы остались вполне довольны. Они показывают, что и с отбором и с подготовкой у нас все было хорошо, раз так мало кандидатов мы потеряли на последнем этапе.

Ключевой пункт — поддержка команды

Разбираясь в причинах успеха всей этой инициативы, одним из ключевых факторов я считаю значительную поддержку членами команды моих инициатив на всех этапах.

Самых опытных и/или «голодных» я с самого начала привлекал себе в помощь на технические интервью, со временем, полностью делегировав им проведение самого митинга. После каждого интервью мы созванивались и детально обсуждали кандидата и его соответствие нашим ожиданиям и потребностям, чтобы принять правильное решение. Особенно приятно осознавать, что для некоторых ребят это был первый опыт проведения интервью, и это дало толчок для их профессионального развития далее, многие затем начали проводить внешние интервью в компанию.

На этапе менторской программы, как бы хорошо я ее не продумал, но у нас тоже ничего бы не получилось без участия менторов, которыми выступили те же инициативные члены команды. Для ряда коллег это был первый опыт менторства, и поначалу мы детально обсуждали, что мы ожидаем от этого процесса, активно помогали друг другу.

Мне, конечно, очень повезло с командой (лишь часть из которой я подбирал сам) — все ребята были очень ответственными, мотивированными и готовыми выходить из зоны комфорта. Лишь один раз ко мне подошел коллега и сказал, что ему было интересно попробовать, но он все-таки чувствует себя недостаточно комфортно в менторинге и ему это не очень интересно. Все остальные были довольны и охотно участвовали вновь и вновь.

Здорово, что получилось создать очень дружелюбную и позитивную атмосферу в команде, приправленную стремлением к профессиональному развитию. Я бы сказал, что в целом корпоративная культура EPAM здорово способствует этому, но бывает по-разному.

Выводы. Win-win решение

Я считаю, что одной из главных черт менеджера должно быть стремление к поиску win-win решений, то есть таких решений, в которых ни одна из сторон не жертвует своими интересами, но находится вариант, который устраивает всех. Конечно, не всегда такие решения возможны, но на мой взгляд, это может случаться чаще, чем принято считать.

Для того, чтобы найти такие варианты, нужно как можно лучше понимать интересы сторон, чтобы наверняка знать, что и в какой степени важно, а чем можно пренебречь ради другой, более приоритетной, цели. И тут ничто лучше не поможет, чем плотное общение и заинтересованность в помощи другой стороне, будь то член команды, менеджмент компании и/или проекта, продакт оунер или другие стейкхолдеры.

Лично меня больше всего радует разносторонний эффект от всей инициативы.

Проект. Проект в срок получил необходимое количество инженеров со скиллами, достаточными для выполнения большинства запланированных задач. Тем самым мы выполнили свои обязательства перед клиентом и подтвердили статус надежного партнера. Хочется отдельно сказать, что за все время клиент ни разу не жаловался на перформанс ребят, прошедших нашу менторскую программу, хотя бывали жалобы на других коллег, которых мы взяли с бенча или с рынка. Некоторых даже пришлось выводить из команды. Для меня это главный показатель, что уровень знаний и способностей подготовленных нами ребят абсолютно соответствовал позициям.

Джуны. Для большинства из них наш проект стал первым продакшн проектом с оплачиваемой позицией, благодаря которой они становились полноценными сотрудниками EPAM. Мне всегда было очень приятно видеть, как они радовались, когда узнавали, что прошли кастомер интервью и их берут в команду, это было искренне и неповторимо. Большинство ребят, показывая хороший перфоманс, спустя примерно 8-10 месяцев получали промо на миддла, были рады своему карьерному росту и благодарны проекту.

Команда. Благодаря этой инициативе многие наши teammates не только попробовали, но и порядочно прокачали навыки проведения технических интервью и менторинга. Некоторые ребята, в том числе благодаря этому опыту, успешно прошли ассессмент на синьора и получили повышение, что тоже искренне меня радовало. В любом случае все получили полезный и ценный опыт.

Компания. Кроме того, что компания продолжала долгосрочное взаимовыгодное сотрудничество с клиентом, мы принесли дополнительную ценность из-за того, что сделали ставку именно на подготовленных джунов, компенсация которых ниже, чем у мидлов и синьоров. По примерным подсчетам, дополнительная прибыль от этой затеи составила порядка $150 000.

Я. Я получил абсолютно бесценный опыт и массу позитивных впечатлений от работы с такой классной командой :)

В завершение, хочу перечислить и поблагодарить наиболее активных ребят из команды, благодаря усилиям которых у нас получилось добиться поставленных целей. Андрей Шоферивский, Андрей Евгеньев, Александр Кукла, Юлия Мельниченко, Макс Ляпкало, спасибо вам за помощь и поддержку, вы прекрасны.