Почему стоит нанимать джуниоров

Когда я начинал как разработчик на Rails, я постоянно ковырялся с фреймворками все свое свободное время, которого, однако, у меня было достаточно. Я не был женат, работал в Coles ^[1] и подрабатывал на фрилансе, выполняя заказы на PHP и Rails.

Как-то я услышал о проводимом в городе Аделаида Ruby Meetup. Сразу после работы я рванул на поезд и отправился на это мероприятие. Когда я туда попал, несколько человек спросили меня, чем я занимаюсь. Я рассказал о работе в Coles, о PHP и Rails, на что мне ответили «ты не должен больше работать в Coles» и трое из них протянули мне свои визитные карточки, сказав, чтобы я подал им резюме. Я отправил заявку в Sealink и меня взяли.

В Sealink я попал в подмастерья команды Rails-разработчиков, которые имели кучу терпения для того, чтобы мириться с моими 19-летними выходками. Я очень благодарен им за то время, что они потратили на мое обучение и, как я считаю, именно их наставничество заложило основу моей карьеры и всего того, что я делал следующие десять лет.

В Мельбурне есть много джуниоров, посещающих Ruby Meetup'ы. Я знаю это наверняка, так как помогал организовывать ночные хакатоны, на которые они тоже ходят. И вот представьте, если бы какой-нибудь новичок на митапе сказал бы вам, что он активно ищет работу, вы бы его наняли? Возможно, нет. Создается впечатление, что на таких мероприятиях царит атмосфера отвращения к найму джуниоров, ведь потому, что они, джуниоры, отнимают столь драгоценное время команды, которое могло быть потрачено на разработку, на их обучение.

Раньше существовала серьезная нехватка талантливых и квалифицированных разработчиков и компаниям приходилось нанимать тех, кого они могли найти. Именно поэтому когда-то я так легко устроился Rails-разработчиком. Думаю, что теперь все вернулось на круги своя и наличие таланта не имеет никакого значения для того, чтобы взять человека на работу.

В последнее время я много дискутировал в Ruby-сообществе на тему уклонения компаний от найма джуниоров. Вместо них компании стремятся нанимать мидлов и синьоров и не хотят иметь джуниоров в команде, которые будут учиться у тех же мидлов и синьоров.

У адвокатов, слесарей, механиков и во многих других профессиях есть культура ученичества (и подмастерий), так чем программисты хуже? Это довольно странно, потому что в IT-компаниях существует достаточная текучка, которая должна была донести до руководства урок, что всегда нужно задумываться о подготовке кадров на будущее. Мы — молодая община с опытом менее пятнадцати лет и нам нужно задумываться о долгосрочной перспективе: кто будет поддерживать наш код после того, как мы уйдем?

Найм сеньоров

Давайте посмотрим, почему компании желают нанимать в первую очередь синьоров. В компании, где я работал, мы хотели нанять нового middle/senior разработчика, потому что наша нагрузка дошла до уровня, когда мы уже физически не справлялись с поставленными задачами. Я полагаю, тоже происходит и в других компаниях. Где бы я не работал — в том числе и по сей день — у меня, да и у вас, я полагаю, всегда стояли люди, которые дышали в затылок и периодически спрашивали, когда будут пофикшены баги или реализованы какие-то новые функции.

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

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

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

Мы, как сообщество, уже опустошили «бассейн» талантов.

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

Компании так увлекаются попытками найма конкретных 5% или 10% от общего пула разработчиков, что уже не обращают внимания на все остальное. Существует больше количество талантливых людей в оставшихся 90%, но им нужны наставники. Если они его получат, то мы сможем привлечь в наше сообщество умнейших людей. Что делать, если человека, который занимался обучением в вашей компании, продвинули выше и сделали техническим директором? А если бы он стал тем самым инженером, который стоит десятерых, и который мог бы помочь кому угодно и с чем угодно? Я считаю, что компании полностью игнорируют таланты людей, если они не являются для них абсолютно очевидными.

Слишком многие организации сосредоточили свое внимание на краткосрочных целях получения рабочего кода, вместо того, чтобы обратить внимание на долгосрочные перспективы развития и профессионального роста собственных команд.

Компании, нанимают лучших из лучших — людей с гарантированно высоким скиллом — и заставляют заниматься тем, что, по сути своей, является очередной фантазией на тему конкатенации ^[2]

Если сравнивать это с наймом пианистов, то вы нанимаете Шопена, Баха и Ференца Листа для того, чтобы они играли вам «У Мери был маленький барашек».

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

Получение компенсации

Вы можете подумать: что мы, (как организация) поимеем с этого? Я считаю, что думать нужно в обратном направлении: «мы заработали на этом сообществе и теперь пришло время сделать что-то для него». Если вы инвестируете (в долгосрочной перспективе) в здоровье населения, то в дальнейшем вы получаете с этого свои дивиденды. В нашем же случае, вы будете иметь активный кадровый резерв разработчиков, которые смогут заниматься поддержкой вашего продукта. В краткосрочной перспективе вы получите поддержку уровня производительности вашей команды новым талантливым разработчиком.

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

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

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

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

