Когда я начинал как разработчик на Rails, я постоянно ковырялся с фреймворками все свое свободное время, которого, однако, у меня было достаточно. Я не был женат, работал в Coles и подрабатывал на фрилансе, выполняя заказы на 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%, но им нужны наставники. Если они его получат, то мы сможем привлечь в наше сообщество умнейших людей. Что делать, если человека, который занимался обучением в вашей компании, продвинули выше и сделали техническим директором? А если бы он стал тем самым инженером, который стоит десятерых, и который мог бы помочь кому угодно и с чем угодно? Я считаю, что компании полностью игнорируют таланты людей, если они не являются для них абсолютно очевидными.
Слишком многие организации сосредоточили свое внимание на краткосрочных целях получения рабочего кода, вместо того, чтобы обратить внимание на долгосрочные перспективы развития и профессионального роста собственных команд.
Компании, нанимают лучших из лучших — людей с гарантированно высоким скиллом — и заставляют заниматься тем, что, по сути своей, является очередной фантазией на тему конкатенации
Если сравнивать это с наймом пианистов, то вы нанимаете Шопена, Баха и Ференца Листа для того, чтобы они играли вам «У Мери был маленький барашек».
Вам не нужно нанимать синьоров. Вам нужно нанять разработчика любого уровня квалификации, обучить их и вырастить. Дайте людям шанс, обучайте их на том, что реально используется, ведь сегодняшние джуниоры завтра могут быть великими разработчиками в вашей компании, но вы просто не даете им возможность ими стать.
Получение компенсации
Вы можете подумать: что мы, (как организация) поимеем с этого? Я считаю, что думать нужно в обратном направлении: «мы заработали на этом сообществе и теперь пришло время сделать что-то для него». Если вы инвестируете (в долгосрочной перспективе) в здоровье населения, то в дальнейшем вы получаете с этого свои дивиденды. В нашем же случае, вы будете иметь активный кадровый резерв разработчиков, которые смогут заниматься поддержкой вашего продукта. В краткосрочной перспективе вы получите поддержку уровня производительности вашей команды новым талантливым разработчиком.
Вы можете думать, что вам нужны только лучшие, «крутые засранцы», потому что ваше приложение — один большой, бесструктурный монолитный бегемот, справиться с которым смогут только эти самые «крутые засранцы». Вам нужны синьоры, способные сориентироваться в лапше кода, из которого состоит приложение. Возможно, это так. Но в каждом монолитном проекте есть капелька функциональных возможностей, совладать с которыми сможет не только синьор, на которых не-синьор сможет повысить свой скилл, при условии, что будет работать в связке со старшим разработчиком.
Это нормально — нанимать команду без синьоров для того, чтобы работать с кодом уже рабочего продукта. Мы сделали это с «Marketplacer» и мы по-прежнему в бизнесе. Поймите, вашу компанию не охватит пламя только от того, что вы начнете нанимать джуниоров.
Да, это рискованно. Изначально, стоимость содержания такого работника выше, чем прибыль, которую он приносит компании. Но имея возможность роста, они могут вырасти в лучший актив, который вы когда-либо имели.
В момент начала работы джуниоров, долларовая стоимость производимой ими продукции меньше, чем стоимость их содержания. Но с хорошим наставником они могут измениться и перейти в состояние, когда их производительность выше их зарплаты. Да, существует просадка по производительности труда — это правда, но она длится лишь 6 месяцев, если вы все делаете правильно. В конце концов, вместо одного разработчика вы имеете уже двух. Даже если джуниор вполовину производителен относительно синьора, то у вас есть полтора разработчика, что больше, чем всего один, а из этого следует полуторный рост производительности команды.
В Marketpalacer мы нанимали джуниоров на протяжении последнего года, и я считаю, что они стали очень продуктивными и ценными членами команды. Мы бы пропустили их, если бы были сосредоточены исключительно на найме синьоров или людей, уже имеющих опыт разработки приложений на Rails.
Вы можете думать «а что, если они уйдут»? Этот риск существует при найме сотрудника любого уровня навыка. Если люди уходят из компании, вы должны сделать для себя выводы и понять, почему так происходит. Они уходят по собственным причинам, или дело в вашей компании? Есть ли в вашей компании корпоративная культура, из-за которой не хочется уходить? Или люди работают тут исключительно из-за того, что их интересует код ПО для морских грузоперевозок?
Поиск джуниоров
Откуда можно начать поиск джуниоров? Ну, для начала — код-академии. Нет какой-либо конкретной, но моя любимая — Turing. Код-академии сейчас позволяют частично решать проблему отсутствия наставничества. Люди платят «академиям» тысячи долларов, чтобы освоить азы. Некоторые из «академий» даже дают гарантии трудоустройства по окончанию их курса. Чаще всего там обучают азам 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 г.
Также существует отличная книга, которую я всем рекомендую прочитать, называется «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) 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 г.
И я согласен с обоими. Джуны развиваются быстрее всего, когда им удается быстро достичь положительного результата. Когда они имеют постоянную обратную связь, их доверие к вам растет, а каждый раз, когда они «выигрывают» в коде, растет и их уверенность в себе, что делает их только сильнее.
После того, как они обрели некоторую уверенность в собственных силах, вы можете позволить джуниорам работать самостоятельно. Не существует четких временных рамок, когда этот момент настанет, все зависит от того, насколько способен ваш новичок.
Дайте им волю сделать что-то небольшое и возможность задавать любые вопросы, а самое главное, дайте понять, что «неправильных» путей реализации этого нет. После выполнения задания заставьте их показать то, что они сделали, сядьте рядом и разберите вместе написанный код.
Совместный разбор кода важен, потому что в нем не написано «почему ты это делаешь?», в нем нет никаких эмоций, в отличие от ситуации, когда с вами говорит живой человек. Но будьте осторожны: джуниор может интерпретировать ваш вопрос «Почему ты сделал так?» как агрессивный «Э! Почему ты делаешь это так?».
Визуальный контакт помогает установить связь между учеником и наставником намного лучше, чем, например, сообщения в мессенджере.
Если джуниор допустил ошибку в запросе, то вы можете обсудить ее с ним и исправить. Это снизит вероятность того, что она появится снова.
Ревью кода также позволяет старшим коллегам оценить, насколько хорошо ваш новичок справляется с поставленными задачами. Если он отлично управляется с мелкими двухдневными тасками, возможно, пора дать ему что-то на четыре дня? Если же нет, то, по всей видимости, придется еще его подучить.
В конце концов, суть наставничества заключается в том, чтобы джуниор почувствовал себя нужным и в безопасности в вашей команде. На самом деле, это касается абсолютно всех членов коллектива. Google запустил проект, который они назвали «Project Aristotle», в рамках которого они пытались найти способ создания эффективных команд. Они провели опрос сотрудников и получили пять пунктов:
И пунктом №1 стала «Психологическая безопасность(комфорт)»: члены команды чувствуют себя в безопасности и могут позволить себе быть уязвимыми.
Google — не уникальная компания. Она тоже состоит из людей, как и любая другая организация. И вы должны иметь это ввиду, когда будете обучать собственных новичков и работать с другими членами команды.
Комментарии (61)
rombell
18.05.2016 15:14+13Мой личный опыт говорит, что единственный способ кардинально поменять зарплату — это сменить работу. Я четыре раза менял работу с удвоением, и сейчас делаю это пятый раз. В то же время рост на одном месте за 4 года — максимум 30%
Мне сложно представить компанию, которая может взять junior и вырастить его сама, адекватно повышая з/пл. По той же причине, что и всегда — «нет пророка в своём отечестве»Cryvage
18.05.2016 16:14Чтобы повышение зарплат адекватно работало, нужно чтобы в компании были более менее фиксированные категории программистов. С определенными диапазонами зарплат. И если человек дорос из категории «junior», до категории «middle», то это надо оформлять официальным повышением в должности, с соответствующим повышением зарплаты. В итоге компания имеет нового «middle» разработчика, а на освободившееся место «junior», найти нового сотрудника всяко проще, чем нового «middle». Единственное существенное ограничение здесь, это ситуация, когда компании не нужен новый «middle». Но это, чаще всего, означает стагнацию в компании, и тут есть о чем задуматься. Для подросшего программиста это действительно повод уйти в другую компанию. А компания просто найдет себе нового «junior», раз их устраивает разработчик именно такого уровня. Это, кстати, возможность для бывшего «junior» самому побыть в роли наставника, подготовив себе замену, а потом уже уйти. Таким образом он и сам наберется дополнительного опыта, и заодно отдаст свой «долг» компании, которая помогла ему сделать первые шаги.
И еще, на мой взгляд, тут главное не искать себе «junior» разработчика только ради того, чтобы воспитать из него «middle»/«senior». Если вам нужен именно «middle»/«senior», то скорее всего он нужен вам прямо сейчас, а не через полтора-два года. Так что первое, что нужно сделать, прежде чем начать нанимать новичков — выстроить процесс разработки таким образом, чтобы появились задачи, которые можно доверить именно новичкам. Если в компании каждый разработчик ведет свой проект от и до, то нанять новичка будет пустой тратой времени и денег. Да и новичку будет тяжело. Все будут пытаться отбрыкаться от него. Будут те самые вздохи и закатывание глаз, как описано в статье.
MatrixFailure
18.05.2016 17:14+8А бывало так, что находишь новую работу, приходишь к директору с заявлением по собственному желанию, и вдруг выясняется, что тебе очень хотели повысить зарплату раза в 2 или 1.5, но просто не успели об этом сказать. И так несколько раз.
NINeOneone
19.05.2016 12:40+1Плюсую, то же самое. Только формулировка другая — «что мы можем сделать, чтобы ты остался». А ответ обычно «уже ничего», т.к. если уже решил уходить, значит что-то уже нашел.
Damik
19.05.2016 16:25+1Имея возможность уйти куда-то на бoльшую зарплату, я бы пришел к начальству и сообщил об этом как можно заранее. Так и дела закрыть комфортно время есть, и сторговаться. А если тебе и здесь предложат больше — еще и профит неслабый.
Зачем так подставлять и нынешнего босса — он явно не ожидал ухода, это может навредить проекту, и себе — потенциальная возможность остаться там, где к тебе лояльны, за те же деньги?NINeOneone
19.05.2016 16:39Звучит по-рыцарски конечно, но на второй итерации (а вторая итерация будет, т.к. после повышения начальство будет думать еще лет 5 что «тебе недавно повышали») это будет выглядеть как шантаж. Ваши действия?
defuz
19.05.2016 17:11+2«Это будет выглядеть как шантаж» – это ваши предрасскудки или неадекватность начальства. Если вы понимаете, что стоите больше (например, вас оценила другая компания), почему бы не прийти и не поговорить об этом честно со своим текущим начальником?
NINeOneone
19.05.2016 18:11+1Еще раз — ваши действия на второй итерации? Вы пришли, сказали что уходите, вам подняли ЗП до ожидаемого уровня, вы ушли, вам опять 3-5 лет не поднимают ЗП (это не фантазии, если вы дошли до увольнения в первый раз, скорее всего дойдете и второй), вы нашли другое место работы — ваши действия в этот момент?
defuz
19.05.2016 18:56+2Если вам 3-5 лет не поднимают зарплату, то это повод прийти к начальству и потребовать пересмотра как минимум потому, что за 5 лет часть вашей зарплаты съест инфляция.
Мои действия на второй итерации? Точно такие же. Если я знаю, что могу получать значительно больше, и нет ничего такого, что оправдывало бы более низкую зарплату на текущем месте работы, то что зазорного в том, чтобы прийти и сказать: поднимите мне ЗП или я уйду к другому работодателю, потому что мне не комфортно получать значительно меньше, чем я мог бы получать на аналогичной должности в аналогичной компании? Не обязательно конечно говорить так ультимативно, но ведь суть от этого не меняется.
Scf
19.05.2016 18:56+3"Тебе подняли ЗП, теперь ты обязан не возникать по поводу её роста n лет" — это обыкновенная манипуляция над работниками, которые плохо понимают, что такое бизнес-риски.
"на сколько тебе поднять зп, чтобы ты не ушел" и "на сколько тебе поднять зп, чтобы ты покрыл риск того, что твоя стоимость значительно вырастет, а ты обязался работать за фиксированную зп ближайшие 2 года" — это совершенно разные вещи.
HashieMash
19.05.2016 16:46+31. Пойти просить надбавку может быть дискомфортно, т.к. мало кто любит быть «просящим»;
2. Лояльность к работодателю уже отсутствует, т.к. работник ощущает, что его интересами пренебрегли, когда рынок зарплат вырос, а его оплата труда не растет. Из-за этого возникает ощущение «ненужности», кажется, что не ценят;
3. Как следствие п.2, если есть предложение от другой фирмы, то возникает как раз ощущение «нужности» другой фирме, а еще и платят больше;
4. Если босс не ожидал ухода, то это в какой-то степени проблема босса, т.к. не платил в рамках рынка или не обезопасил себя от раннего рассторжения трудового договора, если человека сманили. В любом случае, это рынок, управляющий персонал должен учитывать эти риски. К тому же, 2 недели никто не отменял для закрытия всех тех самых дел и найма человека на должность или передачи дел.
Это не истина в последней инстанции, и, судя о всему, у вас другие взаимоотношения с начальством. И по совести, да, я бы тоже предупредил заранее. Но я понимаю и тех людей, кто так не делает.
DeadKnight
19.05.2016 09:24+25 удвоений зарплат, это повышение зарплаты в 32 раза. Может конечно я отстал от жизни, но это значит, если бы ты ты начинал карьеру джуном за 300 $/мес. то сейчас ты будешь получать сейчас около 10000 $/мес.
К сожалению, джуны сейчас за 300 долларов не сильно хотят работать, да и сеньорам мало где 10000 долларов в месяц готовы платить.evocatus
19.05.2016 16:30Подозреваю, что человек имел в виду в рублях. Так что можете смело делать на 2, получится в 5 раз, т.е. с условных 300$ до $1500. Даже если с 1000$ до $5000 — вариант не невозможный.
rombell
24.05.2016 22:54Ну так не монотонно. То я дауншифтил 4 года, то рубль. Не всем же з/пл в баксах считают.
И начинал в 1998 с $100, кстати. Потом за 3 года $800.
Shamov
18.05.2016 15:47+2Не совсем понимаю, почему автор говорит о наставничестве джуниоров в побудительной манере и в будущем времени. Неужели у них, на Западе, такого ещё нет? У нас это давно внедрено. Лично я свои первые три года отработал в НИИ практически без денег. Зато у людей, которые там работали, было полно свободного времени, чтобы заниматься со мной. Они научили меня практически всему, что нужно в жизни — SQL, UNIX, Perl и т.д. В общем, уберегли от виндовой ловушки, в которую попадают все новички. Вообще я думаю, что это общий принцип: джуниоры подходят тем, у кого мало денег, но много времени… а сеньоры — тем, у кого наоборот.
ganqqwerty
18.05.2016 17:20+2Вот я тоже начинал с НИИ, но у них есть очень важная характеристика: качество кода и зачастую работа программы глубоко вторичны. Наличие в организации бардака и в то же время относительная финансовая стабильность дает синьорам возможность создавать внутри нее свои царства, в которых можно в том числе и обучать новичков. Думаю, что в рабовладельческом мире Новой Англии такое может не прокатить, потому что за эффективностью следят.
Shamov
18.05.2016 17:59Эффективность ведь бывает разная. Смотря как её измерять. В бизнесе эффективность, естественно, измеряется в деньгах и зависит от издержек, выручки и рисков. Поэтому в бизнесе джуниорам есть место только там, где они могут помочь снизить издержки за счёт почти бесплатного труда над тупыми и однообразными задачами, которые им можно доверить. Это так и в Новой Англии, и где угодно ещё. Вряд ли джуниоры смогут поднять выручку или снизить риски. Но ведь существует не только бизнес. В мире полно работы по разработке софта, которую так или иначе необходимо делать, но для которой не существует никакой бизнес-схемы. Эффективность такой работы можно измерять не в деньгах. С точки зрения тех, кто делает на софте бизнес, выполнение такой работы за счёт государственных денег будет выглядеть как «распил» бюджета. Но при взгляде под немного другим углом в такой деятельности можно увидеть нечто общественно полезное.
janekprostojanek
18.05.2016 18:56Лол. «Внедрено». В том и суть этого длинного, между прочим, повествования, что подразумевается «брать на работу, на которойПЛАТЯТ». Причем платят, как всем. Там же целые абзацы есть про окупаемость!
Shamov
18.05.2016 22:33+1Ну, в этой части текст просто неверен. Сама по себе окупаемость, безусловно, возможна. На длинном временном интервале. Но никакого длинного интервала не будет, поскольку нет надёжных инструментов принуждения к лояльности. Там об этом вскользь тоже сказано. Но как-то невнятно. Предлагается задать себе вопрос: «Почему обучившись джуниоры сразу уходят?» Однако не приведён очевидный ответ на этот вопрос, который состоит в том, что обученные джуниоры уходят ровно потому, что компания начинает им недоплачивать в попытке окупить первоначальные вложения в их обучение. Одно с другим связано. Если платить обученным джуниорам, как всем, то не будет желаемой окупаемости. А если им недоплачивать, то никакая корпоративная культура не поможет.
ArisChik
19.05.2016 11:03+2Строго зависит от людей. Работал я как-то с тех лидом у которого был феноменальный нюх на «молодых и голодных». Он умел за 10 минут понять какая мотивация у человека, что им движет и выбирал тех, кто очень хотел пролезть из говна к солнцу и при этом «котелок варит». После наема никаких «сюсюканий»: на тебе рабочий ноут, сам поставь и сконфигурируй себе БД под хранилище данных, BI систему с репортингом, настрой ETL скрипты и залей себе тестовые данные для работы. (и ты сидишь и делаешь это, спрашиваешь, куришь мануалы, набиваешь шишки) Справился? Оке, вот твоя первая тех спека, дедлайн — конец следующей недели, вперед. Ах да, а вот тебе доки (у него была база почти всех «закрытых» документов из дорогих курсов для сертификаций).
И ты опять сидишь и лабаешь.
В итоге, уже через год его «джуны» умели то, что некоторые «синьоры» не научились делать за 10 лет своего опыта. Но надо сказать что и зп повышал он соответственно и регулярно и не было ощущения что ты за 700 баксов делаешь то что обычно делают за 2500.
Конечно, такой метод строго зависит от людей: надо найти того самого молодого и перспективного из хорошего вуза с хорошими мозгами, но при этом амбициозного и готового пахать, но оно того стоило.
Самая большая проблема в его «школе» была только в том, что через 3-4 года, когда приходил момент расти дальше, ты выходишь на рынок и понимаешь что тебе никто не верит, что за свою карьеру ты проработал с таким огромным стеком технологий, умеешь все это делать и готов быть условным Senior/Tech Lead на равне с тем кто «7+ years of solid experience».Shamov
19.05.2016 13:23+2Это известная стратегия. Никогда раньше не слышал, чтобы её применяли при подборе персонала, но её очень активно применяют женщины при выборе мужа. Мудрая женщина старается выйти не за того, кто уже состоялся в жизни, а за того, кто «имеет хорошие перспективы». Если сама не уверена в выборе, то показывает потенциального жениха маме, чтобы получить более компетентную оценку. Смысл стратегии в том, что если построить семью с перспективным мужем на том этапе, когда он ещё ничего из себя не представляет, то к тому моменту, когда он полностью раскроет весь свой потенциал, тебя с ним уже будет связывать очень многое. Он уже привыкнет к тому, что его место здесь… с тобой. И это будет фактором, существенно ограничивающим его свободу манёвра в новой ситуации, когда он уже хорошо котируется на рынке. Недостаток у этой стратегии только один. Чтобы успешно её применять, нужна хорошая интуиция, позволяющая не только видеть уже имеющиеся достижения, а ещё и чувствовать потенциал будущего развития. У женщин такая интуиция есть.
PavelSandovin
23.05.2016 17:55Так вот почему среди рекрутеров — одни девчонки.
Shamov
23.05.2016 18:34Скорее всего причина не в этом, а в том, что девчонки дешевле обходятся. За одну и ту же работу им, как правило, можно платить меньше. Ведь им обычно не нужно содержать семью, поскольку они и есть та самая семья, которую кому-то нужно содержать. Насколько я понимаю, девчонки-рекрутёры не участвуют в процессе принятия решений. Они лишь выполняют функции коммуникационного посредника и проводят самый первичный грубый отсев. Хотя, конечно, бывают и исключения. Но я знаю только одно такое. Когда-то давным-давно в КРОКе меня собеседовала женщина. Причём уже после технического интервью. Да и по вопросам было понятно, что это более важный этап в процессе принятия решения.
harant
18.05.2016 16:25Shamov, если возможно, расскажите про виндовую ловушку, что это и почему плохо?
Shamov
18.05.2016 18:34+2Винда, как и любой инструмент, имеет свою область применения. Когда ты владеешь одним инструментом существенно лучше, чем другими, тебе начинает казаться, что всё проще делать этим инструментом. Пока область применения инструмента и область решаемых задач совпадают, проблем нет. Но если вдруг возникнет задача, выходящая за область применения инструмента, ты всё равно начинаешь решать её этим инструментом. По отдельности возникающие задачи очень редко бывают такими, что ради них имеет смысл осваивать принципиально иной инструмент. Всегда кажется, что проще сделать их с помощью хорошо освоенного инструмента. Точнее, даже не кажется… это реально так и есть. Инструмент к задаче совершенно не подходит. Но и другого человека, который бы владел подходящим инструментом, в данном конкретном месте и в данное конкретное время нет. Поэтому, как правило, принимается решение делать так, как умеешь и как проще. Это к вопросу о том, почему это плохо.
А ловушкой эта ситуация является потому, что новичку очень легко попасть в неё неосознанно. Обычно все начинают знакомство с компьютером с игр, т.е. с винды. При переходе к программированию комфортнее делать это в знакомой среде. Обычно говорят, что развитие происходит в тот момент, когда выходишь из зоны комфорта. Но кот Матроскин сказал бы, что для того, чтобы выйти из зоны комфорта, нужно сначала войти в зону комфорта. Это в полной мере относится к новичку, желающему научиться программировать. Он изначально находится не в зоне комфорта и стремится сначала в неё войти. Ближайшая к нему зона называется «программирование под винду». Именно в неё новичок и устремляется. Для него это развитие. Однако далеко не каждому потом удаётся накопить достаточный импульс мотивации, чтобы покинуть эту зону комфорта и продолжить своё развитие. Очень многие остаются на виндовой орбите на всю жизнь. И с каждым годом покинуть эту орбиту всё сложнее. Масса накопленного виндового опыта со временем только растёт. И сила гравитации притягивает к винде всё сильнее.Jamon
18.05.2016 19:20Я вот только одного не понял — почему проблема относится именно к винде?
Судя по написанному, винда — первое, с чем, скорее всего, встретится новичок-разработчик. Но, скажем, если тот же новичок (с теми же скиллами) встретится в начале не с виндой, а, скажем, с разработкой под Mac? Ну, скажем, будет у него хорошее место джуниора в хорошей компании под такой проект.
Так вот, — после этого, какая вероятность что этот новичок будет активно смотреть по сторонами (как разработчик), пробовать новые технологии и пр., а не закопается только в проприетарных решениях?
Вот у меня ощущение, что любознательность и желание развиваться в профессиональной области не зависят (ну, не сильно зависят) конкретно от того, что на первом компьютере была винда. Как то так)Shamov
18.05.2016 22:11Если новичок изначально встретится с разработкой под Мак, то это будет очень редкий случай. Это тоже плохо. Но эта проблема не имеет столь массового характера.
Разумеется, любознательность не зависит от того, что на первом компьютере была винда. Но если любознательности нет, то от того, что на первом компьютере была винда, зависит то, кем человек в итоге станет. А у большинства её нет. По крайней мере, её нет в количестве достаточном для того, чтобы вырваться из виндовой ловушки самостоятельно. И спасти в этом случае может только опытный наставник.
lucifer-m
18.05.2016 16:40Я вроде как и не джун но работу в компании один фиг найти не могу. Сейчас начал фрилансить. Думаю собрать много отзывов положительных и тогда будет проще устроится хотя бы джуниором
ganqqwerty
18.05.2016 17:25Общий совет, надеюсь, что будет полезным. Подойди к вопросу поиска работы серьезно. Часть материалов (linkedin-аккаунт, резюме, отзывы) должны быть заточены на девочек-HR-очек. Другая часть (сделанные проекты, вклад в opensource и самое главное github-аккаунт) должны быть заточены на мощных бородатых тимлидов или тимлидерш, которым девочки-HR-очки дадут резюме после предварительной фильтрации.
RPG18
18.05.2016 17:45В прошлый раз никто не смотрел на мой github-аккаунт и все давали тестовые задания чисто на кодирование.
lucifer-m
18.05.2016 19:16а можете описать его? А то я был на немногих собеседованиях. Хочу быть готовым ко всему)
ganqqwerty
18.05.2016 22:21раз на раз не приходится. Если в аккаунте много хорошего кода, то лучше его выпячивать вперед.
felsher70
18.05.2016 17:23Работаю уже 4й месяц Junior Java Developer'ом, очень повезло с компанией, у меня хороший наставник
vyatsek
18.05.2016 22:20Я бы разделил звание старший/рядовой/младший разработчик на несколько составляющих: экспертная, кругозор, интеллект.
• Экспертная составляющая отражает глубину знаний конкретных технологий. На сколько человек точно и досканально представлет внутренее устройство и принцип работы технологии или инструмента.
• Кругозор говорит о том, какие смежные технологии/области изучал человек при решении проблемы.
• Интеллект говорит о способе и эфективности мышления: человек в состоянии выявить проблему, изучить инструменты для её решения и выбрать наиболее подходящие.
В российской практике очень часто на позицию старшего разработчика отбирают только по экспертным знаниям. На собсеседовании спрашивают лютейшие тонкости, кандидат все отвечает, но когда сталкивается с задачей в которой нет опыта, то возникают проблемы, потому как не хватает кругозора и умственных способностей для её решения.
Ошибка заключается в том, что его не спрашивали, а как бы он решал новую задачу, по которой читал только теорию и давно. И вот тут срабатывает кругозор и интеллект, благодаря которым и формируются экспертные знания.
Понятным становится недовольство способными младшими разработчиками: «Мол я не знаю, но вот изучил и применил бы так и так», и его решение имеет верное направление. Т.к. интеллект на уровне, а тонкости и кругозор он получает в процессе.
При устройстве на работу выбирайте те компании, которые ищут умных людей, готовых развиваться и умеющих двигаться в верном направлении. На моей практике таких компаний было две, где на собеседовании выявляли уровень по трем составлящим.
А способному младшему всегда найдется работа, при условии, что в старшем и рядовых составляющие сбалансированы.
akdes
18.05.2016 22:20Для тех, кто рассуждает «сложно найти хорошего, целеустремлённого...»:
1. Мотивация, горбатого исправит.
2. Пробные пару месяцев никто не отменял.
3. Собеседование — отсортировка.
4. При качественном подходе к собеседованию, проверке знаний и отбору сотрудников, максимум что можно потерять: одну месячную зарплату
HashieMash
18.05.2016 22:20+3Данная статья задела меня за живое, т.к. в какой-то мере я нахожусь в том самом состоянии, которое описывает автор, а часть вещей ещё предстоит преодолеть.
Кратко: Наставничество — это отличный вариант обучения программистов даже с нуля (как в моем случае), вещи, указанные автором, работают, я проверил на себе.
Подробно:
В силу обстоятельств 10 лет тому назад я не стал программистом, занялся армией (или она мной), а потом продажами в строительном бизнесе. Но примерно полгода тому назад (спустя 5 лет успешной работы) пришло ощущение бессмысленности ежедневной деятельности, а также появилось желание что-то изменить. И я выбрал RubyOnRails. Вот об этом выборе я хочу чуть подробнее рассказать. Мне повезло, что один из моих друзей работает в этой области и был готов мне помочь начать этот путь.
На начальном этапе было изучение Ruby при помощи Codecademy. Это мог был быть любой другой сайт, как указывает также автор статьи, но у меня был этот. И для изучения базовых основ мне он очень пригодился.
На следующем этапе лично для меня было открытие мира Linux-систем, с которыми я был знаком лишь чуть. Так что установленная Ubuntu сначала на виртуальную машину, а спустя три месяца — на ноутбук, здорово помогла размять мозги. В это же время происходило знакомство с Git. Всё это мне помог осознать и в какой-то степени установить (нет-нет, кнопку «Далее» за меня никто не жал, сам справился) мой друг (наставник). Он предоставил мне для ознакомления наиболее свежие, полные и полезные (на его взгляд) туториалы и гайды.
Третий этап — написание бота для Телеграм, который работал с API вконтакте.
Четвертый — знакомство с Rails.
Пятый — написание блога (тот самый, что за 15 минут, который я делал день).
Шестой — написание своей альтернативы фотохостинга (крайне схематичного, конечно).
Седьмой — работа над реальным проектом сайта, где на текущий момент я реализую самостоятельно небольшие части функционала.
Параллельно я делал каты по Ruby на Codewars (настоятельно советую подобный формат, это отличная подготовка к собеседованию для уже знающих и великолепный способ потренировать разнообразные фундаментальные аспекты языка для тех, кто только учится).
Это все подпадает под тот стиль наставничества, который описывает автор статьи, с разбивкой на небольшие задачи, отслеживанием прогресса, постепенным увеличением сложности (хотя на мой взгляд с Rails переходы по сложности довольно резкие в рамках решаемых задач). Важный аспект, о котором в статье упоминается, это психологический комфорт работы. Например, чтобы не было стыдно за тот код, который ты пишешь. Мой наставник на 7 лет младше меня. Думаю, вы понимаете, насколько важно в таком случае не отбить желание работать совместно резкой критикой тех или иных вещей. Как говорил один умный товарищ из Яндекса в своем выступлении, чем старше становишься, тем более стыдно бывает обратиться за помощью к молодым (которые быстрее и вообще выносливее), но нужно себя перебарывать. Мне повезло с наставником и он оказался способен к такой деятельности: направлять, критикуя профессионально. К нему хочется обращаться за советом. Однако много ли таких людей? На мой взгляд также тяжело найти (в рамках фирмы) человека, который был бы способен являться для Junior-разработчика эффективным наставником, как и для фирмы тяжело найти перспективного разработчика, который будет гореть желанием развиваться и не уйдет в другую фирму через полгода (да, это вопрос корпоративной политики и уровня зарплат, но всё же).
Как итог могу сказать, формат наставничества действительно работает, как минимум на мне.
summerwind
19.05.2016 02:07+1Нужно просто понимать, что ситуации бывают разные. Подход, который советует автор статьи, очень хорошо подходит для больших состоявшихся компаний с готовым продуктом, кучей legacy-кода и неприоритетных задач. Если же у вас команда из пяти человек, жесткие сроки и 85% времени пишется новый функционал, то нанимать джуниоров вместо миддлов и сеньоров будет провальной стратегией. Потому что в данном случае, найми ты хоть трех джуниоров с зарплатой 40к — они не дадут такой эффективности, какую бы дал один сильный миддл или сеньор за 150к.
boblenin
19.05.2016 02:44-1Доводилось нанимать недавно довольно приличное количество народа. Зачастую сеньоры знают увы меньше джуниоров, хотя и стоят при этом больше. Но хороший сеньор, которого да, не просто найти, может влиться в разработку сразу через пару недель, а вот джуниор даже хороший будет разгоняться с месяц. Опять же долгосрочно джуниор, конечно хорошо, особенно если не убежит через годик обучения но вот краткосрочно один джуниор и один синьор в комманде — это 1.25 производительности синьора.
justforword
19.05.2016 09:25+1Будучи на практике знакомым с php около 8 лет и имея за плечами большое кол-во своего кода, несколько крупных проектов, кучи оптимизаций, поиска багов, дыр и тд рутины в режиме фултайм загрузки — никуда не собираюсь устраиваться по этому направлению НЕСМОТРЯ на реальную нужду («в бизнесе случилось за руль такси сесть»).
И объясню почему: если опустить банальные личные потребности в уважении, то я считаю, IT-компании (большинство, исходя из текста вакансий) не дают ощущения «Ай молодца, так держать». Имею в виду те компании, которые вот также ищут программистов с какими-то своими размышлениями о профитах и прочем денежном. Только контроль, контроль, один контроль на этих лицах.
Такие предпочитают нанять милых девочек-рекрутеров и, простите, маркетолога-начальника с общими вопросами и нулем заинтересованности в деле. Возможно таких начальников и самих жизнь за щеки треплет, но им не место среди программистов.
Я к чему это написал. Если вам встречается Джуниор с маломальским опытом, который загорается от загадки эйнштейна про дома — это ценнейший актив, если вы этого не понимаете — то увы и ах. Если не можете найти ему подходящей работы — увы и ах. Если не можете организовать ему практику — увы и ах.
Увы и ах — это не он 0.01% работы выполняет за 30к, а это у вас нет достаточной компетенции для организации работы. Ищите верстальщиков, пусть они вам программы верстают, а вы их на 3d-принтере в виде 3d-открыток и в бухгалтерию.
Абсолютно все программисты были когда-то новичками, но только лучшие из нас — навсегда новички.
?>
Scf
19.05.2016 10:00Я считаю, что основная причина не нанимать джуниоров — это тот факт, что качество проекта получается как среднее арифметическое навыков всех его участников, несмотря на всё лидерство тимлида. Так что джунов берут:
- компании, ориентированные на минимальную стоимость в ущерб качеству — т.н. заказная разработка
- достаточно крупные компании, где всегда есть низкоквалифицированная работа без особых требований к качеству
- крупные компании, которые могут позволить себе отобрать многообещающих студентов, вырастить их и удержать их. У Яндекса и Дойчебанка, например, такие программы есть.
DeadKnight
19.05.2016 11:34+1Основная причина не нанимать джунов, это то, что далеко не все компании могут себе такое позволить.
Что я вижу вокруг, так это то, что джунов нанимают либо очень маленькие компании, у которых мало денег и несложные задачи, либо непрофильные компании, например отделения банков. Мидл или сеньор для них во-первых дорогой и во вторых он там на долго не задержится, потому, что ему будет неинтересно.
Также, джунов нанимают большие профильные компании, у которых достаточно большие команды работают над проектом и джуны для них достаточно выгодны. Во-первых, им можно поручать работу, которую не любят выполнять синьоры, они дешевы, ну и когда он учится, он вникает в специфику компании, и потом, даже если уйдет, то большая вероятность, что он вернется назад еще более заматерев.
А вот для средних компаний джуны могут быть в тягость. Да, им можно мало платить, но когда у тебя над проектом работает всего два человека, то валить всю работу на сеньора… знаете, ну он просто уйдет. Во-вторых, если джун толковый, то рано или поздно, ему просто станет скучно, и он уйдет. Вероятность возвращения его назад в стеднюю компанию довольно мала. И получается, что ты взял человека, обучил, и только он стал пригодным к работе — ты его потерял. А бестолковых джунов держать, смысла мало.
Вот и получается, что имеем то, что имеем.
P.S. Да и еще, у больших, профильных компаний, очень пользуется популярностью брать студентов, пока те еще учатся. Это выходит еще дешевле, и быстре толковые от бестолковых отсеиваются.
eldarmusin
19.05.2016 18:41+2— Вы не боитесь что вы обучите вашего работника и он от Вас уйдёт?
— Я больше боюсь что я его не обучу и он останется
iproger
20.05.2016 10:03Очень в тему статья. Достаточно посмотреть вакансии для NY. Одни синьеры и лиды нужны, даже мидлов редко встретишь, чего уж говорить про новичков.
habradante
За все то время что мне приходится нанимать людей, я выяснил для себя одну весьма важную вещь. Есть кодеры, а есть программисты. И те и другие нужны в команде. Различаю я их так: кодеры, это люди, которые хорошо знают язык, могут ориентироваться в коде, даже, применять какие-то паттерны и методики, а программисты — это люди, которых отличает системный подход к задаче, для них это не только набор классов, они понимают как их код впишется в общую архитектуру, зачем и для чего пишется документация. Программисты, в отличие от кодеров, могут разрабатывать архитектуру, для весьма крупных модулей и прогнозировать интеграцию этих модулей между собой.
Так вот, начинающие программисты, как правило это кодеры среднего (middle) уровня, т.е. это люди, которые могут решать задачи, а не кодировать «отправку мыла с сайта в несколько потоков». И если в начале все начинают с уровня джуниора кодера, то некоторые могут вырасти в программиста, а некоторые так и остаются кодерами. Повторюсь, кодеры тоже нужны, но вот решение крупных комплексных задач, мы будет не под силу, даже несмотря на то, что они могут знать несколько фреймворков и неплохо знать сам язык.
Поэтому я бы различал затраты на джуниора программиста и джуниора кодера. Вторых не очень любят, т.к. затраты на них не отбиваются, либо отбиваются очень долго. Просто различить их на начальном этапе не все могут.
MatrixFailure
Это точно. Джуны джунам рознь. Редко, но встречаются такие отвественные, проницательные, любопытные и понимающие потребности пользователей.
Они довольно быстро становятся ведущими, а затем и руководителями и часть из них потом открывают своё дело.
И вот сижу я и думаю: где бы мне найти и как опознать такого джуна для своей компании?
habradante
Я для выявления такого типа джунов предлагаю решить несложную задачку на псевдо-коде. И, глядя, как человек рассуждает в процессе ее решения можно судить в какую сторону больше склоняется. Задачка, естественно, должна быть на подумать, а не на знание вызубренных методов, классов и пр. Ну и плюс ворох различных вопросов.
Кстати, такие вот ответственные, проницательные и любопытные хуже решают задачи поддержки (исправление багов в имеющейся системе). Какое-то время они там роются, что-то улучшают, меняют, но, в конечном итоге, если задачи не усложняются, ответственность не растет, то интерес быстро гаснет. В то же время «кодеры» могут прекрасно справляться с повседневной рутиной, причем, зачастую даже лучше, если речь идет о поддержке.
MatrixFailure
Это да. Не все могут долго выносить рутину.
Проблема с кодером это то, что он зачастую не знает как сделать хорошо (для пользователя, для дальнейшего развития продукта, для бизнеса, да и просто для красоты).
sciomenihilscire
А как бы вы подошли к найму джуниора в свою компанию? Джуниоры с начальным знание какого языка вас интересуют?
maxru
Ещё бы научиться отличать джуниор программиста от ленивого джуниор программиста :)
А так-то в целом % попаданий по тестам с заданиями на мышление, а не специфику языка, достаточно высок.