The relationship between recruiters and developers is a rocky one.
In 2013 Joel Spolsky, the CEO of Stack Overflow, famously exploded Twitter asking a simple question: “Programmers: what things do recruiters do that drive you crazy?”
The 350 answers he got varied in details but ultimately focused on the fact that recruiters don’t understand programmers.
The reason? Developers and recruiters are very different.
Recruiters typically like people, enjoy phone conversations, and thrive on ambiguity. Developers on the other hand, typically hate the telephone and enjoy coding because computers respond predictably, unlike people.
According to Spolsky, if you’re a great recruiter, you’d make a bad programmer, and the other way around. If you’re a recruiter, he says, programmers don’t like you because you don’t realize that.
Six years later, things haven’t really changed that much. Recruiters and developers are still struggling to cooperate in many organizations globally. Is it possible for these two groups to work together despite the difference in their psychological makeup?
As the CEO of Devskiller, I’ve spent a large portion of the last five years running workshops for tech leads, engineering leads, senior architects, HR leads, and learning & development leaders. The three-day workshops I conducted were focused on a number of development-related issues, including Spring, Java, microservices, and engineering architecture. Despite attracting people from various backgrounds, with various levels of experience from over 70 companies, one thing seemed universal. It was the frustration with the recruitment process in tech.
During the workshops, many participants were quite vocal about their pain points. I often saw that at the beginning of the workshop, people were reluctant to share their pain stories. But as the workshop progressed, they would gradually open up after hearing other people’s stories. Interestingly, that frustration was commonly found both in HR professionals and developers.
If nobody is happy with the current state of affairs, why is the tech recruitment process still broken in some many companies? There are a number of resources about the cooperation between the HR and IT, but most of them are somewhat superficial.
So I’ve mapping out below the optimal recruitment process setup, along with the involvement of both departments (HR and IT) at each stage.
How HR and IT Should Work Together to Recruit Developers
Let’s go through each of the stages of the process see how they can cooperate for optimal results.
Defining the Need: IT
The skill gaps are most easily identified by members of the dev team. They’re the ones doing the job. For that reason, the need for hiring a new developer usually comes directly from the dev team.
Skill gaps are most easily identified by means of competency mapping, which can be carried out in a number of ways, from Excel spreadsheets to competency mapping software.
Job Description: IT + HR
The IT department usually lists the skills required for a particular position. The role of the HR department is to decide whether these requirements are realistic or not, and if possible, establish a list of priorities among those. HR is more likely to know how scarce or abundant some skills generally are on the market. For example, the IT team would like to hire a senior Java developer in the ideal world, but there is no budget for this type of skill set.
The two options are to either increase the budget or hire a junior Java developer and help them advance their skills. It is the job of HR to manage these expectations.
Job Ad Draft: HR
The HR department defines the candidate profile and provides some data like the dress code, benefits, etc. However, the IT department also has an impact here because it chooses the tech stack and project-development methodology.
The tech stack should always be communicated in the ad. It’s important information developers are looking for in an ad.
Source: Casumo via No Fluff Jobs
You can have the nicest job ad and company site, but they need to authentically represent the job. In essence, your internal developers are the storefront for your culture. If they contribute to open source and attend industry events, they actively show whether what’s said in the job ad is true or not.
Company culture and the nature of the job can be communicated at this stage. In the example below, you can see that the choice of architecture, technologies, and conventions are made by the developers. This is a clear, simple piece of information which has a lot more value to this particular target group.
Source: Casumo via No Fluff Jobs
Job Ad Promotion and Sourcing: HR + IT
This is executed by the HR department. It uses LinkedIn, the company’s social media, the website, and profiles on industry sites like Stack Overflow or GitHub. However, in a perfect world, the company’s developers support the HR department at this stage. They organize hackathons, meetups, conferences, and other industry events to attract people passionate about the craft. Given that referrals are one of the best sources of high-quality hires, you can’t really underestimate the value of the existing network of your developers.
This is the stage which typically sparks the most controversy. In most cases, recruiters don’t have the skills listed in the job description, so they can’t assess these skills. This is why the IT department typically steps in.
In an efficient, fully optimized hiring process, technical screening is carried out using dedicated software. Selecting a good platform for technical skills assessment allows you to filter out up to 44 percent of candidates before a face-to-face meeting without impeding the end result. Other companies report decreasing the number of unnecessary interviews by up to 60 percent.
Interview: HR + IT
The interview stage is where both departments cooperate most closely. Unfortunately, it’s also where things usually go wrong.
These groups are so different they simply don’t understand each other’s needs.
In most cases, developers are invited to two interviews: a soft skills interview and a technical interview. These typically take part on the same day.
The recruiter evaluates whether the candidate fits the team or not and evaluates the candidate’s personality traits. This is different from the tasks of the IT team. Their job is to assess hard skills. Their focus is engineering aptitude only, while the HR looks at behavior. For this reason, they can have completely different opinions about the same candidate.
As harsh as it sounds, developers have been known to trick recruiters into believing they’re a great fit. It’s relatively easy to put on a character for one hour if you know your audience doesn’t have answers to the questions they’re asking.
For that reason, the IT team engages the developer in engineering-specific conversation, often asking tricky questions. Because it’s easy to argue in tech (most things are context-specific), the candidate is more likely to focus on what they want to say instead of how they want to be perceived.
These 45 minutes are highly important because the HR department can take a closer look at the candidate. They get a clear idea of the candidate’s personality which they can compare with what the developer’s shown them in the soft skills interview,
Decision and Offer: HR + IT
Reaching a hiring decision should be a joint decision of the IT and HR departments. Both teams provide different types of insights necessary to make a good hiring decision:
- soft skills
- technical skills
IT should be reminded here that both sides of the process are equally important, and that the decision should be reached by consensus. Great developers for example, can be productive and highly skilled, but not team players.
A word of warning: in many cases, developers often forget that candidates are rarely perfect. No candidate ticks all the boxes. If you like the way a candidate thinks, their problem-solving skills, and their willingness to learn, give them a shot.
Communicating the Decision to the Candidate and Candidate Feedback: HR + IT
While discussing this subject, the workshop participants were divided. However, we ultimately seemed to reach a consensus.
- A 100 percent positive hiring decision can be communicated by HR
- A positive hiring decision without meeting all the requirements of the candidate (i.e. lower pay) should be communicated by a technical person so they can explain the decision in detail. I can’t stress enough how important this is.
- A negative hiring decision should be communicated by technical professionals so they can thoroughly explain the decision and answer all questions.
I’ve heard of many cases where candidates were hired after acquiring the desired skill or skills that were missing from the portfolio. They were re-invited to the interview six to nine months after their first application.
Onboarding: HR + IT
Both parties are involved in onboarding. R is responsible for administrative onboarding, including equipment, health and safety, and paperwork. Any project-related onboarding is carried out by IT, with the team lead typically being the person in charge.
As you can see, both HR and IT are heavily involved in the recruitment process, so it’s not like they can avoid each other. To maximize the recruitment results, both recruiters and developers must work on improving their communication. Above all, they should accept that despite being different from each other, they have a common goal.