IT-рекрутмент. Как найти лучших специалистов, когда все вокруг горит

Ссылка на плагин: https://chrome.google.com/webstore/detail/octohr/beiklbdjdmfkgchmiabjejdlpaoicbef

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

Ссылка на плагин: https://chrome.google.com/webstore/detail/candyjar/mlelamfpbkmcjighmglfodehbknhmlod

Git-Awards — сервис, который помогает искать топовых пользователей GitHub: вы можете отсортировать самых популярных, активных, востребованных в сообществе разработчиков по городам, странам, по выбранной технологии и другим параметрам.

Ссылка на плагин: http://git-awards.com/

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

Ссылка на сервис: https://octohunt.com/

После этого списка автоматических способов поиска, я надеюсь, вы пришли к выводу, что GitHub — это не так страшно, как могло показаться вначале. Теперь переходим к различным способам ручного поиска по ресурсу: как и следовало ожидать, на GitHub есть операторы поиска, которые могут быть нам очень и очень полезны. Хотелось бы, конечно, сказать, что это тоже булевы операторы и сейчас будет легко, но нет. Не в этот раз. Изучить их в полном объеме можно здесь: операторы поиска в GitHub https://docs.github.com/en/github/searching-for-information-on-github/searching-code#considerations-for-code-search.

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

location: — в поисковой строке GitHub мы можем ввести этот оператор, поставить двоеточие и без пробела написать город, который нас интересует: location: moscow. Таким образом мы получим в выдаче всех людей, которые указали в аккаунте локацию Moscow. При этом, как вы понимаете, мы не увидим людей, которые указали свое место проживания как «Москва». В отличие от Google, GitHub не распознает такие синонимы. Если мы хотим, чтобы в выдаче оказались и те, кто написал Moscow, и те, кто написал «Москва», мы, по логике вещей, должны поставить между этими двумя локациями оператор OR. И это будет одна из наиболее распространенных ошибок. Булевы операторы на GitHub не работают! В данном случае все запросы нам надо писать через пробел, чтобы получилось: location: moscow location: москва.

Но тут возникает другая проблема: на GitHub далеко не все пользователи указывают свою актуальную локацию, а многие и вовсе ограничиваются указанием Russia. Поэтому узнать, что они живут в нужном вам городе, не так-то просто. Что с этим делать? К сожалению, ничего — придется с этим жить. К счастью, GitHub предоставляет много других возможностей поиска.

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

Но тут возникает следующий вопрос: зачатую есть какие-то языки, которые мы хотим написать в поиске, но в реальности репозиториев на этих языках может не быть. Например, для разработчиков java есть фреймворк sрring — помните, да? Если мы хотим найти специалистов, которые работают со spring, казалось бы логичным написать поисковый запрос language: spring. Но это будет неверно, потому что в данном случае язык все же java, а фреймворк (то есть инструмент, который помогает разработчику кодить на java) — spring. Из-за этого найти людей, у которых есть репозитории на spring, будет не так-то просто.

Что делать? Можно написать language: java и дальше, через пробел, — spring. Таким образом система будет искать репозитории на java, а spring будет ключевым словом, которое система разыскивает в профиле. Если у человека в профиле написано что-то про spring, то мы получим это в выдаче. В данном случае есть риск, что у специалиста есть опыт работы со spring, однако он этого нигде не указал — и мы его упустим. Но с этим, к сожалению, ничего не поделать.