Прежде чем переходить к делу, настоятельно рекомендуем вам ознакомиться с нашими предыдущими публикациями о GitHub*. Также, вам жизненно пригодится переводчик с гитхабовского на русский. Мы постараемся дублировать термины, но, пожалуй, держите его под рукой!

* Github (Гитхаб), веб-сервис для размещения репозиториев и совместной разработки проектов.

3 причины завести микро-ATS
на Github прямо сейчас
[именно это и сделал автор, и научимся мы с вами сегодня]

  1. Разработчики из вашей команды могут оперативно оценивать профили новых кандидатов, не выходя из привычной для них платформы;
  2. Полезный опыт для рекрутера — если команда не полениться давать фидбэк о кандидатах, можно научиться лучше разбираться в специфике тех или иных позиций;
  3. Не забывайте… Это бесплатно!

Обзор работы

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

* репозиторий, (м.р., склоняется) папка, в которой находятся: конфиги, журналы операций, индекс файлов и сами файлы репозитория.

Говоря понятным языком, так будет выглядеть страница, на которую вы будете добавлять кандидатов. Очень просто и поэтому круто: никаких скрытых кнопок [и смыслов].

Каждый новый кандидат — это новый issue*, который соответственно получает уникальный порядковый номер. Удобно и наглядно: можно посмотреть, кто добавлял карточку, создать ярлыки и отсматривать людей группами.

issue (ишью), (ср. р., не склоняется) запрос к организаторам репозитория, содержащий предложение по улучшению, указание на ошибку, задачи или вопросы, связанные с репозиторием, напр. to open a new issue — открыть новое ишью.


Ярлыки
 (они же labels — лейблы)
Лучше начать работу именно с этого: создать ярлыки для каждой позиции. К примеру: Frontend, Backend, Data Science и так далее. Остается даже место для творчества — в окрашенных разными цветами ярлыками ориентироваться намного проще.

С помощью лейблов* еще можно сделать внутренний рейтинг кандидатов: так другие члены команды смогут давать им свои оценки. Например:

* лейбл/лейблы, (м.р., склоняется) он же ярлык. Наглядная система пометок для уже созданных ишью. Обычно включает в себя подобные значения: «bug» (ошибка), «help wanted» (требуется помощь), но четких правил нет. Могут быть изменены в зависимости от целей и потребностей.
Создаем проекты

Одна из любимых функций — она показывает, кого из кандидатов уже оценили разработчики из вашей команды, а кого нет. По сути, это будет своеобразная альтернатива всем знакомым доскам (как в Trello). Настроить этапы можно как душе угодно. Если компания небольшая, и объемы найма тоже скромные — Github может стать идеальной альтернативой ATS.

Если выставить настройки следующим образом, каждый новый созданный issue [новый кандидат] будет автоматически добавляться в первую колонку, закрытые issue [не интересные кандидаты] — во вторую:

  • Первая колонка: Новые кандидаты / preset: to do / move all newly added issues and pull requests here.
  • Вторая колонка: Не интересные кандидаты / preset: done / move all closed issues here.
  • Остальные колонки: не требуют специальных настроек — делайте как вам удобно.

Как найти Github кандидата?

Найти профиль разработчика не сложно: часто ссылка уже указана в резюме.


Краткая инструкция в картинках

1. Регистрируемся на Github. Первое, что потребуется сделать — создать свой первый репозиторий.

2. Добавляем несколько issue [карточек] для каждого из кандидатов. В описание добавляем ссылки на резюме, профиль на Github и другую полезную информацию.

3. Создаем систему ярлыков/лейблов. У нас это — технологии и шкала оценки (от * до ***).
В следующий раз при создании карточки кандидата, сразу добавьте к ней необходимые ярлыки.

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

Готово!

Как внедрять?

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

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

«Что я буду делать: Находя нового кандидата, я буду создавать новый issue со ссылками и моим мнением/комментариями о нем. Добавлю ярлыки и прикреплю к соответствующему проекту. После вашей оценки — буду связываться с кандидатами.

Чего я жду от вас, ребята: Не думаю, что вы будете все время сидеть и просматривать кандидатов (так что уведомления лучше отключите), но если появится желание и возможность — добро пожаловать!

Но, когда я попрошу, пожалуйста, зайдите и оцените кандидатов (поставив им от 1 до 3 звезд).

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

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


Источник: recrutach.ru

Похожая запись

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *