Привет! Мы работаем в Константе и занимаемся разработкой различных сервисов и систем, связанных с беттингом. Один из наших продуктов – платежный шлюз, он интегрируется с платежными системами и позволяет клиентам букмекера вносить и выводить деньги из личного кабинета.
Это довольно молодой продукт – костяк команды формировался в течение последнего года. В какой-то момент мы подумали о том, что у нас есть ряд типовых интеграционных задач, на которых мы могли бы вырастить начинающих Golang-разработчиков. С одной стороны, стажировки – популярная сейчас история, и на рынке существует множество предложений, с которыми нам предстояло конкурировать за таланты; к тому же мы, как небольшая компания, не могли позволить себе выделить на этот проект большой бюджет и много человеческого ресурса. С другой стороны – нам очень хотелось попробовать.
Спойлер: в итоге стажировка была организована силами 2 HR и 3 человек из команды разработки. Помимо оплаты нашего времени и выплат стажерам, не было потрачено ни рубля дополнительно.
О чем стоит подумать, готовясь к стажировке:
Ресурсное планирование
Для небольшой команды может стать проблемой проведение стажировки, поскольку какое-то время ваши разработчики будут наполовину разработчиками и наполовину – менторами. В нашем случае за четырьмя стажерами были закреплены два старших специалиста. На время обучения стажеров объем выполняемых задач у них снизился примерно в два раза.
Есть разные способы сгладить просадку в период обучения новичков. Например, заранее обсудить с разработчиками возможность овертаймов. Или же подойти к этому с другой стороны и договориться с бизнесом о том, что в период обучения стажеров произойдет просадка в поставке, но это даст хороший профит в долгосрочной перспективе.
Оптимальное количество стажеров
Исходя из потребности в найме 1-2 человек в команду, на стажировку решили пригласить четырех ребят (в итоге они оказались слишком хороши, и мы оставили всех).
Как мы проводили набор
Время и деньги на полноценный лендинг в нашем эксперименте мы решили не тратить, поэтому в качестве посадочной страницы использовали минимально оформленную страничку в notion.
Перед началом стажировки мы ответили себе на несколько вопросов:
1. Кого бы мы хотели видеть в роли стажеров
Нам надо было учесть, сколько времени разработчики смогут выделить на обучение. Прикинув наши возможности, мы пришли к критерию о наличии какого-либо опыта разработки – совсем нулевых ребят мы бы не потянули.
Для нас важна возможность работать фуллтайм после завершения стажировки, поэтому фокус был на выпускников либо магистрантов последних курсов.
Нам хотелось найти ребят на долгосрочное сотрудничество, поэтому мы обращали внимание на теоретическое знание Golang, чтобы наши стажеры представляли, с чем они будут работать, и у них не возникло “разочарования” в технологии уже в процессе работы.
2. Где обитают такие ребята
Понимая, что наша целевая аудитория это те, кто ищет полную занятость в конечном итоге, мы отказались от взаимодействия с классическими студенческими сообществами (хотя в паре групп техвузов в соц.сетях разместились для проверки гипотезы, но они ожидаемо не дали существенного выхлопа); основными нашими источниками стали телеграм-каналы по Golang и старый-добрый headhunter.
3. Как мы будем обрабатывать заявки и проводить первичный отбор
Для сбора заявок мы сделали простейшую гуглформу, в которой были вопросы о соответствии вышеописанному профилю: наличие опыта разработки, возможность работать фуллтайм после стажировки, знание Golang.
Для проверки корректности заполнения формы мы добавили короткий (буквально на 5-10 минут) звонок с HR для обсуждения того, что кандидат написал о себе в форме.
Ключевое значение в первичном отборе было у результатов тестового задания.
4. Как мы будем принимать решение о приглашении на стажировку
Все, кто соответствовал изначальным критериям, получили тестовое задание (подробности о его создании ниже). Проверив с десяток тестовых, мы эмпирическим путем пришли к минимальному проходному баллу, и кандидаты, достигшие его, получили приглашение на техническое интервью.
Техническое интервью было структурировано таким образом, чтобы его могли проводить разные разработчики, оно содержало одинаковые вопросы, и мы могли сравнить кандидатов друг с другом. Ребята, показавшие лучшие результаты в выполнении тестового и прохождении технического интервью, получили приглашение на стажировку.
5. Как мы будем принимать решение о приглашении на работу по итогам стажировки.
Для нас было важно видеть динамику, стажировка длилась 2 месяца, и мы обращали внимание на прогресс, который показывали ребята. На протяжении стажировки HR регулярно собирали обратную связь от команды по стажерам, а в середине с ребятами проводились встречи для обмена фидбеком и внесения корректировок.
Итоги отбора:
180 входящих откликов - 52 HR интервью - 33 тестовых задания выдано - 9 технических интервью - 4 стажера - 4 найма
На подготовку к старту сбора заявок ушла 1 рабочая неделя - с 23 по 27 мая.
30 мая были опубликованы страничка в notion и объявления о стажировке в каналах, начался прием и обработка заявок, выдавались первые тестовые. С 15 июня мы начали проводить технические собеседования, 24 июня определились с финалистами, и уже 28 июня был первый стажировочный день. Таким образом, на весь процесс подготовки и отбора ушло чуть больше месяца.
Тестовое задание
В момент, когда нужно было готовить тестовое задание, нашему лиду пришла идея: раз мы ищем потенциальных разработчиков для задач, связанных с нашим платежным проектом, так почему бы не дать им задание написать свой платежный сервис в миниатюре?
В тестовом задании он расписал, какие предполагаются методы в API, какие бывают переходы между статусами транзакций, и попросил кандидатов предусмотреть особый эндпоинт для приема запросов со стороны внешних платежных провайдеров для обновления статуса транзакций. Способ авторизации оставил на усмотрение кандидата: главное, чтобы она была.
Выполненные тестовые задания мы попросили кандидатов выкладывать в GitHub в открытом доступе. Для кандидата оно является частью его портфолио, которое он вправе показывать и другим потенциальным работодателям в качестве примера кода. После выполнения задания кандидат просто закидывает нам ссылку на репозиторий, а дальше мы смотрим, как оно сделано, скачиваем его, пробуем собрать и запустить.
Чтобы не оценивать выполнение тестовых заданий по настроению и проще сравнивать результаты друг с другом, мы сделали критерии оценки:
Результаты запуска сервиса (запускается/не запускается), все ли запросы работают в соответствии с ТЗ.
Наличие комментариев, readme, описания примеров запросов.
Навыки работы с HTTP в Go и базами данных.
Наличие докерфайла для запуска сервиса.
Наличие тестов, качество тестов.
Общее качество кода (структурирование кода, использование простейших методов проектирование).
Аккуратность (отсутствие грамматических ошибок, нормальное именование переменных, отсутствие магических чисел и строк).
Плюс, добавляли еще и развернутую связь по каждому тестовому. Единственная проблема здесь – затрачиваемое на проверку время, в отдельных случаях оно доходило до 40 минут. Так, конечно, быть не должно, и в следующих стажировках мы это учли.
Собеседования
Стажеров мы собеседовали в сокращенном варианте: не было традиционной вступительной секции «расскажи о своем предыдущем опыте», а также часть более сложных технических блоков была опущена. Вопросы были по основам языка Go, по базовым алгоритмам и совсем немного по базам данных, если оставалось время. В качестве некоего подобия чек-листа в секции по языку Go наш тимлид у себя перед глазами держал открытой вкладку с главной страницей сайта GoByExample.
Онбординг
В целом, онбординг для стажеров практически не отличался от обычного онбординга для джунов - за исключением одного маленького нюанса. При погружении стажеров чуть больший акцент делался на базовых инструментах, таких как Jira, Slack и т. п., так как некоторые из них оказались для ребят совсем новыми.
После выполнения первых задачек по проекту ребята активно начали общаться не только с кураторами-разработчиками, но и с остальными участниками команды: тестировщиками и аналитиком. То есть уже в это время началась полная интеграция ребят в команду.
Начало стажировки и провал идеи с оторванными от проекта задачами
Изначально была мысль придумать стажерам задачи, не относящиеся напрямую к нашему проекту, дабы они ничего там у нас не поломали. В идеале, чтобы ребята сделали нам какие-нибудь полезные библиотечные функции, которые, может быть, мы в будущем засунули бы в основной проект, но это не обязательно. И вот пошли всякие идеи, вроде «сделать обертку над логгером», «сделать обертку над time.Time» и прочие. Хотя пара интересных вещей тоже была.
Придуманные задачи мы отдали стажерам в их первый рабочий день. «На первые две-три недели им хватит работы», – подумали мы. Прошло 2 дня. Задачи готовы, отданы на ревью, надо дать им что-то еще. Мы не предполагали, что они справятся с ними настолько быстро. (Спойлер: ни один из разработанных пакетов не используется в нашем проекте до сих пор, и вряд ли будет использоваться.) В итоге мы потратили время стажеров на разработку бесполезных пакетов, потратили наше время на ревью и время лида на придумывание задач.
Из плюсов, наверное, немного подтянули ребят по качеству кода. По крайней мере, те же замечания при код-ревью начали встречаться реже.
Для себя мы сделали вывод, что стажировка должна начинаться с настройки рабочего окружения под проект, с чтения нашей документации, с попытки подебажить ручками наш сервис. Поскольку мы проверяли их навыки с помощью тестовых заданий и собеседования, то на этом этапе уже должно быть понятно, что ребята и тестировать код умеют, и адекватно читать условия задач способны, и клавиатуру как минимум в руках держали. Если уж так страшно давать им доступ к коду проекта, можно в первые дни дать поправить свое тестовое задание, исправить замечания ревьюера.
Боевые задачи
Критерии выбора “реальных” задач:
Выполнимые. Избегали исследовательских задач. В задаче были описаны явные критерии завершения.
Не затрагивают систему целиком. Доработки затрагивают какое-то одно место в системе, очень узкий функционал.
Простые. Просто разобраться и воспроизвести проблему. Легко отладить доработки.
В работу стажерам уходили задачи из нематериального класса обслуживания (intangible). Это задачи с низкой стоимостью задержки, которые допускают длительное время выполнения, но при этом, если задачам из этого класса совсем не уделять внимания, в какой-то момент они могут стать критичными. В нашем случае это были небольшие технические и бизнесовые задачки.
На этапе распределения первых задач для стажеров неоценима помощь разработчиков, которые помогают стажерам с техническим погружением в проект. Они могут посоветовать или даже на первые несколько недель взять на себя распределение задач между новоиспеченными коллегами.
Как оценивать стажеров
Спустя несколько недель работы над “настоящими” задачками, стало понятно, что стажеры практически не отличаются от джунов. Поскольку за полтора месяца до начала стажировки к нам присоединился джуниор-разработчик, в голове были свежие воспоминания о его вхождении в работу, поэтому формирование картинки о том, насколько хороши стажеры или наоборот, происходило очень быстро.
Мотивация
Нельзя не отметить интерес и желание стажеров поскорее разобраться в проекте и влиться в процессы. Гибкость и свежий взгляд позволяют быстро адаптироваться и встроиться в культуру команды и компании. Все эти факторы способствуют тому, что ребята буквально растут на глазах.
Наставничество
Основным фактором успеха нашей стажировки мы бы выделили вовлеченность со стороны старших разработчиков.
При принятии решения о том, кто из текущей команды разработки будет привлекаться к стажировке, лучше ориентироваться на заинтересованность со стороны ребят.
То есть не по принципу: “у нас есть сеньор – пусть он возьмет на себя трех стажеров”, а именно с позиции заинтересованности. Можно задать прямой вопрос всей команде о том, кому было бы интересно поучаствовать в организации стажировки. Те, кто неравнодушен, принесут намного больше пользы, чем самостоятельно назначенные разработчики.
Помимо пользы в организации, у наставников появится хорошая возможность прокачать свои коммуникативные навыки и почувствовать себя в роли минилидов.
Подготовка к офферам
Важно, чтобы к экватору стажировки у тимлида/проджекта сложилось понимание, кто из ребят останется в команде, чтобы начать поиск в смежные подразделения немного заранее. Например, в случае стажировки в команду разработки - дополнительно нанять аналитиков и qa. С учетом того, что поиск подходящих соискателей может затянуться, не стоит откладывать открытие вакансии позже середины стажировки.
Выводы
В нашем случае стажеры начали приносить пользу сразу же, как только начали работать над проектными задачами. Во-первых, некоторые простые задачи можно было со спокойствием отдать стажерам, в то время как разработчики-старички могли заняться более сложными. Во-вторых, на нашем проекте наконец-то появилось обязательное код-ревью, которое проводится до сих пор для всех-всех разработчиков. (Да, раньше особого код ревью не было, до него не доходили руки)
Сейчас, после окончания стажировки, бывшие стажеры стали полноценными разработчиками, которым можно доверять разные задачи на проекте. +4 новых разработчика за 2 месяца стоили всех усилий.
Важные моменты:
Не растягивать онбординг и не давать выдуманные задачи.
При знакомстве стажеров с проектом отдельное внимание уделить новым инструментам.
Привлекать к стажировке заинтересованных в этом разработчиков.
Заранее начать найм QA и аналитиков, чтобы избежать bottleneck по окончании стажировки.
Бонус-история тимлида: Плагиатор
Просматривая очередное выполненное тестовое, я вдруг испытываю дежа-вю. Ошибки, названия функций и структур, пакетов, – всё это я где-то уже видел буквально вчера. Начинаю пролистывать недавно просмотренные проекты – и что я вижу – да мы тут имеем дело с плагиатом! Два абсолютно одинаковых проекта, один копия другого, сданы с разницей в несколько дней. Надо выяснять, кто у кого списал, а также – осознанно ли автор оригинального проекта дал списать другому? От этого зависит то, кто из двух кандидатов пройдет дальше, а с кем мы попрощаемся. Или, может, даже придётся попрощаться с обоими. За дело берется Детектив Коломбо.
Глянув на коммиты одного и другого репозитория, я сразу понял, кто у кого. Первый репозиторий был сдан на 3 дня раньше, в нём много коммитов, видно, как автор работал над проектом. Во втором репозитории, который был сдан позже первого, всего один коммит с названием «Upload files». Итак, плагиатор найден. Осталось выяснить, знаком ли плагиатор с автором оригинального кода. Написали мы в Телеграме плагиатору по этому поводу, а он возьми да и признайся во всём, вообще без каких-либо возражений. Говорит, нашёл готовый проект на Гитхабе, с автором не знаком, да и вообще, у автора много свободного времени, а у него – семья, дети, работа, чего пристали? Что ж, за навыки поиска по Гитхабу поставили ему 5, а за тестовое задание – твёрдый и уверенный неуд.