If you would like to learn how to source on Github as per this post, and other ways, I’d suggest you sign up to Advanced Sourcing Training Live in Barcelona on the 26th of March. Use the discount code GITHUBSOURCING for a 30% discount.

Behavioural sourcing

Those who know me, have heard me speak, or attended any of my trainings know that I am quite into what is called behavioural sourcing. It was my friend Guillame who first introduced me to the term about a year ago. The concept as such wasn’t new to me, just the terminology. I had applied the concept to my own sourcing for a while but never really had a name for it. I just thought of it as sourcing.

The basic description of behavioural sourcing is that instead of trying to find matching keywords on, let’s say a LinkedIn profile, you look at the behavioural of the candidate – their digital footprint.

There are many ways of doing behavioural sourcing. I believe that on each platform that we use to find talent, we can either find candidates based on keywords or based on behaviour. 

 

Sourcing on Github

When it comes to Github, I used to think that by simply using Github to find candidates, I was applying the concept of behavioural sourcing. I’m no longer convinced that’s the case. If you are finding candidates on Github based on what repositories they have matching your keywords to theirs, you are missing out on lots of others great potential candidates.

A user on Github can choose to have their repos public or private, so we might not be able to see what their technology of choice is through simply looking at their profile overview – it could be empty.

 

Beyond the keywords

The fact of the matter is that you cannot, or rather should not, contact potential candidate solely based on their skill set. “Hi. You use Java. I need a java developer” simply isn’t good enough. Before contacting a potential candidate, you also want to evaluate the likelihood of them wanting to work for your company/client. It’s not a simple game of matching keywords to tech stack.

As an example, java can be used for a wide variety of things, from e-commerce to logistics, streaming to whatever. So, just because they know java does not mean it’s a match.

This is where behavioural sourcing comes in.

 

A real life example

At TV4 & C More, where I’m currently on assignment as an inhouse recruiter, we need more people who has experience, knowledge and/or interest in the field of video/streaming. We need to strengthen our skills in this particular area.

Our tech stack is a big mix of React, Go, Elixir, Swift, Kotlin and whatever else takes our fancy. Me doing a search for people with those particular skills does not guarantee an interest in video/streaming. I need to go beyond the keywords and look at other aspects.

 

Step 1 – Finding a repository

As opposed to the “ordinary” way of finding users on github,

 site:github.com “block or report” Stockholm javascript,

we will start our search a little differently. We are looking at it from a “behavioural” point of view.

The first thing you want to do is find a repository related to your niche and/or using the language/technology you are after. In my case, I need someone who is interested in video and/or streaming. My keyword will be “hls” (hls stands for HTTP Live Streaming) and the language I’m looking for is javascript. So my search on Github itself, not via Google, will be 

hls language:javascript

This gives me a list of 526 repositories. The keyword “hls” is now targeting both the name and description of the repository. If I want to narrow the search I can use the github specific operator in:

 hls in:description language:javascript

Above search targets repositories written in javascript mentioning “hls” in it’s description. This instead gives me 295 results. This tells me there are quite a few repos with hls in the title, but not in the description (231 to be exact).

There is a third way of finding hls related repos and that is by searching for hls in the readme file. The search would look like this 

hls in:readme language:javascript

This gives me 1001 result. So, a lot of repositories has a name and description not mentioning hls, but it is mentioned in the readme file. This would indicate to me, that even though I cannot see it at first glance, these repositories are related to streaming.  

 

Step 2.1 – Finding stargazers

You have to make sure you actually read the readme file to make sure the repository is related to your role. In my search for hls I came across the a repository called GoogleChrome/puppeteer which in it’s readme file stated: 

 “Since Puppeteer (in all configurations) controls a desktop version of Chromium/Chrome, features that are only supported by the mobile version of Chrome are not supported. This means that Puppeteer does not support HTTP Live Streaming (HLS).” 

Instead I’ve chosen sampotts/plyr which in it’s readme file states 

“📹 Streaming – support for hls.js, Shaka and dash.js streaming playback” 

Exactly what I’m after.

Now that we have the repository we want we, which is related to the position we want to fill, both in terms of technology (language) and topic, we can start looking at the stargazers. All I need now is to click on the number next to “Star” at the very top.

 

X-raying for stargazers

At Sourcing Summit in Munich, Irina Shamaeva gave a great presentation on tech sourcing where she mentioned the string 

site:github.com inurl:repositories 

to target the “repository” tab on a user profile on Github. This string can simply be adapted to suit are case of stargazers

 site:github.com inurl:stars

Let’s use the reop above, sampotts/plyr, as an example. I will simply add this to my search string

 site:github.com inurl:stars sampotts/plyr

and what I’ll get is a list of people who has starred this particular repository. I can, of course, add more parameters to the string such as location. 

These people does not necessarily have any of this information on their LinkedIn, hey they might not even have a LI profile! So, I’m better off looking at their behaviour (showing an interest in video) than finding their own repos. 

If you just tried those strings in Google you will have noticed a discrepancy between how many people have starred the repo, and the amount of results in Google. There’s quite a big difference. So, the best-case scenario here is really to NOT go the Boolean way but instead look directly at the people in Github. 

 

Step 2.2 – Finding forkers

Behavioural souring on Github does not end at stargazers. You could do the very same thing looking at those who have forked the repo. Simply click on the number next to “fork” at the very top. 

 

Step 3 – Get in touch

How you get in touch will be up to you. Personally, I prefer e-mail. Hyperpersonalised ones. Having the information about what the candidate has starred or forked, and how that in turn relates to the job your looking to fill, should help you on your way to writing a great reach-out message. 

 

Conclusion

You can do so much more than simply matching keywords. Making sure you are contacting the right people will give you better results. So start thinking about what the person you are looking for will be intrested in, and start your search there.

Using the above technique I managed to find an Android developer not on Linkedin. Unfortunately it didn’t go beyond the first interview, but I am still happy 🙂

 

If you would like to learn how to source on Github as per this post, and other ways, I’d suggest you sign up to Advanced Sourcing Training Live in Barcelona on the 26th of March. Use the discount code GITHUBSOURCING for a 30% discount.