Interviewing Programmers

We have discovered why it is actually so difficult to interview programmers. We want to know if they’ve acquired the thousand and one little lessons that add up to being good at this. And those lessons mostly consist of a sense for a good design versus a bad one, identifying the correct abstraction and the right data structure, and knowing when they have chosen poorly and how to fix it.

We are stuck with an hour conversation and trivia and a sheet of paper that often tells lies.

It’s also why the technology bingo card style job ad is just a serious red flag. It screams “Here is a company that either doesn’t know what a good programmer looks like or despairs of being able to spot one.”

Every semi-decent engineer knows they would rather hire an awesome Clojure dev to work on NodeJS than a mediocre Javascript dev. A competent programmer can pick up a new language in a few weeks. A bad one might never become a good one, no matter how many years they can put on their resume as having spent churning out messy, confused code in the language your stack happens to be built upon.