Weíve all heard the usual jargon about how competitive the marketplace is. So, letís presume that when interviewing developers you need to be as competitive as possible. All based on my own experiences with candidates and clients, these are a few ways you can immediately improve the process:
The speed at which you recruit will be a key factor in your success. Quite often a candidate will have many great opportunities on the go at the same time and considering all other aspects are equal (salary/location/tech stack) the speed the business moves will be one of the defining factors.
There is nothing more flattering than a business giving feedback on an interview almost immediately after the event; that positive perception will go a mile when it comes to the individual making a decision.
Finally, limit the amount of stages in the interview process. If you have more than three interview stages, then you should look for ways to shorten that process. I have had candidates refuse to interview for 5+ stage processes. If possible keep it to one telephone session and one face to face session.
Sell your EVP
EVP stands for employee value proposition and knowing yours could be the difference between an accepted offer and 4 weeks of pain.
The key is to be specific and to show it to the candidate wherever possible.
- If your people are your USP, get candidates to meet and interact with them
- If your perks are your USP, remind candidates of them at every opportunity (stuff to shout about includes: remote working options, unlimited holidays, free food, extra-curricular activities)
- If your office is your USP, then give them a tour of the space
Need some inspiration for improving your EVP? Here are some great examples Iíve heard from our clients.
The illustrious technical test. There are many pros and cons to this. Studies have shown work sample tests to be the single best predictor of overall job performance. However technical tests or more specifically, take-home technical tests are also a major culprit for candidate drop-outs.
Simply, this drop out can be attributed to the amount of time these tests take. The shortest take- home technical tests require the candidate to give at least an hour to the problem and more commonly 2-4 hours.
In-person technical tests are a different story and can be a great way to see if someone can actually code. If you are able to provide a room with a PC or a laptop to complete a test and then follow it up with a code review this is an excellent way to not only see their ability to produce clean code but also understand the way they think. Whiteboard tests are a good alternative as long as the interviewer remembers that whiteboards donít come with intelligent code completion features.
Tips: If you are to use a technical test, try to make it an in-person technical test as part of an interview. If you require a take-home test, keep it as short as possible and try to make it integral to the process instead of another hoop to jump.
Return to view news articles
On the 6th December 2017 Sanderson hosted their 7th annual client Christmas party at The Darwin Centre at Natural History Museum.