“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:
- Career Portal / Candidate applications
- Sourcing
- Active – Monster, Dice, CB, LinkedIn, Google resume searches, etc.
- Passive – Cold calling, blogs, user groups, associations, white papers, speakers, patents, etc.
- Job Postings
- Paid for
- Free
- University
- Social Media Campaigns – Facebook, LinkedIn, Twitter, Google+, etc.
- Referrals
- Candidate
- Employee
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:
- DevOps Engineer – Linux server production, cfengine or puppet for SCM, and strong perl or python
- Entry Level / Jr Software Engineer – Computer science degree, algorithm writing, C/C++
- Java Developer – Core java, MVC patterns, backend database software
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:
- Making sure your career portal is appealing to the right audience. Remember that these engineers have their choice of the best companies to work at. They don’t have to work at yours.
- Your sourcing pipelines need to be varied with active and passive (job boards, LinkedIn, resume searches, cold calling, networking, blogs, user groups, associations, white papers, speakers, patents, etc. It all starts with a solid search string that you can adjust for every sourcing method possible:
(devops OR “production engineering” OR “service engineer” OR “site reliability” OR “systems engineer”) linux (puppet OR cfengine) (perl OR python)
- If you aren’t getting the return on investment for your job postings, then you may have to change them up. These engineers love the challenge of deploying software releases in an mission-critical production environment, all without any downtime. Your job postings should emphasize these factors.
- Using social media to engage with similar candidates is abolsutely necessary. Network with simliar engineers at companies with similar server infrastructure like Google, Facebook, Amazon, Yahoo, GAP, Walmart.com, Salesforce, Microsoft, Twitter. But don’t forget that these engineers exist in similar role at mid-size engineering companies that are not “brand name”.
- Referrals go without saying, but always talk to everyone. Even if they are not interested, there is always someone that they may know. Even if the candidate was not up-to-snuff, they may know the perfect person.
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.