#code tests

I've been off the job market for a little while but I've been thinking about it lately and wanted to share some of my frustrations. One thing that irked me in particular were the code tests. Somewhere along the line it became standard to challenge a candidates abilities in person during an interview.

These technical evaluations are typically in the form of pair programming challenges, riddles, code problems, even written tests! You may be thinking "Well if a programmer is good they should be able to do fine on the tests!" Wrong.

Here are a few of the big problems with on-site testing:

That awkward feeling of being watched

You don't typically write code with someone looking over your shoulder. It can be very nerve wrecking and greatly skew your perceived skill level.

Who codes on a white board?

During many technical interviews I have been asked to solve a programming challenge on a white board. First off, my handwriting is atrocious. Kind of hard to solve a problem when you can hardly read what you're writing. A white board is also really awkward for writing code. If you're not an experienced white board programmer you're certainly going to slip up here.

You are out of your element

A couple years ago I was doing a technical interview and was given a crappy IBM laptop, told to sit in a conference room and solve a coding challenge that was written up in a text doc. The whole experience was extremely awkward. I use a particular browser, IDE, OS and specific tools that have become integral to my workflow. If you take those away from me, obviously my results are going to suffer, especially in the speed category.

Most interviewers ask the same questions

The last time I was interviewing, I began encountering the same questions over and over. When this happens, the questions no longer have anything to do with skill level or critical thinking ability, they just become a game of memory. I've literally been handed a job offer during an interview after solving a couple puzzles which I had failed that same day at an earlier interview. I just don't do well under that sort of pressure, but once I had time to work them out on my own, I aced them.

So how do I find the right engineer for the job?

Review their Github

Any programmer who wants to be taken seriously on today's job market should have a flourishing Github. It's an easy and painless way to get a quick and overall sense of the candidate's history and technical ability before even scheduling an interview.

Hire for culture

Sure it would be great to find an engineer who really knows his/her stuff and can write amazing code, but if no one gets along with them, they have no passion for the product and aren't excited about learning new technologies, how long would you really keep them around?

Instead focus on hiring great learners who mesh nicely with your team dynamic. Personalities can't usually be changed, but coding skills can always be learned.

Give them an assignment

There's no harm in giving the candidate a coding task. This is something they can complete on their own terms and timing. Afterwards you should be able to review the code and get a great view of the programmer's abilities.

Passive testing like this is so much better because it allows the candidate to complete the assignment in their own environment, in their own time, which inevitably leads to higher quality engineers.

It doesn't have to be anything super complex, time consuming or challenging. It's just to get an overall picture of the programmer's level. Is their code dry? Are they writing less code wherever possible? Are their comments smart and useful? These questions should be easy to answer after the assignment is complete.

Conclusion

You should be striving to hire smart people who are fast learners, if you do this the rest will fall into place. The best way to determine this is by engaging with candidates to establish cultural fit and by examining their engineering history to determine their experience and ability to learn.

Couple this with an at-home assignment and there's no reason you shouldn't be completely confident in your next engineering hire!