Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-03-10

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

2 Надо отметить, что эту тему не раз поднимали на Хабре, так что я настоятельно рекомендую ознакомиться с мнениями других специалистов: 1.<a>Если вы не нанимаете джунов, то не заслуживаете сеньоров</a>. 2.<a>Воспитываем Джуниора</a>.

3 <h2>Проблематика</h2>

4 В чём же постановка задачи в найме Junior-разработчиков? Рассмотрим типичные проблемы найма:

5 Опытного программиста можно искать довольно долгоДавайте честно: подавляющее большинство компаний далеки от понятия "работа мечты" (везде есть набор минусов). Да и не везде кандидату могут сделать предложение, от которого он не сможет отказаться. Как правило, приходится решать задачу поиска оптимального 3-стороннего сочетания между требованиями, бюджетом и специалистами на рынке. Очевидно, что поиск может затянуться. Да и мало найти специалиста -его ещё нужно удержать. Ни для кого не секрет, что толковые программисты выбирают работу, а не наоборот. Поэтому придётся конкурировать. Всё это приводит к тому, что иногда найм растягивается до 6-12 месяцев.А за это время джун спокойно себе вырастает до хорошего middle-специалиста!

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

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

8 <h2>Каковы плюсы?</h2>

9 Конечно же, найм джуниоров - это не панацея для перечисленных проблем. Для их решения потребуется комплексный подход. Однако найм младших разработчиков может помочь в снятии остроты проблемы.Это не означает, что надо, сломя голову, нанимать всех. К работе с младшими программистами нужно быть подготовленными, чтобы действительно получить от этого пользу. Какую именно? Сейчас перечислим:

10 Джуниоров многоРынок переполнен ими: вчерашние студенты, "самоучки", выпускники курсов. Выбор действительно огромен. И можно отыскать толковых людей, готовых к быстрому росту и развитию.

11 Джуниоры стоят совсем недорогоНа этапе найма младший разработчик обойдётся Вам в 1,5-2 раза дешевле того же middle-специалиста. И это поможет получить резерв в бюджете команды, который ещё точно пригодится.

12 Джуниора можно нанять быстрее, потому что см. пункт 1Только оставляйте время в своём графике для многочисленных интервью.

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

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

15 <h2>Итак, вы решили нанимать Junior-разработчиков…</h2>

16 <h3>1. Знакомство с продуктом</h3>

17 Готовьтесь к этому заранее. Вы не сможете работать с ним "по бразильской системе", тупо бросив в код. Он не сможет самостоятельно разобраться с кодом, понять тонкости архитектуры, да и просто собрать себе окружение. Первым шагом здесь часто устраивают практику "живых тренингов", когда опытный разработчик садится вместе с джуном и объясняет ему, что и как устроено. Довольно быстро на поверхность всплывают минусы данного подхода. Во-первых, это требует довольно много времени, так как объём вводной информации довольно большой. Во-вторых, энергии нужно больше, так как опыта у джуна меньше - он потребует объяснений каких-то элементарных на взгляд опытного программиста процессов. В итоге сессии объяснений случаются всё реже, а джун отправляется в свободное плавание до первого косяка, удаляющего данные с прода. Не надо так делать :-)

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

19 1) выделите процессы и знания, которые потребуются джуниору в первые 1-2 месяца работы. Это такие вещи, как получение рабочей среды, введение в используемую кодовую базу (как работает загрузка классов, сборка проекта, внедрение зависимостей и т. п.);

20 2) опишите эти вещи в wiki. Например, в виде чек-листов или схем. Скорее всего, поначалу это будет даваться тяжело, но с каждой новой итерацией найма вы сможете собирать фидбэк и оттачивать документы;

21 3) внедрите недостающие процессы автоматизации. Звучит громко, но ведь автоматизировать сборку виртуальной машины довольно легко. Вы потратите на это считанные часы, которые потом с лихвой будут экономиться на старте работы;

22 4) опишите п. 3 в документации.

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

24 <h3>2. Прокачка персонажа</h3>

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

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

