Плохая стратегия: брать только опытных разработчиков

Вольный перевод оригинальной публикации Anton Zaides, под каждым словом которого лично я готов подписаться (в т.ч. и как человек, у которого прямо сейчас на проектах 2 практиканта и один стажер).

У каждой компании свои оправдания:

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

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

В крупных компаниях — «у нас сложная инфраструктура, новичкам потребуется много времени, чтобы освоиться».

Это все чушь.

И я не говорю здесь о возрасте. Есть 25-летние старшие сотрудники, и есть 40-летние новички, которые сменили сферу деятельности.

Разработка программного обеспечения - это не полеты в космос

Некоторые разработчики становятся сеньорами менее чем за 3 года, некоторые даже без профильного образования. Если вы мне не верите, почитайте истории Джордана Катлера, Тайгера Аброди и Райана Питермана.

Я не говорю, что через 3 года они будут знать все — но они будут результативны и смогут решать большинство проблем корректно.

Как и со всем в жизни, могут случаться откаты. Вы будете становиться лучше со временем, но темп вашего роста замедлится. Вы можете различить разработчика с годом опыта и того, у больше 5 лет, но между теми, у кого 10 и 15 лет разницы? Вероятно, не сможете.

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

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

Неопытные разработчики могут добиться великих успехов:

  • Эван Спигель и Бобби Мёрфи основали Snapchat в 2011 году, когда им было 21 и 23 года, они были студентами.
  • Цукербергу было 20 лет, когда он начал Facebook.
  • Дрю Хьюстон был студентом в 24 года, когда основал Dropbox.
  • Ларри Пейдж и Сергей Брин разработали первую версию Google в 24 года, также будучи студентами.
  • Билл Гейтс основал Microsoft в 20 лет (а Джобс был всего на год старше, когда начал Apple).

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

Но вот в чем дело — амбиция, характер и ум имеют мало отношения к опыту.

Почему стоит нанять младшего разработчика на следующую открытую позицию

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

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

5 причин, почему найм отличного младшего - правильная ставка для вас:

  • У вас больше кандидатов, и вы можете получить лучших. Когда вы ищете full-stack разработчика с опытом работы от 5 лет на Python и от 3 лет на React, у вас будет меньше вариантов, и в конечном итоге вы вынуждены будете пойти на компромисс.
  • Джуны приносят свежую энергию в команду — им хочется учиться, и у них есть стремление доказать себя и добиться успеха. Их мотивация может быть заразительной!
  • Опытные члены вашей команды будут рады работать с умными и мотивированными разработчиками. Это даст им возможность наставлять и обучать, чего им может не хватать, если в команде только сеньоры.
  • Джуны не ограничены тем, что знают — они не будут пытаться повторно использовать технологии из предыдущих компаний или воссоздавать те «клёвые» шаблоны проектирования, которые были полезны только в конкретном контексте.
  • Джуны более открыты к работе с новыми технологиями и менее придирчивы к задачам, которые им нужно выполнять. Это не значит, что их нужно заставлять исправлять неприятные ошибки весь день, но это дает вам больше гибкости в команде.
  • Хорошие джуны быстро учатся и ищут обратную связь, поэтому ими легче руководить. Они хотят расти и хотят знать, что вы думаете о их работе.

И самая большая причина:

У джунов есть стажировки и студенческие позиции

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

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

Идеальное сочетание

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

Но для большинства команд, работающих над SaaS-продуктом, соотношение джунов/сеньоров может быть довольно высоким. В то время как джунам нужен кто-то, от кого можно учиться, многие из них не требуют много времени и внимания в формате 1:1. Вот замечательная аналогия, которая мне нравится:

Представьте свою команду не как озеро, а как реку. Озеро застаивается. В нем нет энергии или побуждения к изменениям. То же самое верно и для групп, которые застаиваются. Они выращивают посредственность и удовлетворенность; они не любят риск. Река всегда текущая и меняющаяся с множеством потрясающей энергии. Вы хотите реку.
Река зависит от потока воды, и ваша команда зависит от потока людей и информации. Вы можете представить людей разделенными на три группы: новая кровь, новые лидеры и старейшины, готовые к новому вызову. Вот как эти группы должны сбалансироваться и течь:
→ Самая большая группа должна быть новой кровью.
→ Для течения вы хотите стабильный поток новой крови, становящейся вашими новыми лидерами, и новых лидеров, становящихся старейшинами.
→ Ключ к потоку — в поступлении новой крови и уходе старейшин. Чтобы это работало, вы хотите, чтобы ваши старейшины переходили, прежде чем они забьют поток и нарушат поток возможностей для других. Если вы вообще не нанимаете младших, ваша команда застаивается.

Около года в моей команде было 2 сеньора и 3 джуном. Полгода назад, мы вместе с моим ведущим разработчиком-девушкой решили, что для нее пришло время перейти в другую команду, где она могла бы расти лучше (я возглавляю команду full-stack, а ей хотелось глубоко погрузиться во фронтенд).

При этом, мы выжили и до сих пор продуктивны.

Джун не означает эксплуатацию

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

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

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

Anton Zaides (перевод: Павел Федотов)

Комментарии 2

Авторизуйтесь чтобы оставить комментарий

Спасибо большое за полезную информацию! Да полностью согласен, иногда джунов очень выгодно брать если вы собираете лояльную команду на long-term! Банально отсеивая слабых, оставляя лучших, вы соберете себе в перспективе сильный коллектив!

Ответить

Мне кажется, что работать с молодыми — это еще и перспективно. Где-то же они должны расти?!

Ответить