Recruiting for Skills

One of the easiest characteristics to recruit for is hard skills. At the end of the day, I need a person to code or test—since that’s what they’ll be doing all day, there’s no better way to probe than to have candidates actually code. I was a bit surprised during my recruiting in India to see how many companies administer a coding question in the form of a seated, written test—there’s probably some value in that, because it does allow the candidate to prove their skills but a written test is such a sterile environment. When I probe for coding, I’m looking for a couple of things at once: can a candidate break the problem down appropriate, can they get the right logic, are they looking to refactor or improve their code, and are they thinking about performance or scalability. In a written test, the candidate does all that thought in a vacuum – all I get is the final code. So a written test can be used as an initial weeding out, but don’t rely on it as the sole measuring stick.

In an interview, I’m dealing with limited time—usually 30 to 60 minutes. Because I don’t have all day to get through a question, I need to pick something that will let candidates demonstrate as many skills as possible. I have, therefore, developed a few standard requirements. First, if I’m interviewing for C or C++ developers, my questions do not allow candidates to use outside libraries. I once had a candidate yell at me – literally – about that restriction, but I don’t care. Anyone can consume a library – but can they write clean, elegant code on their own? I often ask them to implement a library—for instance, one question I like to ask is reversing the characters in a string (I usually throw a twist in that, such as reversing the characters in each word while preserving word order). There are some very simple bars to measure by – does the candidate use pointers or temp arrays? Memory isn’t constrained any longer, but a clean coder is still concerned. How complex are their logic statements? Are they nesting double and triple negatives together? Do they over-complicate things? Are they getting lost in their own algorithms? How confident do they appear? Do they tackle the problem without thinking, or do they put together an approach in their mind.

I really don’t care about the solution they ultimately arrive at (for the most part). I’m mostly concerned that they write clean code, the solve the problem, and they do it with quality. I’ll take a conscientious coder who returns to his algorithm one, twice, even thrice during an interview over the cocky application who codes quickly and sloppily and just leaves the code when it’s ‘finished’.