Стоит ли брать на работу джуниоров

Ища работу, начинающие программисты обнаруживают, что молодым у нас дороги нет. Компании не охотно берут новичков на работу, и тому есть весьма веские причины:

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

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

— Им хочется использовать какую-то новую модную технологию. До определённого момента все программисты ищут серебряную пулю, пока с опытом не приходит осознание, что за всё, так или иначе, приходится платить.

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

— Они себя не окупают. Зарплата джуниоров всё равно довольно большая, и платить им меньше не стоит.

Это довольно серьёзные риски и траты для компании. Особенно остро они ощущаются в Украине и Беларуси, где компании в основном аутсорсинговые, а сотрудники для заказчика являются удалёнными. А это требует больше самостоятельности и профессионализма.

Тогда зачем компании нужны вчерашние студенты?

Тем не менее, мне было интересно исследовать, зачем крупные компании (даже такие высокотехнологичные, как Google) делают интернатуру и всё-таки берут на работу вчерашних студентов. Вариантов было много, но ключевой ответ я услышал в замечательном интервью с Евгением Кривошеевым, тренером из ScrumTrek.

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

Вот несколько причин, почему вам могут понадобится именно джуниоры, даже если бюджета хватает на нескольких синьоров:

1. Они мучают вопросами, и их нужно вводить в проект. И это хорошо! При этом у вас часто всплывают разные сложности системы, которые вы раньше и не замечали. Например, у вас проект собирается какими-то shell скриптами с помощью ANT’а, и, объясняя это джуниору, вы можете подумать: а почему бы это не переписать на Maven и собирать одной стандартной командой?

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

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

3. Им нужно много объяснять, как работает система. И это хорошо. Каждый раз отвечая на вопрос, стоит задуматься: а почему вам приходится это объяснять? Может быть, у вас нет документации? Вот и всплыла проблемка.

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

4. Они косячят. И это хорошо. Джун угробил базу, написав UPDATE без WHERE? А бекапы у вас были? Сразу же всплыла проблема, которую раньше не замечали, а ведь у вас может в любой момент винчестер полететь. Джун закоммитил какую-то ерунду? А у вас вообще построен процесс ревью? То-то же.

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

В том то и дело, что как только джун останавливается на каком-то направлении, он концентрируется только на нём и развивается в миддла. И только потом, уже вертикально развившись до синьора, у него появляется время и желание посмотреть по сторонам.

6. Они быстро учатся. Они как губки впитывают новые технологии. И да, они постоянно норовят их впихнуть в проект. В том числе те, которые синьоры пробовали в своей молодости, но тогда они оказались слишком сырыми или для них не было рынка, или они опережали время. Например, in-memory БД (e.g. Redis) во времена, когда 512mb RAM было шиком, или функциональные языки (e.g. Scala), которые стали востребованными только с массовым внедрением многоядерных процессоров. Эта способность схватывать быстрее чем старшие товарищи может быть незаменимой и хорошо дополнять общую компетенцию команды.
Нужно помнить, что со временем юношеский энтузиазм неизбежно разбивается об горький опыт сменяется рассудительностью и консерватизмом.

7. Их мозг ещё не загажен штампами. Это даёт возможность смотреть на проблемы свежим взглядом. Кроме того, опытные программисты склоны к оверинжинергингу, в то время как джуны могут написать более простой и прямолинейный код. Например, синьор вероятнее будет оптимизировать конкатенацию строк в цикле через StringBuffer, а джун напишет этот код в лоб — проще и читабельнее. И оказывается, что современные компиляторы уже давно сами делают эту оптимизацию.

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

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

9. Им интересно заниматься тем, чем более опытным коллегам уже не интересно. Например: сделать кнопку округлой и раскрасить с помощью CSS или сделать диалоговое окошко на JavaScript. А раз интересно, то и сделают они это, с большой вероятностью, лучше. Я знаю случай, когда джун сильно удивил команду матёрых синьоров, используя анимацию CSS 3, которой сам обучился, делая игрушку.

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

10. Неуёмная энергия. Джуниоры могут себе позволить овертаймы или потратить больше времени на изучение нового. У них нет семьи или денег на катание на сноубордах на выходных. Вообще, насколько я видел, большинство джуниоров, даже имеющих занятия кроме работы (семья, спорт, учёба, пьянки), всё равно с огромным энтузиазмом работают и выкладываются на полную. И некоторые к двадцати трём годам уже становятся вполне себе синьорами.

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

11. Неожиданно, но джуниоры могут знать технологию лучше синьоров. Джуниоры обучаются по самым последним книгам и с самыми последними версиями технологий. Например, пока бородатые синьоры повязли в индусском легаси на шестой джаве и пишут спринговые контексты на XML, а для работы с базой используют какой-нибудь MyBatis, в котором нужно SQL писать руками, то джуны уже вовсю используют восьмую джаву с лямбдами и новый Spring Boot, где бины создают аннотациями, а с базой работают через модный Spring Data, без единой строчки SQL. И, обменявшись опытом, вы можете обнаружить, что для Spring Boot уже есть модуль MyBatis, и можете попробовать его и получить глоток свежего воздуха.

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

Каждый раз, когда я менторил джунов, я всегда от них узнавал что-то новое. Один мне показал свой компилятор Brainfuck, написанный на JavaScript. Другой рассказывал про технологии BigData, которые он изучал на Coursera.

