Зачем рекрутеру ATS внутри Github
Прежде чем переходить к делу, настоятельно рекомендуем вам ознакомиться с нашими предыдущими публикациями о GitHub*. Также, вам жизненно пригодится переводчик с гитхабовского на русский. Мы постараемся дублировать термины, но, пожалуй, держите его под рукой!
* Github (Гитхаб), веб-сервис для размещения репозиториев и совместной разработки проектов.
3 причины завести микро-ATS
на Github прямо сейчас
[именно это и сделал автор, и научимся мы с вами сегодня]
- Разработчики из вашей команды могут оперативно оценивать профили новых кандидатов, не выходя из привычной для них платформы;
- Полезный опыт для рекрутера — если команда не полениться давать фидбэк о кандидатах, можно научиться лучше разбираться в специфике тех или иных позиций;
- Не забывайте… Это бесплатно!
Обзор работы
Это тестовый репозиторий* — не стесняйтесь, можете понажимать и поиграться, чтобы выяснить, подходит ли вам это и что к чему
* репозиторий, (м.р., склоняется) папка, в которой находятся: конфиги, журналы операций, индекс файлов и сами файлы репозитория.
Говоря понятным языком, так будет выглядеть страница, на которую вы будете добавлять кандидатов. Очень просто и поэтому круто: никаких скрытых кнопок [и смыслов].
Каждый новый кандидат — это новый 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
