Advertisement
To Source, or Not to Source by @MarkNexus
Get articles like this
in your inbox
The longest running and most trusted source of information serving talent acquisition professionals.
Advertisement
Related Articles
“To Source, or not to Source…that is the question:
Whether ’tis Nobler for recruiters and sourcers to suffer
The Postings and Campaigns of outrageous Recruitment life cycles,
Or to take up Sourcing against a sea of difficult requisitions,
And by sourcing fill them: to close, to fill
No more; and by close, to say we hire”
So I may have altered the soliloquy from Hamlet by a few words here and there, but there is a good reason.
For all the recruiters and sourcers out there who contact candidates, you probably have more than one requisition you’re working on. In fact, if you work for a mid-size technology company, a recruiting agency, an RPO firm, or a start-up, then you probably have anywhere from 5 to 25 open requisitions. These can range from entry-level engineers all the to software engineering team lead. All of these requisitions need attention from you, but it may not be feasible to give each of them equal attention. There’s only one of you! So what do you do?
The question becomes: To Source, or not to Source.
Ideally, we want to source for every job requisition we have. Since sourcing is just one tool we can use in our toolbox, we want to make sure we use it for the right jobs. The list of tools in your toolbox could look something like this:
Common sense says that if you have the space/slots to post your jobs, then you post all of them. Even if you are sourcing for those jobs actively, it couldn’t hurt to have a wider range of possible candidates. For the sake of argument, let’s say you have 3 jobs you need to fill:
So which ones to source and which ones to post? Like I mentioned before, if you can, post them ALL. Save the most difficult or competitive requisitions for your sourcing campaigns and paid job posting slots.
Entry Level / Jr Software Engineer
Your entry-level or Junior Software Engineer positions have a higher chance of getting filled through job postings and career portal listings. If you don’t want to bother going through a full blown sourcing campaign, then set up a Google Alert with a string like:
site:stanford.edu ~resume (2013 OR 2012 OR 2011) (algorithm OR “data mining” OR “text mining”) (bscs OR mscs OR “computer science”) -intitle:jobs -inurl:jobs -professor
And a local (50 miles) Monster/LinkedIn Search Agent like:
(“entry- level” OR intern OR “junior sw” OR “jr sw” OR “jr software” OR “junior software”) (algorithm OR “data mining” OR “text mining”) (bscs OR mscs OR “computer science”) (stanford OR berkeley OR mit OR “carnegie melon”)
Once you set these up, you can forget about them and only deal with the incoming flow of candidates. These strings will give you the most return for the least amount of effort.
DevOps Engineer
Now your DevOps Engineering requisitionis a tougher role to fill. I don’t necessarily find it difficult, but these guys are wanted by EVERY company. You have to look for systems engineers working in a production environment with 1000?s of servers, that also have software deployment skills, expert Linux scripting experience, and strong networking / load balancing.
For a more difficult role like this, you want to utilize ALL of your channels. This means:
(devops OR “production engineering” OR “service engineer” OR “site reliability” OR “systems engineer”) linux (puppet OR cfengine) (perl OR python)
I can go into more detail for each of the recruiting and sourcing strategies for these jobs, but you get the idea. Some jobs can be tackled with one tool. The most competitive / challenging jobs must be tackled with a Swiss Army knife of solutions.
This post originally appeared on Mark’s blog.
Mark will be our special guest on #SourceCon Live this Thursday at noon central.