12. Околопрограммисткая специальность. Такие профессии, как специалист тех. поддержки, тестировщик-автоматизатор, DBA, Build Engineer, требуют знания программирования, чтобы, засучив рукава, полезть и исправить проблему. Опытные программисты предпочитают не идти на такие вакансии, но джуниоры вам могут отлично подойти. Возможно, они будут неплохо справляться и даже вырастут в синьоров по этому направлению. И таких опытных ценят даже больше, чем программистов, — из-за более узкой специализации.

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

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

14. Сын полка\Юнга — продолжение традиций, снисходительное отношение или, наоборот, дедовщина (да-да, такое тоже бывает!). Но, вообще говоря, передавать ремесло и воспитывать следующее поколение бойцов — это важно в долгосрочной перспективе. О таком обычно задумываются продуктовые компании, в которых знание продукта важнее, чем знание технологий.

Все компании несут потери на трудовом фронте: кто-то засиделся, и его выгонять пора, кто-то трактор завёл, кого-то в армию призвали, кто-то «ушёл на повышение», кто-то не выдержал корпоративной беготни в колесе и сдауншифтил на Гоа. Люди уходят. Но кто же придёт в замен? Как же наша, эта самая, корпоративная культура? И тогда вы решаете — мы будем воспитывать своего джуниора! Но тут возникает проблема: мы его как родного лелеяли, а он ушёл, неблагодарный. Тут возникает вопрос о лояльности.

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

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

Если у вас в компании всё в порядке с оплатой и поощрением заслуг, то, как правило, неблагодарные джуны уходят на другой проект просто за новыми приключениями. Каждого из нас точит вечное: «А, может, там интереснее?». У вас всё может быть отлично, но это следствие парадокса выбора — человеку всегда кажется, что он мог выбрать что-то получше. Это нормально, это и у синьоров бывает, просто меньше вызывает обиду.

Один джуниор, который год назад только устроился на хороший проект, недавно мне жаловался:
— Я тут уже всё изучил и вот чувствую, что ничему новому не учусь. Подумываю менять работу. Куда податься, не знаю. Что там сейчас в тренде?
— Boy, Boy! Придержи коня, ковбой. Не так и много таких хороших проектов. Ты бы на конференцию сходил, чё нового узнал, тренды те же. Услышишь про Continious Delivery, которого вам так не хватает — вот заодно попробуй пропихнуть в команде и внедрить. В общем, не спеши. Поверь, самое интересное с работой ты не пропустишь, если что.
— Спасибо, успокоил мю душу мятежную. Так и поступлю.
Вот так вот спас от опрометчивого увольнения.

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

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

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

Я считаю, что людей, способных к профессиональному программированию, не так уж и много. И те, кто поняли, что это их призвание, концентрируются в определённых точках, где они учатся друг у друга. Это объясняет, почему даже из глухих вузов, где учат чуть ли не дырочки не перфокартах делать, всё равно выходят матёрые профессионалы (которые на самом деле самоучки). Есть мнение, что гимназии с физико-математическим уклоном хорошо подготавливают программистов. Мне кажется, что здесь связь обратная — это не гимназии готовят программистов, а потенциальные программисты концентрируются в них и спокойно выживают, когда балбесов оттуда выгоняют.

Тут же кроется ответ, почему крупные компании бегают за студентами-инженерами. Если ученик может в Matlab расписать передаточную функцию, то, скорее всего, выучить программирование ему тоже не составит труда. И учитывая дефицит таких людей, они будут стараться заинтересовать выпускников именно своей компанией и готовы нести расходы на их обучение. Поэтому при устройстве на работу они даже глянут в диплом: хорошие оценки — это всё-таки кумулятивный показатель качеств как специалиста. Либо студент достаточно умён, либо достаточно прилежен. И то, и другое что-то скажет о потенциале будущего сотрудника.

16. Мотивация для нас, старичков. Это очень тебя мотивирует, когда ты уже закостенелый девелопер, и тут приходит какой-то сопляк, который схватывает всё на лету. Чувствуешь, что молодые наступают на пятки. А ещё и нахваливают какое-то модное реактивное программирование. Ты, конечно, делаешь скептическое лицо: «эх, молодость зелена». Но вечером приходишь домой, ужинаешь, задумываешься на минутку... А потом бьёшь кулаком по столу «Щенок!», да и записываешься на курс.

Хорошим джуном кашу не испортишь

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

Я пришёл к выводу, что джуниор — это прекрасный кандидат на роль «новичок на проекте». Так или иначе, все мы, приходя на новый проект, оказываемся в той же ситуации, что и джуниор. Большинство этих ситуаций точно также могут случаться и с миддлом, и с синьором.

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

Если у вас налажен процесс на проекте, то интегрирование нового игрока в команду проходит безболезненно. А если процесс не налажен, то, возможно, как раз джуниор и поможет увидеть и исправить множество проблем. Более того, сама возможность добавить джуна в проект — это довольная важная метрика. Если у вас нет работы для джуниора, есть повод задуматься — а всё ли у вас в порядке? Почему только синьор может с этим хозяйством разобраться? Возможно, у вас очень устаревший стек технологий, который уже никто и не учит. А значит, дальше вам будет только сложнее искать сотрудников. А возможно, вашу систему следовало бы разделить на более простые модули.

Главное нужно признать — они также нужны на проекте, как и опытные программисты. Пока джуниоры будут с интересом ковырять какой-нибудь новый фреймворк, более опытные будут сосредотачиваться на предметной области и архитектуре. Таким образом, коллеги дополняют друг друга.

Так что, дорогие работодатели, помните народную мудрость:
Молодым — везде у нас дорога.
Старикам — везде у нас почёт.

А вы, джуниоры, не падайте духом и помните, что дорогу осилит идущий ;-)