The Sourcing Gig
I was on the look out for full time work a few months back when a friend suggested that I try sourcing for an IT recruitment firm. As a sourcer, my job was to take a job opening, compose a meaningful search string from the job requirements to mine the job board resumes with and then reach out to possible candidates. The premise was that as a computer science major and despite having been mostly in academe for the last 6ish years, I would be able to read and understand job requirements a little better thus end up with a good candidate pool. The boss describes it (and recruitment really) as an easy job, but difficult to do well.
First Things First
I was told that the trick was to read what counts. And what counts for the recruiter is the candidate’s most recent job and who it was for, how many and what kind of jobs they had in the last 5 years, with whom and in what industry. Academics and certifications were checked only if mentioned explicitly. And if a candidate worked in a company a recruiter isn’t familiar with, no matter how big in the software world (Adobe and Mathworks from experience), it may go unnoticed.
Of course, the resume should be readable to begin with; some files are just a victim of a bad upload or can’t be read by the job board web application. It doesn’t matter if the original file is fine and attached to the search result,; it will most likely get skipped (I expect that my LaTeX generated resume wont do well here). Regarding content and all the resume tips out there (for example,    ) – all worthwhile to go over, keeping in mind the information recruiters care about. Personally, I’m glad that the objective statement is out. Also that old SEO trick where you place a set of tech buzzwords in tiny, unreadable font at the bottom of the resume? Bad idea.
The <insert-programming-language-here> Developer/Programmer
At university we remind students that programming languages are only tools. Focus on how the system works and it wouldn’t matter what tech/language the industry throws at you. Sadly, this is far, far from what the outside world thinks. At least from the recruitment perspective; which doesn’t make it any less disappointing. I understand that not all developers share this philosophy and prefer the intimacy of a single language. But to pass on one software engineer for developing in one language over another is, to me, a wasted opportunity (and in the case of computer scientists, a wasted 4-year degree).
Isn’t recruiting and hiring all about people and talent, not tools?
The Hunt for Purple Squirrels
There was no shortage in open positions (developers, helpdesk specialists, QA’s, administrators and analysts) during my stay, but not a lot of perfect matches. When dealing with people, there will always be variables – the recruiter, the hiring manager, the candidate, the job,the pay. And sometimes it feels like what they need is clone or android; not a real human person with varied skills and experiences. So we end up hunting for purple squirrels.
The experience was a hole-in-the-wall peek into IT recruitment. It was an opportunity to know what skills and tools some of these companies are looking for. And whether I perceived it incorrectly or it’s just the way hiring is, but what they want are mercenaries – no training needed, ready out of the box to work on 3-18 month projects then move on. As mercenaries, it’ll be all about money and maybe about the experience too. But will the company get great (maintainable, scalable, readable, documented, usable) software this way? And more importantly, is this an ideal developer archetype or just another unhealthy image that should be avoided at all costs?