Нанимать джунов — это настоящая pain in ass. Откликов приходит больше ста в неделю, а кандидаты отличаются по уровню: одни только вчера окончили курсы, другие — почти мидлы. Пока разберем все отклики, проверим тестовые, проведем собеседования — проходит полтора месяца. А потом найденный сотрудник не проходит испытательный, и все повторяется снова.

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

Об авторе

Меня зовут Глеб Ковалев, я ведущий frontend-разработчик в Mindbox. Пару лет назад я начал проводить стажировки для frontend-разработчиков. А сейчас начинающих фронтов мы нанимаем преимущественно через стажировки. О том, как это происходит, расскажу в этой статье.

Почему стажировки, а не найм «с холода»

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

Меньше ресурсов на отбор

Кампания по найму джуна с рынка обычно длится 6 недель. Набор на стажировку занимает 3 недели. То есть каждый нанятый стажер «стоит» для нас вдвое меньше, чем джун «с холода». 

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

Обычно из всего массива откликов мы выбираем трех стажеров. Конверсия в найм и прохождение испытательного — 75%, то есть до конца стажировки доходят двое стажеров из трех. Это позволяет смягчать отбор на входе: все, кто не подходят нам, «отсеются» за время стажировки. Но если мы берем джуна с рынка, права на ошибку нет: нужно нанять человека, который с высокой вероятностью встроится в команду. Поэтому и отбор жестче и дольше. 

Обучение трех стажеров равносильно онбордингу одного джуна

Математика следующая: стажер работает полдня, три стажера — 60 часов в неделю. Джун работает полный день — 40 часов в неделю. И да, разработчик тратит на кураторство примерно столько же времени. Почему?

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

Но больше трех стажеров — для сеньора уже тяжеловато, начинают страдать основные задачи и обратная связь. 

Вероятность, что стажер останется в компании, больше

За время стажировки сотрудники «притираются» к команде, начинают ориентироваться в процессах и культуре компании. Если такие ребята остаются работать, то с большой вероятностью задерживаются надолго.

Для пруфа — статистика Mindbox за 2023–2024 годы:

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

То есть, когда мы нанимаем стажеров, мы не только экономим ресурсы на отбор и обучение, но и уменьшаем текучку в компании. 

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

Как отбираем стажеров: из ста кандидатов на стажировку проходят трое

Набор на стажировку похож на обычную процедуру найма: размещаем вакансию на hh.ru, собираем отклики, проверяем тестовые, проводим технические интервью. Процесс занимает три недели. 

Этап 1. Вакансия: публикуем ненадолго, сразу с тестовым

Обычно мы открываем вакансию на несколько дней, например с пятницы по понедельник. За это время получаем 100+ откликов — этого достаточно для одного набора стажировки. 

Мы выбираем такие «быстрые» вакансии по двум причинам: 

1. Учитываем собственные силы на отбор. Вдумчиво обработать больше сотни откликов сложно, поэтому стараемся не собирать больше. Тем более до оффера на стажировку доходят 4% откликов (подробнее об этом дальше), поэтому сотня откликов обычно закрывает один набор.  

2. Ловим самых мотивированных кандидатов. Тот, кто хочет попасть именно в Mindbox, подпишется на наши вакансии и получит уведомление, когда откроется очередной набор. 

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

Пример тестового задания

Сделать приложение для управления списком задач

Требования к интерфейсу.

В приложении должно быть:

• поле для ввода новой задачи,

• общий список задач,

• список выполненных и невыполненных задач,

• функция очистки выполненных задач.

Требования к коду

• Проект выложен на GitHub, доступен на GitHub Pages/Vercel/etc.

• Языки и инструменты: TypeScript, React и React Hooks.

• Библиотеки компонентов: на ваше усмотрение.

• Ключевая функциональность покрыта тестами.

• Проект запускается командой npm i && npm run start.

Этап 2. Разбор откликов: отсматриваем тестовые и ранжируем по приоритету

Через Huntflow автоматически отсеиваем отклики, в которых нет ссылок на тестовое. Оставшиеся просматриваем вручную и убираем те, в которых тестовое выполнено не по заданию. Например, в приложении нет тестов или оно написано не на TypeScript или React.

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

1. В код можно влюбиться. Например, он разумно декомпозирован, логика отделена от UI и протестирована отдельно. 

2. Good enough, но без старания. Условно, код разбит на компоненты, но логика протестирована не отдельно, а только внутри UI. Стажер проверяет реакцию на нажатие кнопки, а не вызов метода логики.

