The elusive developer hire...The past seven years of my recruitment career have been dedicated to hiring this specialist talent and during this time Iâve seen a lot of things that work when trying to acquire development talent - and sometimes more importantly the things that donât. Â While I wonât pretend that one hiring methodology works for every company, (big banks and little start-ups will most likely have different processes) I have compiled a number of useful tips that can be helpful to bear in mind throughout the hiring process.
1)Â Donât chain yourself to a job description. Â
On occasion, have you come across a candidate who has great skills, yet not ALL the skills you want? Â Our advice - consider them and donât be so quick to dismiss! Â If a developer has worked in all versions of ASP.NET up to 4.0, but donât have 4.5, itâs fair to imagine theyâll be able to figure it out. Â If theyâve shown the capacity to learn in the past, we can assume theyâll have the capacity to learn in the future. Flexibility could provide you with the best candidate in the long term.
2)Â Do know your needs vs. wants.Â
In line with the above, ask yourself âWhat is the CORE responsibility of this role?Â What are the non-negotiables?âÂ Yes, you may want your front-end developer to act as a stop-gap for your PHP developer when heâs on vacation, but is that the most important responsibility?Â Can you train on these skills when needed? Do they need to be a deal breaker?Â Having a clear understanding of what you want is key to having good options.
3)Â Â Â Do remember that youâve been a jobseeker in the past. Â
Use empathy, and look at your hiring process: Does it make sense? Â Is it fair and logical to the candidate? Â Are you showing them what you have to offer? Â Ask yourself: why would a developer want to work here?Â As much as youâre qualifying a candidate, theyâll be qualifying you!Â Do your best to create a positive impression.
4)Â Donât turn your interview process in to a final exam. Â
Youâre trying to find out if this developer can do the necessary work for your companyâ¦ donât ask trivial questions on OO design patterns or trick semantic questions unless it serves a purpose! Â Throughout my career in recruitment, Iâve seen these kinds of exercises utilised to weed out great candidates and keep in the wrong ones.Â Remember, youâre trying to assess if they can be a good developer, not a good member of your weekly trivia team!
5)Â Donât focus on the unimportant.
This might be an unpopular opinion, however in most development roles, communication and presentation skills are rather overvalued. Â Remember that old maxim: âDonât judge a book by its cover.â Â Unless your developer needs to be client facing, you probably donât need A+ skills in these areas. Â Also, make sure youâre screening these things accurately. Â In my experience, phone communication is not an accurate reflection of a candidateâs communication skills on a day-to-day basis.
6)Â Do prioritise culture fit. Â
Iâm not saying you should hire an unqualified person because you like them, although it is terribly important to understand the environment your company operates and whether this would be an ideal fit for candidates entering the company. Â If youâre an unstructured, very independent environment, someone who craves timelines and strong authority will have a tough time fitting in. Â Can the candidate succeed in the structure you have?
7)Â Do define your timeline and be willing to speed it up for top tier talent. Â
Yes, youâre part of a great company and people would love to work there, but chances are if you have identified good talent so have other organisations. Â If your process takes weeks to progress, youâll lose people unnecessarily. Â Before you start hiring, know what steps need to take place and map out a schedule that works as concisely as possible. Â
8)Â Donât think a coding exercise is the only way to judge candidateâs.
Most developers have a portfolio or github where they can demonstrate what they can do. Â You can learn a lot by looking at their code and asking pointed questions about why certain decisions were made. Â You can also learn if itâs code that youâd be willing to look at on a regular basis! Â Coding exercises have a place in the process, if theyâre designed correctly, but can weed out a guy thatâs already producing awesome work 80+ hours a week for his current company. Â Does he really want to spend 5-10 hours (or more??) on your test?
9)Â Do move your âstoppersâ towards to front of the process. Â Whatâs a stopper? Â
The step in your process that âchews up and spits outâ the majority of the Â candidates. Â There is absolutely no point in going through five rounds of interviews (and who knows how many man hours) just to have 90% of candidates fail the technical test/the meeting with the head honcho/the culture meeting with HR. Â Iâm not saying to have your CEO do every first round interview, but if sheâs your stopper, donât let her be the very last step. Â
10) Donât be unrealistic. Â
Youâre not going to get a rockstar/ninja/whatever buzzword front-end engineer with an outgoing personality and client-facing skills for $65K. Â Get real, and know what youâll need to pay to be competitive.
11) Donât come to the table with preconceived notions.
If youâll only hire people whoâve already worked at a Brand Name Company, or graduated from very exclusive University, youâre limiting your talent pool unnecessarily. Â A developer is more than their pedigree. Â If they have glowing references and prodigious work behind them, consider giving them a shot.
Above all, remember that youâre hiring a person - not a coding robot. Â Be transparent, flexible and realisticâ¦ and attempt to enjoy the process!
Do you have any tips to share or disagree with any of those outlined above? Â We would be keen to hear your thoughts in the comments below.