Всем привет! Меня зовут Иван Сёмин, я руковожу несколькими командами разработки в компании Домклик. На данный момент в моём подчинении 28 человек, часть из которых приходила на junior-позицию. Хочу поделиться своим видением погружения новых сотрудников в процессы компании и коллектив, и рассказать о способах развития разработчиков до middle-уровня в крупных командах.

Кто такой junior

Разберём на примере junior в Python-разработке. Разработчик может претендовать на junior-позицию, если он хорошо знает основы Python: базовый синтаксис, типы данных, области видимости, ООП, а также умеет писать модульные-тесты. Если же какие-то из этих требований не выполняются, но есть базовые навыки программирования, то кандидат может претендовать на позицию стажёра с быстрым ростом до джуна.

Для веб-программирования хочется увидеть у кандидата знание асинхронного программирования (и чем оно отличается от синхронного) и основ SQL. Также из-за специфики развёртывания веб-сервисов нужны хотя бы базовые навыки обращения с Linux-системами и знание Docker/Docker-compose.

Большим плюсом для работодателя будет наличие портфолио из pet-проектов на github (разработанных с нуля, а не выполненных в рамках какого-то курса под диктовку лектора).

Специфика нашей компании и команд

В нашей компании сложилась хорошая культура разработки, всегда работает принцип «попроси — и тебе помогут». Благодаря этому новички быстрее адаптируются, а многие сотрудники работают на одном месте дольше стандартных для рынка двух-трёх лет. Компания заинтересована в разнопланово развитых инженерах: кроме основного навыка (backend/frontend) от сотрудника ожидают развитие навыков DevOPs (чтобы понимать, как код попадает в тестовые и production-среды) и баз данных (потому что ряд сервисов работает под высокой нагрузкой и нужно представлять себе дальнейшие оптимизации). Плюсом будет изучение (хотя бы на базовом уровне) frontend-а в дополнение к backend-у (или наоборот) — это позволит лучше понимать своих коллег на «другой» стороне разработки, а также даст возможность закрывать ряд задач бизнеса «под ключ».

Перейдём к этапам погружения.

Этап первый

В свой первый рабочий день разработчик подписывает документы в HR, получает технику (мы используем Macbook Pro) и проходит базовый onboarding со своим руководителем. Во время адаптации мы кратко рассказываем о процессах в компании, о техническом инструментарии, корпоративном портале. Дальше идёт погружение в бизнес-часть выбранной разработчиком команды. Также очень важно, чтобы в свой первый рабочий день новый сотрудник познакомился со своей командой и получил первую задачу, с которой начнётся его техническое погружение в проект. Наставник новичка (опытный сотрудник из команды, который будет отвечать на все технические вопросы во время испытательного срока) поможет локально поднять проект, подключиться к тестовым стендам и базам.

Этап второй

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

Этап третий

Примерно в середине испытательного срока нового сотрудника знакомят со всеми обязанностями релиз-инженера (эту роль может исполнять любой разработчик из команды, на неё назначают при планировании нового спринта). Первые самостоятельные релизы проходят под чутким контролем наставника. Также в ряде команд есть ротируемая роль support-инженера: это разработчик, который решает все появляющиеся в течение дня тикеты от пользователей. Большинство тикетов будет сложно разобрать самостоятельно (если инженер не знаком с этой частью системы), поэтому наставник подскажет, к кому обратиться за помощью. Благодаря этому подходу хорошо получается делиться знаниями и взаимодействовать со всеми членами команды.

Этап четвёртый

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

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

Заключение

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