If there was ever an image summing up the developer recruitment pattern, it’s the one used by Isaac Lyman in his Medium post “How to recruit a developer”:
Looks familiar, right?
Unless you are one of the lucky companies offering “showstopper” jobs, it’s very rarely that top tech talent comes knocking on your door. Good developers are quickly snapped up because as passive candidates they get subsequent offers. They are almost never on the market because they don’t need to be shopping for jobs.
Research shows that HR professionals rely on the same social networks when they work, with LinkedIn topping the list with a score of 87% .
Source: Statista
To make things worse, recruiters tend to use LinkedIn in a very similar manner, mostly to “contact candidates or potential candidates” which comes second with a staggering 75%.
Source: Statista
This means we are all circling around one talent pool using the very same methods and yet, we expect unique results.
To make things even harder, web architecture and development framework come third on LinkedIn’s list of top 10 skills to get you hired here and today, which means developers are in VERY high demand.
Source: Slideshare
It’s high time you redesigned your developer recruitment pattern. Here are the 7 steps to make it happen.
Don’t outsource sourcing
That’s a no-no. Sourcing is the hardest and most mundane part of the process and many HR professionals are tempted to pay someone to do it. Sadly (but unsurprisingly), when the quality of your sourcing goes down, Quality of Hire is also likely to decrease.
Do your homework before you reach out to someone. Run a Google search, go through the candidate’s social media, and look through their projects on their site, GitHub and Stack Overflow (if they have them). Do a deep scan based on the data you find – I know you’re going to say it takes time, but it’s top talent we’re talking about here.
If you can, don’t rely too heavily on resume walls because people feel ignored if they don’t hear back, which happens A LOT. As CareerArc study points out 36% of employers never notify candidates about their status. It’s only logical that good developers are more likely to talk to you if you show real interest and dedication. Nobody likes bouncing CVs off resume walls.
Make sure the person going through resumes gathered understands the keywords and their substitutes. You may be losing perfectly qualified leads because you’re not getting the technicalities right.
Invest in referral programs
Good developers get pulled into the industry. They are typically noticed by mentors and peers who help them reach full proficiency and they learn as they work. In other words, they rarely look for jobs because “prospective employers recognize their greatness quickly”. As a matter of fact, in 2016, employee referral programs were the third source of quality hires according to Global Recruiting Trends 2016 report by LinkedIn Talent Solutions.
Source: Global Recruiting Trends 2016
The trend is constantly on the rise: Global Recruiting Trends 2017 by LinkedIn Talent lists employee referrals as the best source of quality hires (48%).
Source: Global Recruiting Trends 2017
Remember that the developers currently employed in your organization are a great entry point to a whole network of like-minded individuals who can code.
The benefits of employee referrals are manifold:
- You can take advantage of the whole network of your workforce,
- They come with a great applicant to hire conversion rate. Based on Jobvite Index, employee referral programs generate only 6.9% of all applications and 39.9% of all hires. “This is nearly double the SHRM reported average.”
- Zao research findings suggest that employee referral programs have a higher retention rate after one year (48% vs. 33% in comparison to career sites),
Source: Zao
- It’s easier to bring the new person up to speed because the employee who referred the new hire feels partially responsible for them.
Find out where devs like to hang out
Attend meetups, industry events and conferences where people who care about the craft usually meet. Good recruiters know where and when to look for the candidates, including Github, Stack Overflow, Hacker News.
You’ve got to remember though that the person you’re talking to is not their job title. Listen to what developer Matt Youell has to say about this:
“I am not a “Rails developer” or a “.Net engineer” just because those were the last positions I held or the last technologies I worked with. I like to solve problems with software. And sometimes hardware. And sometimes by just sitting and thinking and chatting with other smart people in the company. I’m a person. My name is Matt. Nice to meet you.”
Once you find someone interesting, make sure it’s about them and don’t just pitch your offer. Avoid generic messages and don’t go knocking on somebody’s door telling them they’re a fit if you don’t know that.You’ve never spoken to them and you don’t even know if they feel like moving jobs, so why don’t you just ask?
Which brings us to #4.
Start off on the right foot
One of the biggest problems of tech hiring is lack of time. As Glassdoor reports, average time to hire is getting longer and it’s increasingly difficult to find qualified developers in the scarcity situation IT sector is currently going through.
Recruiters are rushed while they source, rushed when they email potential candidates and rushed when they first talk to them. Why? Because they’re afraid to spend too much time on non-viable candidates.
And candidates can sense that right away.
A couple of initial messages from recruiters may seem flattering, but after the novelty wears off, recruiter outreach becomes a nuisance, especially because it’s poorly executed.
One of the biggest problems is that recruiters are not paying attention to profiles. Clément Folliet’s makes a good point: “You offer me a Java developer position, when I’ve clearly showed an interest in Microsoft technologies; you ask me for my phone number, when I’ve put it on the first line of my CV.”
That’s what is happening in the world of tech recruitment and you know that he has a point.
Folliet goes on to say that the problem can be solved easily by asking people how you can improve their current situation. He says the only person who got him to discuss the opportunity asked a simple question “Hello! How can your current job be improved?”.
Approach the people you find interesting like you would in real life. Engage in conversation and express interest in them. Don’t shout out offers in their general direction and leave, it’s rude. The rule of thumb is to only talk about the position once you’ve learned who they are and what they do.
You only get one shot at first impressions and if you fail to impress the developer, they’re probably gone for good. As Matt Youell argues, “the loss might be minimal when soliciting unskilled labor, but with high-demand, creative talent, that loss is unrealized potential”.
Design a bona fide system of verifying skills
As Isaac Lyman argues, “a developer at her best is a Swiss Army Knife for software — someone whose creative, insightful and rational thought process makes her a valuable part of any discussion in the company”.
How do you know if someone’s skill set and mindset can make a valuable contribution to the company?
Knowledge of technical minutia is an important part of the equation but not the only one – so are problem solving, abstract thinking, creativity, and willingness to learn.
How do you screen skills effectively?
You might be tempted to ask your candidate to invert a binary tree on a whiteboard (nope), look at your code and find bugs (no, no, no) or or throw random programming questions at them and hope you understand their point of view (no, thank you).
Now, let me go back to the dreaded whiteboard interview. You’ve probably heard that whiteboard coding sparks a lot of controversy among programmers – see what world leading techies have to say about “whiteboard” interviews.
- David Heinemeier Hansson, Creator of Ruby on Rails, Founder & CTO at Basecamp (he actually calls highly technical interviews “whiteboard algorithm hazing”:
- Tim Dierks, Made of the ashes of supernovae. Security @ Google.
- Ivan Morgillo, Author of RxJava Essentials, Learning Embedded Android N Programming and Grokking ReactiveX, speaker, Android Engineer at @Clue
Sadly, the biggest problem of the technical interview is that it doesn’t resemble work to be done if hired. In many companies, candidates are asked to write code on paper or a whiteboard. In fact, technical interview is by far the biggest problem of tech hiring: Sahat Yalkabov’s Medium post kind of says it all:
Source: Medium
Is there a better indicator of future performance than rote memorization? You bet there is.
Research from Frank L. Schmidt (University of Iowa) and John E. Hunter (Michigan State University) The Validity and Utility of Selection Methods in Personnel Psychology: Practical and Theoretical Implications of 85 Years of Research Findings shows that work sample quality is the best indicator of performance if hired.
How to get a viable work sample from the person interviewed? Well, there’s only one tool you really need to test coding skills and that’s a computer. Being able to recall and write bug-free code on a whiteboard doesn’t mean the person will do well. Remember that the closer you get to the actual work to be done, the more likely you are to hire a great dev
You can create a first day at work experience for the candidate using dedicated skill screening software. Observing a candidate doing his thing, coding away the way that feels natural to them and solving problems tells you a lot more about them than artificial trivia or whiteboard tests. For optimal results, you should test programming languages, frameworks and libraries, preferably in a manner which resembles real IT projects. Not only does it yield reliable results, it doesn’t make people frustrated. I call that a win-win.
Trust structure
You can only make your hiring work if you design a fully functional hiring process This way, when things go wrong you can fall back on your structure and find out why it happened. The aim is to look at each of the steps below and analyze where you have room for improvement:
I also strongly advise you to use a standardized interview scenario to reduce the influence of personal bias. You might like someone but it’s only fair you treat them the way you treat others and let their performance shine.
The final word of advice would be to stay human at every stage of the hiring process. Remember that the recruitment process is just like the sales funnel, so as you lose people along the way, your chances of hiring successful candidates are getting dimmer and dimmer.
Conclusion
As Isaac Lyman points out, developers and recruiters have the same goal. Coders look for jobs which are cut out for them, preferably ones that are challenging and provide learning opportunities. Recruiters aim to fill open positions with qualified people who can code well, do a good job and fit company culture. “If we have common goals, why is it that we can’t all work together?”, Lyman asks.
There’s a way to do that: don’t be a robot. Hire “people, not units of labor” and things are going to work out really well for you.
