The recruiter approach
Being a frontend developer, I regularly get contacted by recruiters for a variety of development roles. The majority of this happens through Linkedln. First and foremost, this is indicative of the booming web development industry (e.g. Ireland is currently at peak employability). But it also shows that our skillsets are highly sought after.
This kind of clickbait seems to be a recruiter’s go to. It is so common that I receive solicits like this on a daily basis.
Now, it may seem a very strange to complain about. Why would a load of potential job offers be an issue?
Well, the frequency is not so much the problem, more the delivery. Such a thriving industry is bound to come with an influx of offers that developers tend to filter through. That is unless of course they are urgently seeking a job, but even then, the most inviting offers will be prioritised. I’m going to help you get your job offer to the top of the jobseeker’s list, as well as poach the best candidates for your role.
If the above message is your style, your recruitment tactic needs to change. Describing the role accurately is key. Poor recruitment tactics lack empathy for the developer and don’t demonstrate how his/her skills will be applied.
This small snippet only scratches the surface, a perfect example of how poor recruiters gloss over details and try entice candidates with generic intro messages.
So a frontend specialist in Reactjs might have their own specialised recruiter. One would think that this level of specialisation in recruitment would mean more understanding of a particular roles. However, it is my experience that the recruitment field lags slightly behind, as the technology industry dashes ahead. A recruiter who can keep on top of latest trends and demands in the industry will have a huge advantage.
Recruiters are not relating to potential hires.
Lets examine a message that I recently received:
“This company has excellent environment that are consistently focused on building world class products. You will join a flat structure environment where you will have exposure to the entire product and where you will work on taking large complex data sets.
You will work with the team to help guide the companies product decisions and to help build complex features while working as part of a team that prides themselves in solving issues that matter for their customers.”
This section has told me absolutely nothing. This describes any basic developer roles, in fact most jobs in any given tech company. Nothing has been revealed here. In particular, the second paragraph is almost completely useless. It describes the ideals of any business that functions correctly.
I am very much aware that it is in a recruiters interest to keep the roles as anonymous as possible at the discretion of their clients. However, you cannot expect to entice a decent web developer candidate if you’re going to paint it generically.
As a recruiter, you should aim to:
(i) target the developer at his/her skillset
(ii) give them an indication of how they will be applying their skills day to day
(iii) relate that back to the product they will be working on.
Now compare that last example to this offer:
“You will be utilising React.js to build reusable, modular UI components that will be receiving large datasets that will be mapped to the dynamic layouts that you build.
Once created, you will use will then use automated testing on these layouts using the test suite Jest.”
Notice the difference? Instead of just using a techy buzzword, the application of the technology has been described with regard to the company’s product. The text is shorter in length but so much richer in detail. The testing responsibilities for the developer have also been outlined.
Also, there is also a bit of discretion left in there so that nothing is unnecessarily revealed. I understand it can be difficult to strict this fine balance, but get it right, and you’ll be luring in all the best web developers. Do your own research into the role and the company, and don’t be afraid to ask the hirer questions. After all, they’re looking for the best candidate too.
It goes without saying that there is a correlative relationship between how much commission the recruiter is receiving for a potential hire and how eager they will be in reaching out to potential candidates. But after all, you’re only looking to fill one role with one person. So better, more informed contact is better than mass messaging. Recruiters run the risk of losing a potential employee if he/she cannot discuss or relate to the technical skills of that developer. Similarly, you run the risk of wasting time with unsuitable candidates if your message is too generic.
I have experienced my own frustrations with this when dealing with a recruiter who didn’t understand my excitement of working with new technologies such as Ionic and Angular 2 (which was new at the time). I had only one year of experience at the time. The recruiter didn’t understand these technologies, as it wasn’t on his skills sheet. Without the required 3 years experience he didn’t put my application forward.
But any other tech lead or senior developer could easily see how knowledge of these cutting edge technologies gave me an advantage over a more experienced candidate who didn’t know the language required for the role.
I decided to directly contact the company themselves and luckily, I was able to chat to them on the phone, completely bypassing the recruiter altogether.
This is risk you take when playing the recruitment game solely with tech buzzwords, a static qualifications list and a surface level understanding.
The relationship of a recruiter and developer is portrayed as symbiotic. But when the developer has the wherewithal to bypass a recruiter this just isn’t the case.
Instead, the relationship between a developer and recruiter can become increasingly harmonious by the recruiter going the extra mile in understanding how a candidate skills can applied in a specific roles, and understanding the skillset the hirer is looking for.
I don’t expect recruiters to be experts in absolute every area of web development, but you can start off learning incrementally. Do further research into the roles you’re recruiting for now, and soon it’ll be easier to stay on top of things. In this series of blogposts, I will cover more instances of how a recruiter can relate to a developer using case studies. I also breakdown current in demand technologies.
The recruiter that learns high-level, abstracted versions of web technologies, and how they are applied, will attract the most hires.