What to look for from a recruiter

Let’s be honest – any time you see a page called “What to look for in an x“, and the author is x, it’s really a page of “Why I think I’m a really great x“. This page is no exception to that rule. Without further ado, here’s my completely unbiased opinion on what I think is important in a technical recruiter:

They understand what all the words mean on your CV / résumé

So it’s a running gag that technical recruiters can’t tell the difference between JavaScript and Java, or that screening your CV to see if you’re suitable for a role consists of hitting Ctrl-F and typing in PERL/CGI. And while there’s a bit of truth to this, most recruiters are at least a little bit more sophisticated than that.

But what’s really important is a recruiter who can argue your case to a client. I recently had a great developer apply for a role, only to get kicked back at CV stage on the basis that he was “really just a sysadmin and not a developer”.

At this point a non-technical recruiter is out of luck. They’re not really sure either way, they’ve got a bunch of candidates to get through, and they want to keep the client happy. What you really want is a recruiter who understands the job brief – and what’s written on the CV – well enough to be able to push back if that categorization is inaccurate. Somebody who can say “Well I thought that too, but looking through his GitHub contributions he’s written some pretty substantial and well-designed software”.

Maybe the experience on your CV is a bit varied, and your CV gets pushed back for “not enough experience”. Again, what you really want here is a recruiter who’s read through your technical tests for other roles and can push back and say: “I’ve seen some of his/her work, and I was impressed by the use of MooseX::Types / the deep understanding of DBIx::Class / whatever” and make sure that you get the interview anyway.

These are real situations, and they come up more commonly than you might think. If the recruiter referring you is a programmer, and their technical judgment is trusted by the client, you’re going to get a lot further along in the recruitment process.

They’re a sales person, but they’re not interested in just the short-term

Recruitment is a sales job with commission. Recruiters get paid when you accept a job at a client. For recruiters with quartlery targets imposed by their boss, getting you to sign on the dotted line is usually more important than your being convinced a role (or from the other direction, the candidate) is right for you.

If you Google for the answer to whether or not you should accept a counter-offer (your current employer offering you more money when you look elsewhere), it’s no surprise to see a multitude of articles written by recruiters saying you absolutely should not (which is untrue). One site claims: “The rule of thumb among recruiters is that 70 to 80 percent of people who accept counter-offers either leave or are let go within a year”. The actual rule of thumb is that 100% of candidates who accept counter-offers don’t generate any revenue for the recruiter…

Also, sometimes you’re going to be perfect for a job that the recruiter isn’t representing. I may not have telecommute contract work in finance on my books right now, but I do know a company who does. A recruiter focussed on the short-term and making a quick buck won’t tell you about opportunities they won’t make money from, but a recruiter who’s focussed on the long-term wants you to trust them, and wants to be authorititive about the job market, so will make sure you’re aware of the whole market, and not just their jobs.

I’ve been programming Perl for at least 15 years. I imagine I’m going to continue for another 15 years, and I’d still like to be doing Perl recruitment then too. With that in mind, the focus comes off making a quick buck by pushing unsuitable candidates in to unsuitable roles, and much more in to growing a brand and making sure satisfied customers and candidates come back next time they’re looking for a new developer or new role.

They know what the important things about a job are

Back in the day, I worked doing a very fun job automating warehouse machinery for a well-known ecommerce outfit. But I was also keeping an eye out for other interesting things, and when I saw a role that offered a 30% payrise at a large bank, I was intrigued, and went and interviewed, and got offered the role.

I was very lucky to get a counter-offer from the current employer that matched what the bank was offering, but the recruiter was absolutely stunned I might not want to work for the bank. What about the prestige of working there? What about how it would look on my CV to have worked at one of the biggest banks in the world?

When you’ve worked as a developer, you understand your job enjoyment will be multi-faceted. How technical are management? How often do commercial concerns override doing the right thing technically? How much do your coworkers care about programming, rather than just punching a clock? What’s the company’s policy on open-source? Are developers considered a cost-center, or is it a self-described technology company? Do they have a sensible deployment process? Are they in AWS or are you deploying to a 3rd-party-managed server that’s completely locked down?

You’ll want all these answers at interview, but it’s easy to get swept up in the whole process. A recruiter who understands the important characteristics of a role, may well have worked at the company you’re applying for, and almost certainly knows your future colleagues both socially and professionally is going to be able to provide you with a much deeper understanding of any given role.

Conclusion

Being a programmer and being a recruiter are not even slightly similar roles. A recruiter who’s been a programmer knows this, and knows what’s important in the recruitment process. If this sounds like it might make a difference, it’s probably time to get in contact