Most tech companies looking for developers are incorrectly screening candidates for their available positions. If you think asking developers to solve theoretical problems on a whiteboard or calculate how many soccer balls you could fit into a football field, you are definitely doing it wrong.
A realistic hiring process
To hire great developers you need a realistic hiring process in place. Ask yourself before you interview a developer, what the developer will be doing, what his or her day-to-day tasks will be and their responsibilities.
For example if you are hiring a web developer their day-to-day might look something like this:
- Prototype ideas quickly and then implement
- Cut up PSD files into CMS templates, HTML and implement to an existing system
- Implement new features into an existing website/application
- Develop responsive mobile-first websites
- Work with one or more server-side languages like PHP
Once you have a list of tasks the developer will have on a daily basis, you can then frame the right questions and process.
I believe pair programming is one of the best ways you hire great developers. Sure, candidate A might not have a computer science degree or worked anywhere notable, but via pair programming you will be able to determine their capability and skill level very quickly.
If you are not familiar with pair programming, it is where you pair a developer with another developer to solve a problem. Pairing up a potential candidate with an existing developer within your organisation and have them help solve an actual problem you are having will be a great test of their people skills, problem solving skills and communication skills.
If you don’t have the luxury of utilising the pair programming method, the broken code approach is another great way to screen developers. Take a piece of existing code you know works, break it deliberately and then ask the developer to make it work again.
Possibly the second most time consuming task you can ask of a candidate to that of pair programming is asking them to build something. Give them a brief, a basic example design and then see how they interpret that brief and what kind of solution they come up with. You could ask them to build a fictional client website, a multi-step quote form with datepicker or something more advanced like a custom blog.
Just because a developer can solve a problem on a whiteboard doesn’t make them a great developer. If they work well with others, can solve problems using code and deliver results, the above aforementioned means of testing are probably more accurate than puzzle questions.