— recruitment, interviews, diversity — 2 min read
Hiring should be better for you and the applicant. Here are 5 ways to improve your developer recruitment process.
I recently ran a recruitment campaign that ended up recruiting all women from non-traditional tech backgrounds. This was thanks in large part to the job description's precise and limited essential criteria. There is a wealth of research showing that underrepresented groups don't feel confident to apply to a role unless they are confident that can match all of them. Therefore it is crucial that the essential criteria is not vague or overwhelming.
Also, the job description is your shop window. It shouldn't read like a list of tasks you want the applicant to carry out. This is your chance to put yourself out there and attract the best. Put some time and effort into it.
I recently saw two job adverts, one for 'Software Developer' and another for 'Senior Software Developer'. Both were at the same grade with comparable salaries. Why? This just tells your potential applicants that you don't have your shit together and don't know who you're trying to hire.
It might be a good idea to have a single person coordinate your different teams' hiring activities so you present a united and thought out 'front' to the world.
You should sift primarily on the cover letter. For me, I'm always looking for someone who is open to learning new technologies and skills. To gather this from a CV is difficult. It also allows candidates, who may not have years of experience but heaps of potential, to shine.
Technical tests are also an area of contention. Traditionally software developer interviews have included whiteboard tests where you ask the candidate to solve a difficult problem, e.g. write a function to return the fibonacci number of a particular index. More recently the industry has moved to long form take home tests. Both of these techniques have their flaws.
Whiteboard tests are easily crammed and studied for and do not necessarily give you a real representation of the person’s coding abilities in a real world setting. Take home tests, while often more representative of real world work, require the candidate to dedicate hours of time outside of working hours to solve it. This is not ideal for candidates with caring responsibilities or other commitments outside of work and therefore can reduce the diversity of the candidate pool.
I prefer a short (30 minutes is a good length) tech test at the start of the interview. Base the test on a problem that the candidate will likely encounter on the job. Remember, you're hiring an engineer, not a mathematician. Get them to talk aloud. While it is great if the candidate completes the task, what you're really looking for here is an insight into how they approach problem solving.
Interviews often focus solely on the technical abilities of the candidates and overlook the softer skills needed to be an engineer. With some previous developers I've run into this problem where, while their technical skills are strong, they are not good team players and can cause slowdown and disagreement within teams. The importance of soft skills in engineers is widely recognised in the industry.
In order to test soft skills you should try to find out things like:
For roles with more leadership responsibilities, also: