How to Hire Developers III
Some specific tips for designing a technical test for your candidates.
Part 1 explores the idea that every developer should be able to interview candidates and Part 2 explores some more general guidelines for hosting an interview. The third and final part goes into some specific guidelines for creating a technical test for the candidates.
Technical testing guidelines
Although these days, I prefer homework assignments, leave it up to the assigned team member to choose their prefered method of testing the technical chops of the candidate. In order to make a good decision that they will stand by, people need to do things their own way.
Still, that doesn’t mean you just give them the keys to the Ferrari and hope for the best. Here are some wide boundaries and general guidelines to give out (along with the keys), leaving the details to the individual team member to decide for themselves:
Above all, you’re looking for someone you can work with
Discount neither the human nor the technical aspect of a candidate:
Maybe the person doesn’t have all the coding experience you expected, maybe they didn’t score a perfect 10 in your math test, maybe their style is just different. But if you think you can work with them, if they show potential, if you enjoyed their company, found them interesting, saw a spark… go back for a closer look or get a second opinion. Smart and open people can learn new tech, work in a team and adapt to new styles — don’t discount them based on what a machine told you.
On the other hand, this doesn’t mean you just hire people you like, people who make you laugh or people who give out compliments. There is always going to be a technical bar that must be maintained. But perhaps there is something wrong with your test. If you find that you get a gut feeling that the person is ok, but they don’t pass your technical test — get a second opinion. Give them a colleague’s test instead.
Lastly, if they are a rock star coder with a cocaine habit or an arrogant a-hole with a thousand stars on their Github repo… not interested. Cowboys work best alone.
Be clear in your expectations
Spend a little more time on the instructions for the test than you think is necessary, and get the opinion of another team member. Most devs are consumers of requirements and despite being on the receiving end of bad requirements for years on end, dev’s are actually no better at producing requirements than anyone else.
Requirements are always vague, time boxes always overrun, specs misinterpreted, and expectations overestimated. Take a leaf out of the Agile cookbook and encourage the candidate to check in regularly (whether it’s a homework assignment or a whiteboard interview) and be available for them. This prevents the candidate from interpreting the requirements as gospel and polishing it endlessly to impress you. Or worse, beating their head against a wall all weekend only to realise later on that you made a mistake in the requirements.
Be mindful of the applicants time.
For a take-home assignment, around 4 hours is a reasonable amount of time to ask for. Be clear that you want to be mindful of their time, they can simply write in plain English what they would have done given more time. You can also use the take-home assignment as a basis for some in-person pair programming in the second stage of the interview process.
Don’t give them real work
A UI/UX designer colleague once had a ‘take-home assignment’ which was: “Take a look at our home page and tell us what you would do differently.” Sorry, Chet, that is what I get paid for, you don’t get that for free.
Make it something fun, something interesting, something creative that they aren’t going to mind spending their Sunday working on.
Make sure that you have completed the test yourself!
A long time ago, I was tripped up once when an applicant slumped their shoulders and gave up on a whiteboard challenge. He despondently asked for the solution, and when put on the spot, I drew a blank. Soaking with back sweat, I swallowed my pride and admitted I was drawing a blank too! We looked up the solution on the internet together, worked through it and had fun doing so. I ended up hiring that person, but it was an incredibly embarrassing and unprofessional moment. Don’t make the same mistake!
Don’t give anyone a task that requires them doing something from scratch
There is far too much time involved in setting up a project, and it breaks the ‘respectful of their time’ rule. Create and maintain a project on Github that they can clone and create one or more pull requests on.
Take home assignments/pair programming sessions should be as close to the real thing as possible
Don’t test the wrong thing — asking an Android developer to re-write a sorting algorithm is unrealistic. In the above mentioned Github project, try to use the same styles and architecture as in the real project and give a set of tasks to them for completion, small ones, big ones, bugs, features, refactoring… and ask them to choose whichever issues they like, or create new ones!
That’s all folks. Hope you enjoyed the series. Love to hear your ideas and options!
