Эффективное использование накопленного кадрового резерва влияет на два ключевых показателя: скорость и стоимость закрытия вакансий. Если в первую очередь обращаться к кандидатам, с которыми вы уже когда-то общались, то подбор ускоряется и становится дешевле в несколько раз.
Для IT-подбора недостаточно аккуратного ведения базы и проставления тегов и комментариев: база в несколько тысяч контактов будет бесполезна без булевого поиска, который даст более точные результаты за счет использования логических операторов.
Используя запросы с логическими операторами вы найдете резюме с нужными пересечениями или исключениями за пару секунд — и так по каждой вакансии.
Хантфлоу представляет: булевый поиск по базе кандидатов
Мы добавили в Хантфлоу поддержку необходимых логических операторов, которые покрывают задачи рекрутеров:
- OR
- AND
- NOT
- ()
- “”
Используйте их, чтобы найти кандидата с нужным сочетанием в резюме: по используемым языкам, библиотекам и местам работы в прошлом.
Кроме булевого поиска в Хантфлоу по умолчанию работает и поиск по вхождению справа — для него не нужно ставить *. Поэтому когда вы ищете postgre, то в результатах будет и postgres, и postgresql.
Это сэкономит вам часы работы и тысячи рублей: вместо того, чтобы вручную просеивать базу, вы сможете в первую очередь брать в работу теплых подходящих кандидатов.
Алексей Науменко, IT-рекрутер в Postgres Professional, поделился примерами поисковых запросов:
Пример 1
Мы ищем специалиста DBA под линукс с опытом в скриптовых языках и имеющего опыт с Postgres. Запрос будет выглядеть так:
linux AND postgres AND (python OR perl)
При необходимости можно добавить в запрос названия компаний, где с наибольшей вероятностью могли работать специалисты нужного профиля.
Пример 2
Мы ищем программиста, который будет развивать и переписывать текущий легаси-код с Perl на Python. Значит нам нужен человек, который умеет и то, и другое, и поисковый запрос будет таким:
Perl AND Python
Без булевого поиска перебирать всех людей со знанием Perl и всех со знанием Python было бы слишком долго.
Пример 3
Нам нужен фулстек-разработчик, где клиент-сайд на Vue.js, а бэкенд на Node.js. Мы можем использовать такой поисковый запрос:
(“vue.js” OR “vuejs”) AND (“node.js” OR “nodejs”)
Он выдаст разработчиков которые умеют и то, и то. Оператор OR нужен, так как разные разработчики могут по-разному указывать эту технологию. В первую скобку помимо vue.js можно ещё добавить OR “react”, так как эта библиотека достаточно похожа на vue.js и переход разработчиков с нее на vue.js проходит легко.
Если перебирать базу без булевых запросов, на поиск уйдет во много раз больше времени. При этом простой булевый запрос позволяет получить максимально релевантный результат.
Кирилл Ольховик, сорсинг-эксперт AmazingHiring, рассказал, почему булевый поиск по ATS так важен:
Если внутри ATS нет булевого поиска, нам приходится делать массу различных подходов к поисковому запросу. К примеру, мне нужен человек, в чьем резюме помимо того, что он у меня лежит в папке Java, есть еще и упоминание AWS. Я могу поискать по ключевому запросу AWS, потом по GCP, потом по Azure, потом по Cloud, а могу сразу ввести AWS OR GCP OR Azure OR Cloud.
Вторая причина (самая важная для меня лично) — это возможность исключать. Возьмем тот же пример. Мне нужен человек с AWS, но, делая 4 разных поисковых запроса, я постоянно натыкаюсь на профили, которые уже смотрел, потому что в одном резюме может быть одно ключевое слово, а может и все 4.
Поэтому сначала я ввожу поиск по AWS, отсматриваю всех с AWS, потом пишу (GCP OR Azure) NOT AWS, отсматриваю новые профили, потом делаю добивку с Cloud NOT GCP NOT AWS NOT Azure и отсматриваю всех остальных.
Зная, что, например, джависты в EPAM все работают с облаком, последней итерацией я пишу EPAM NOT Cloud NOT GCP NOT AWS NOT Azure.
Все это было бы невозможно сделать без встроенной возможности создавать булевые запросы.