В Marketpalacer мы нанимали джуниоров последний год и я считаю, что они стали очень продуктивными и ценными членами команды. Мы бы пропустили их, если бы были сосредоточены исключительно на найме синьоров или людей, уже имеющих опыт разработки приложений на Rails.

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

Поиск джуниоров

Откуда можно начать поиск джуниоров? Ну, для начала — код-академии. Нет какой-либо конкретной, но моя любимая — Turing ^[3]. Код-академии сейчас позволяют частично решать проблему отсутствия наставничества. Люди платят «академиям» тысячи долларов, чтобы освоить азы. Некоторые из «академий» даже дают гарантии трудоустройства по окончанию их курса. Чаще всего там обучают азам HTML, CSS, Javascript и Ruby и, как правило, «выпускникам» достаточно легко связать свой дальнейший путь конкретно с Ruby. Изначально эти люди очень «зелены», но они, все же, становятся частью сообщества и начинают работать.

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

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

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

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

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

У Асима Аслана (chuhnk) был хороший твит на эту тему:

When hiring remember that someone once gave you an opportunity when you didn't have the experience. Hire smart raw talent and mentor them.

— Asim Aslam (@chuhnk) 14 апреля 2016 г. ^[4]

Также существует отличная книга, которую я все рекомендую прочитать, называется «The Talent Code». В ее слогане говорится: «Великими не рождаются, ими становятся». Книга охватывает примеры совершенствования в таких сферах как спорт, музыка и другие области. Все промышленные отрасли, описанные в ней, так или иначе используют модель наставничества и подмастерий. Тем не менее, это никого не трогает в сообществе программистов: мы все еще слишком молодая община.

По секрету расскажу вам главную мысль этой книги: если кто-то в чем-то реально хорош, он должен послать все к чертям и заниматься именно этим. Где мы возьмем синьоров, если мы не нанимаем джуниоров и не позволяем им отточить навыки в реальных условиях?

Много людей говорит об этой проблеме, о найме джуниоров. Так давайте же начнем это делать.

Наставничество

Теперь, когда, как я надеюсь, я убедил вас нанять джуниора, вы можете удивиться и спросить себя «что я делаю?» как только он появится в вашей команде.

Я помогал запустить ночной хакатон «Melbourne Ruby Hack night» где люди не были ограничены какими-либо рамками, где каждый мог взять с собой любой Ruby-проект и работать с ним. Некоторые, даже впервые видя там Ruby, проявляли большой интерес. Эти ночные хакатоны реально работают, потому что эти новые разработчики чувствуют себя в безопасности, чувствуют доброжелательную атмосферу и что ни один вопрос не является слишком «тупым», чтобы его задать.

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

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

Я ежедневно трудился в паре с некоторыми разработчиками, во времена моей работы в GetUp, и через несколько лет они превратились в уверенных разрабов на Rails. Я делал то же самое и в других компаниях, и каждый раз я видел стремительный профессиональный рост джуниоров, наставником которых был. Одно из лучших чувств в мире, это когда джун говорит: «А, я понял!».

Парная работа также помогает укрепить и собственные знания. Если вы не можете кому-то что-то достаточно внятно объяснить, то вы недостаточно хорошо это знаете. Парная работа полезна младшим разработчикам, потому что они получают новые знания, но также это полезно и их старшим товарищам: в ходе общения с другими людьми по теме, для более ясного изложения, они структурируют свои знания.

Как именно вы должны работать в паре с джуниором? Ну, у Лидии Гуарино есть пара толковых твитов на эту тему:

5) For junior devs, a good guideline for scope is something that can be completed in 2-3 days. You want to keep your feedback loop short.

— Lydia Guarino (@lydiaguarino) 13 апреля 2016 г. ^[5]

5) Tasks with scope of more than 3 days are tasks that are not defined well enough. Break them down further.

— Lydia Guarino (@lydiaguarino) 13 апреля 2016 г. ^[6]

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

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

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

Совместный разбор кода важен, потому что в нем не написано «почему ты это делаешь?», в нем нет никаких эмоций, в отличие от ситуации, когда с вами говорит живой человек. Но будьте осторожны: джуниор может интерпретировать ваш вопрос «Почему ты сделал так?» как агрессивный «Э! Почему ты делаешь это так?».

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

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

Ревью кода также позволяет старшим коллегам оценить, насколько хорошо ваш новичок справляется с поставленными задачами. Если он отлично управляется с мелкими двухдневными тасками, возможно, пора дать ему что-то на четыре дня? Если же нет, то, по всей видимости, придется еще его подучить.

В конце концов, суть наставничества заключается в том, чтобы джуниор почувствовал себя нужным и в безопасности в вашей команде. На самом деле, это касается абсолютно всех членов коллектива. Google запустил проект, который они назвали «Project Aristotle», в рамках которого они пытались найти способ создания эффективных команд ^[7]. Они провели опрос сотрудников и получили пять пунктов:

И пунктом №1 стала «Психологическая безопасность(комфорт)»: члены команды чувствуют себя в безопасности и могут позволить себе быть уязвимыми.

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

Автор: ua-hosting.company

Источник ^[8]