[ad name=”Leaderboard”]

This is a part of a series on Hiring Techies.

Coding Challenge

Of course, if I’m evaluating a candidate to join my team I want to ensure that they know what they’re talking about. There are many ways to do this. Some people slam a candidate with technical questions for hours. Some people choose to do a whiteboard session solving a problem real time.

Like most, my preference is to go first through a short technical phone screen. If it’s obvious that the candidate has the critical skills we need, I’ll send out a coding challenge to be completed within the next few days. This is a short but non-trivial set of acceptance criteria – something that an average developer can complete in a few hours. Some folks balk at this request. This actually tells me a lot about the candidate and is an immediate red flag. Most candidates are happy to be given an opportunity to show what they can do and submit a solution within a day or two.

At this point the team reviews the submitted solution and decides whether or not to bring the candidate in for an interview. We make it clear that the solution that was crafted will be discussed during the interview.

As programmers, we spend considerably more time reading and discussing code than we do writing it. We need to be able to clearly explain our ideas and be willing to listen to feedback. The discussion I have with a candidate about their submitted solution will tell me more about their technical skills than a barrage of technical questions ever would. We’ll review design decisions, the application structure, SOLID principles and clean code, any technologies or frameworks used, and so on.

I also love reviewing the unit tests that were submitted (or having a discussion regarding the lack of tests). We’ll talk about TDD – why it was or wasn’t applied. It’s always fascinating to hear how the tests influenced the design.

I will very rarely challenge a candidate to solve some problem in person. The reason I don’t like to have the candidate code live is because the interview itself is already high pressure. Most of us have experienced this kind of test when interviewing. I want to see what they do when they’re at their best – not when they have a bunch of strangers staring at them. Programming isn’t about memorization. Anyone can find framework documentation online in seconds. Programming is about problem solving and I want to see how candidates think about problems.

Working code is one of the best ways I’ve found to evaluate a candidates technical skill level.

[ad name=”Footer”]