You’re working your ass off to grow fast.
You need to build your product, add features and scale up, fast…
but now you need to recruit yourself a developer. A damn good one!
Here at Applied, we’re on a mission to help you hire the best, which is why we’re bringing you this straightforward guide to bagging your first dev.
Knowing what to ask and what you should be looking for is no easy feat. So, we’ve gone ahead and taken the guess-work out of dev hiring.
1) Start with an INCLUSIVE job ad - don’t deter the best devs
Before you google ‘software engineer job description’ - STOP!
Not all job descriptions were created equal.
You want to attract the most skilled developers, not scare them off or let them scroll past your listing.
The words you use in your ad can influence who applies.
If you want a broad, talented candidate pool (which you definitely should!), make sure your job ads are gender neutral, inclusive and high converting!
Some words are masculine coded, whilst others are feminine. Masculine words will put women off from applying. However, this doesn’t work the other way around (men will still apply to feminine coded ads), so aim for either a neutral or feminine coded job description.
Masculine coded words to avoid:
P.S. we actually built a free bit of tech for this - our JD Analysis Tool
The number of must-haves can also stop women applying. Ask yourself if your ‘essential’ requirements are actually essential. We bet at least a few aren’t.
Evidence shows that men will apply for a job when they meet 60% of the conditions, while women only apply if they meet 100%.
Being inclusive doesn't just apply to gender either, swerve any mention of years experience or academic achievements unless completely necessary (and even then, you should still ditch them).
Sounds daunting, we know, but trust us, the most talented developers might not always have the background you’d expect.
Here’s what your ideal job ad should (and shouldn't) look like:
To get devs - skilled devs - to apply to your job ad, you should be as explicit as possible around salary, location, flexible/ remote working (especially relevant to devs) etc. Set the right expectations and be transparent, these factors could be the difference between recruiting or losing your star developer.
Your job description checklist:
- 300-800 word count
- Only necessary requirements
- No mention of years experience
- No education mention
- No excessive jargon and acronyms
- Set right expectations: salary, location, flexible working etc
Not sure where to post your job description? Download our Job Board Report 2019 to arm yourself with some extra recruitment ammo.
2) Don’t trust CVs, ask work sample questions instead
CVs aren’t predictive of a candidate’s ability to do their job. So why are we still using them?
It's easy to get caught up on someone’s impressive sounding degree. That doesn’t make them the best person for the job. And it doesn’t mean they’re more skilled than other candidates. In fact, 2 in 3 developers taught themselves how to code.
Plus, there’s also the fact that a quarter of applicants LIE on their CV (very naughty).
We don’t expect you to take stabs in the dark, but we do recommend blind hiring.
Instead of asking for a CV and BS-laden cover letter, we ask candidates to answer what we call ‘work samples’.
This replaces the not-so-trusty CV with job-specific work sample questions (with around a 250 word limit each).
And guess what… they’re actually predictive of skills. Don’t believe us? Check out the chart below, based on a Schmidt & Hunter study:
Here’s an example of a work sample question we ask Software Engineer candidates:
"One of the team has fallen behind and you think you’re going to miss a deadline…. what do you do?"
This gives us an insight into how candidates would communicate and collaborate within our dev team.
If you’re going to give candidates a coding challenge, keep them short, sweet and relevant!
The best and most in-demand developers won’t do your 3 hour coding task if they have other offers.
You’ll also want to have an idea of what the perfect answer looks like. That way you can easily grade answers and see which candidates you’ll be interviewing.
If you need a few extra questions to get going, one of our trusty engineers, Hew, wrote a blog post about our process with more work sample questions for you to get inspired by (or just steal, we don’t mind).
3) Interview your candidates by testing their skills
At this stage, you’ll want to get a feel for how candidates work and communicate.
Don’t put your candidate through an assault course of coding tasks.
Try following our template and break the interview stage down into three parts:
Talk through a real project your business has, or is about to work on. Get the rest of the team involved too - this is all about understanding how they approach problems as part of a team.
Communication and teamwork are overlooked skills when hiring developers. Most projects you’ll be undertaking will be done by the whole team, not a single dev, so being able to tackle a task with the team is an essential skill.
Have candidates work with another team member to solve a problem. This should be a short task to see how they work with other developers… and not a deep-dive-into the-matrix-style code-a-thon.
Here, you’ll want to see clean code. What does this mean? If the code is clean, you should be able to work out what the candidate was trying to achieve, without having to pore over it for hours with a 1000 page companion textbook.
Since building your beloved product is probably going to take some collaboration, you want a dev that can write code others can understand without wanting to bludgeon them to death with their wireless keyboard.
As we’re sure you’re already aware, developers are humans too, and not code-spewing androids. Ask them about their interest in your cause, what they want to learn, what they’re looking for etc.
Note: DO NOT MAKE YOUR CANDIDATES DO A WHITEBOARD TEST. They are prehistoric levels of old hat. Developers hate them. Plus, it gives grads (likely doing white board tests left right and centre as they ping off a barrage of applications) an upper hand over more experienced developers, who may be a little out of practice.
Again - the better you outline what a good, bad and ugly (hopefully it won’t come to that) answer looks like, the less head-scratching will be required when it comes to crunch time.
Having a clear criteria takes the guess-work out of hiring and negates any biases that might’ve been whirring around in your head - unconscious or otherwise…
*A shared love of Starcraft or a lip-smacking sushi spot shouldn’t be a factor in any hiring decision.
4) Get a second opinion, then make your decision
Two heads are better than one, especially if you’re not well-versed in software development.
Get other team members to jump in on the interviews, or at least review candidates’ answers to work sample questions.
The more people you get involved the better, according to crowd wisdom - the rule that states combining answers from a diverse crowd produces better results than a single individual.
To get the most unbiased, accurate assessment of your candidates, we recommend at least 3 reviewers.
If you gave yourself scoring guidelines for each of the stages above, give yourself a pat on the back. You should now know who to offer the job to!
That’s why we recommend deciding the skills you’re looking for before cracking on with the hiring process (as opposed to the all-to-common tact of ‘winging it’).
Conclusion: Use this structured process to hire the best developers out there
Hiring developers isn’t always easy. Especially if you’re still yet to pop your dev-hiring cherry.
Rambling, daunting sounding job descriptions and labyrinths of hurdles and hoops to get through have given tech hiring processes a bad rep.
The key to uncovering talented developers is to be STRUCTURED.
Ask all candidates the same questions, have your scoring criteria laid out before you begin and you’ll nab yourself a talented developer - without breaking a sweat.
Here at Applied, we’re on a mission to help teams hire the best person for the job, using behavioural science and data, not gut instinct. Ready to learn more? Why not request a demo?
Psst. we also know a thing or two about hiring developers - which is why we created a comprehensive guide to hiring tech talent.