27 В сторону джуниора же должен быть направлен план развития. Он может быть нестандартным - отталкиваться от конкретного сотрудника.Но нужно показать условия игрыи обозначить, при каких условиях джуниор может рассчитывать на рост. Не надо писать здесь что-то в духе "участие в проектах" или "количество закрытых задач". Метрики здесь будут сложнее. В проекте можно поучаствовать, спустя рукава, а задачи можно закрывать пачками, но не принося ценности продукту.

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

29 <h2>3. Кнуты и пряники</h2>

30 ОК, джуниор начинает брать первые таски, и через какое-то время первые из них доедут до состояния готовности. Здесь важен качественныйcode review. Причём чем больше правил написания кода у вас в команде формализовано, тем лучше. Дело в том, что джуниоры могут и будут воспринимать критику слишком резко. Очень часто они либо прут в агрессию ("да всё тут нормально в коде, чё придираешься?!"), либо думают, что их сейчас уволят ("я перенёс строку не там - мне конец!"). Всё это от того, что джуниор ещё не чувствует себя уверенно и не понимает допустимости определенного уровня проблем. Более того, они ещё не понимают всей пользы критики, не умея обращать её в пользу для себя.

31 Из этого отнюдь не следует факт того, что с джуниора надо сдувать пылинки. Но критику надо делать максимально конструктивной, убирая резкие вещи, привычные в команде сильных программистов (вы ведь тоже жестите "шутками за 300?"). В обосновании своей позиции вам поспособствуют не только опыт и выдержка, но и ссылка на документацию и общепринятые практики. Это поможет и джуниору увидеть, что по установленным правилам играет вся команда, а не только новобранцы. Разумеется, из этого следует равнозначная критика кода на ревью как опытных разработчиков, так и джуниров, чтобы не вышло ситуации с кодом, который отклонили у джуниора, но приняли, скажем, у миддла.

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

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

34 При всей выгоде найма Junior-разработчиков нужно помнить о том, что кто-то всё таки должен следить за их работой и ростом. Поэтому плохим решением будет собрать команду целиком из джуниоров, навесив их на одного опытного специалиста. Всё закончится плачевно даже для проекта средней руки. По моему опыту соотношение может быть таким:1-2 джуниора на 1 миддла-сеньора. Больше будет хуже, так как у старшего специалиста не будет хватать времени, а контроль будет рассеиваться.

35 Многие начинающие разработчики молоды, а это вполне может привести к их непониманию графика работы в компании. Они могут опаздывать, а порой и не являться на работу по каким-то совершенно сумасбродным причинам, оставаясь при этом всё теми же подающими надежды в профессиональном плане людьми. Стоит ли сразу расставаться с ними? Однозначно нет. Для начала ответьте себе честно на вопрос: "А зачем вам график работы?". Неверным ответом будет: "Чтобы следить за сотрудниками".График работы должен обеспечивать предсказуемость. Таким образом, если у вас в работе внедрён Scrum, то ежедневные стендапы должны случаться утром в одно и то же время. И опоздание будет говорить о неуважении рабочего времени команды. И это уже более весомый аргумент, к которому можно обращаться в спорах - он имеет прямое влияние на продуктивность работы в отличие от опоздания на 15 минут.

36 <h2>TL;DR или "Почему вам не нужны Junior-разработчики"</h2>

37 <ol><li>Джунов надо готовить. Нужно иметь чёткий лист прохождения, хотя бы на первый месяц. Вам не нужны Junior-ы, если вы не можете формализовать базовые процессы. Нужно не врать себе и чётко знать, как будет расти джун, как будет градироваться его зарплата в зависимости от скилов.Вам не нужны Junior-ы, если вы не знаете, как будете их растить.</li>

38 <li>Джуны не понимают график. А зачем вам график? Вам не нужны Junior-ы, если вы не знаете, зачем он вам.</li>

39 <li>За джуном надо правильно следить (в хорошем смысле этого слова).Вам не нужны Junior-ы, если курировать их работу некому.</li>

40 <li>Джуны плохо переносят критику. Будьте аккуратны.Вам не нужны Junior-ы, если вы сторонник дедовщины.</li>

41 </ol>