3. Требования выполнены, но есть вопросики. Например, хромает декомпозиция, или тесты для SPA ToDo — только E2E на Cypress.

Этап 3. Техническое собеседование: проверяем харды, но не жестим

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

Идеальных ответов не ждем. Например, я считаю, что знание о том, как устроен Event Loop в JS — не самое главное для начинающего фронтендера, поэтому мы такое не спрашиваем. Еще не просим сделать разные варианты верстки, достаточно одного. Не заставляем описывать детально причины багов в React, достаточно предположения: «Скорее всего, код надо поправить вот так». Не выпытываем подробностей про клиент-серверное взаимодействие, можно описать его в общих чертах. А еще, чтобы не добавлять стресса, не просим включать камеру и шарить экран во время лайвкодинга. 

Если обобщить, у нас всего три требования:

1. Базово понимать JavaScript и работу рендеринга.

2. Разбираться в структуре данных. Тут без поблажек — спрашиваем на уровне джуна. 

3. Уметь быстро схватывать суть — это понимаем в целом по общению.

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

Обычно воронка отбора выглядит так (это среднее за 3 набора):

Как проходит стажировка: каждый месяц — новый уровень сложности

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

• Дейли — ежедневно, на 15–30 минут. Выясняем прогресс по задачам, если задача общая — синхронизируем работу. 

• Ретро — раз в две недели, на 1–2 часа. Проводится с глазу на глаз с каждым стажером. Обсуждаем, что нужно улучшить — не в коде, а в работе в целом: какие харды и софты подтянуть, как организовать процесс.

• 1-1 — в конце каждого месяца, на час. Это время для обратной связи. Ведущий оценивает достижение целей и прогресс стажера. Стажер делится своим мнением о процессах, рассказывает, как справляется с нагрузкой.

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

Для нашего продукта код стажеров безопасен. Без ревью ведущего и продакт-менеджера ни один модуль не попадет в прод. Стажеры ловят баги с помощью тестов, а до непойманных добирается ведущий при приемке задачи или на код-ревью. К тому же стажеры чаще всего получают задачи, с которыми сложно кому-то навредить. Если что и развалится — есть fallback. 

Первый месяц: погружение и простые задачи

На старте ведущий проводит с каждым стажером установочную встречу 1-1, чтобы:

• Сверить ожидания. Расспрашиваем стажера о том, чего он хочет достичь с помощью стажировки и что ожидает от нее. Проговариваем, что стажировка проводится для поиска сотрудников, и успешным стажерам предложат оффер. 

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

Обычно на первой встрече я даю стажерам книгу «Программист-прагматик. Путь от подмастерья к мастеру» Э. Ханта и Д. Томаса — сборник практических советов о том, как выстроить рабочий процесс. 

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

Пример задачи первого месяца

# Big picture

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

Что почитать:

• Документацию Apollo

• Сайт GraphQL

Мы используем микросервис (не CDP), учти это при прохождении инструкции.

# DoD

• Подключена кодогенерация по инструкции: <Ссылка на инструкцию для фронтенда>.

• Есть первая страница — /newbilling/, которая использует результат запроса дат проекта.

# Имплементация

• Прочитать инструкцию, задать вопросы, если непонятно.

• Добавить запрос:

  query {
   billing(tenant: $tenant) {
     billingProjectInfo {
      startDateTimeUtc
      endDateTimeUtc
      freezeDateTimeUtc
    }
   }
  }

• Для получения тенанта можно скопировать код из файла useTenantSystemName.ts в frontend-campaigns.

• Вывести ограниченный список дат на странице

Второй месяц: стажеры становятся самостоятельнее

При постановке задач уже не так тщательно объясняем реализацию: стажеры должны научиться думать об этом до того, как писать код. 

Пример задачи второго месяца

# Big picture

[Ссылка на Figma] 

Выводим данные о тарифе и объем данных в сниппете счета. Указание, где какие в API — в Figma.

При загрузке выводим Skeleton.

# DoD

• Данные выводятся, если они есть

• Выводятся текстовые скелетоны (уточнить у дизайнеров точное состояние загрузки)

# Имплементация

• Добавляем самостоятельный компонент про панель справа

• Получение данных делаем на уровне BillingScreen

• В получение данных добавляем информацию для и выводим ее в панели сбоку: ссылка на сторибук

Третий месяц: прокачка софтов, работа в команде

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

Пример задачи третьего месяца

# Big picture

На старой странице пользователей есть экспорт списка пользователей, надо его повторить.

# DoD

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

# Имплементация

• Найти запрос на экспорты.

• Вписать в него параметры выбора.

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