The Evidence of Absence

Posted on Posted in Blog


At iTrellis, we feel really good about how we hire software developers. First and foremost, our process does *not* include whiteboarding. We want our process to focus on how well the candidate codes, and to work from real-life code that they’ve actually written. To get this, we ask people to submit a code project. We recognize that there are almost certainly some shortcomings associated with this process, but so far it’s worked pretty well.

Recently, I had a “Eureka!” moment while reviewing a project submitted by a junior candidate. Fortunately for my co-workers and the other tenants in our building, my moment did not go so far as to include the running naked through the streets part of Archimedes’ enlightenment, but still – the onset of awareness was sudden. I as looking at a piece of unnecessary, convoluted code, when the lightbulb went off:

I want to hire people who know when to not write code.

Now I know that the reaction from many of you will be, “well, of course,” which is what immediately followed for me as well. It’s so obvious, but it’s easy to overlook. But what prompted this insight was that I had just minutes before rejected a candidate for… not having enough code. In retrospect, they had exactly as much code as I would expect from an experienced developer – which meant that their overall code project, done exactly to the letter, felt skimpy and lacking.

After discussing it with another reviewer who had also rejected the candidate’s project, I still think that we made the right choice. Maybe we were right on the bubble, but there are other things that we typically see in the submissions from more experienced developers (a good ReadMe or other documentation, thoughtful tests, a commit history, separation of concerns through (at a minimum) namespaces) that were completely lacking in this candidate’s project.

As a subculture, software developers tend to value ‘clever’ as well as ‘elegant.’ This was a good reminder that sometimes those attributes manifest in the code that we don’t write as well as in the code that we do.