From the Other Side: Increasing Engagement When Recruiting Software Devs
There's one problem in tech recruiting that doesn't get a lot of attention -- low engagement between software developers and technical recruiters during reach outs.
During my 8 years as a software dev at Amazon, I experienced this first-hand on a regular basis. I'd receive a nudge from recruiters about once a week, and in most cases my response would be lukewarm, or even be absent sometimes. Earlier I just took it as a sign of just how things are, and it was only later that I started looking at it as a problem yet to be solved.
In this post I'll share my view of the problem from a software dev's perspective and ideas to increase the engagement.
The urgency gap
One of the problem components is the difference in urgency. While there is tremendous pressure on recruiters to source qualified candidates, most devs are only looking passively. With the majority of devs relatively satisfied with their current jobs (our data says most developers are relatively content), and with everybody facing information overload all the time, the bar for that first reach out message naturally becomes quite high. While there might not be much that can be done to equalize the urgency of needs, the relevance of that first reach out can definitely be boosted.
Getting past that first filter
As a recruiter, you are the first hiring filter for the employer. At the same time you also serve as the first hiring filter for the candidate, even though this fact may be a little less obvious. At this stage, the candidate is looking to quickly assess the big-picture context and apply some initial filtering.
Does this job offer make them feel excited and be willing to consider a move? Or is it an opportunity to connect with a trusted talent advisor who could share a great opportunity in future? In order answer these questions, low-level technical requirements are not only irrelevant but also detrimental. Many great opportunities to establish context and rapport are commonly missed by focusing too early on technical requirements.
An effective reachout tends to have a certain blueprint. First, it establishes the big-picture context about the opportunity. What problem is being solved and what is the impact? Not necessarily the specific engineering problem, but the overarching business problem-space. Is the scope of work large enough to allow for growth? Second, it explains why the opportunity is likely a good mutual fit. It connects the opportunity with the candidate's career goals.
Not only are technical requirements irrelevant at this point, they're detrimental.
This is so much more powerful than reaching out to someone just because they happen to know Java or SQL. And third, it gets the timing right. This one is more tricky, and it requires transitioning from a transactional to relational approach to hiring. Personally, I've found the reach outs from Google recruiters to be big on the relational approach, and I've usually responded promptly to them even if I choose not to pursue the opportunity.
Relationship-based approach and building trust
Without visibility into candidates’ preferences and career goals, the recruiters are incentivized to take a transactional and shotgun approach to hiring. However, it is inefficient for multiple reasons. With majority of software devs looking passively, they are unlikely to respond to semi-relevant reach outs. Also, a transactional approach misses out on building trust in order to enable future engagements.
You may get lucky with the shotgun approach if you reach out to enough candidates. However, it’s near impossible to get lucky each time at scale.
As an alternative, the relationship-based approach can be a more powerful model. By investing time and energy into really understanding the needs of candidates, a recruiter can be more precise and effective at matchmaking. With insights into the needs of both employers and candidates, they can serve as trusted talent advisor. At the same time, they can also use their visibility into candidates’ preferences to offer advisement to the employers.
The thing about technology requirements
When it comes to exchanging information about technology requirements, there are a few things to consider.
First, from an initial candidate engagement point of view, these requirements usually don’t serve much value. The technology details don’t start to factor in until the candidate is already engaged about what you are offering. Most companies today tend to employ a fairly comparable group of technologies, so the technology stack of an employer is not usually a strong differentiator unless the candidate has strong technology preferences. Besides, filtering on technology requirements is fairly easy once a connection has been established.
Software developers, like other professionals employed in analytical fields, tend to enjoy big-picture thinking and problem-solving. Coding just happens to be one of the skills in their toolbox.
If your message focuses strongly on the fact that you are looking for Java programmers, essentially you are offering just a job opportunity to code in Java.
And lastly, by focussing prematurely on the specific technology needs of the immediate role at hand, you are missing out on building a relationship with the candidate. Having a skilled developer share their career goals with you and be receptive to you for future advisement is a good thing.
Be creative and differentiate yourself
Is there something unique and engaging about your culture that the candidate should know about? Let them know! For example, is the employer dog-friendly? This is something highly relevant in Seattle. Flaunt your USPs. As my grad school advisor used to say, be a leader in a category. If you’re not a leader in your current category, then create a new category and be a leader there. In other words, be creative and share what makes your unique or engaging!
I hope you found these ideas to be helpful. Please feel free to reach out if we can help.