back to xpand blog

Planning to Hire Development Talent in 2014? Xpand's Do's and Don'ts Should Point you in the Right Direction!

12th Feb 2014


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.