How to Interview Programmers

This is a great post chalk full of many excellent hiring tips for technical roles. Although I'm curious, you mention 2 to 4 hours of "programming challenges" as a component of your 'on-site interview'. These are followed by paired programming sessions (presumably several of these) involving debugging with team members --say, 1 to 2 hours? This, along with the usual meet and greet chit-chat/Q&A and walking tours of the office. So basically you're asking short listed candidates you've identified as "qualified" to spend an entire day with you and upwards of 5 hours demonstrating their programming and problem-solving skills.

This sounds excessive.

Your company must have unlimited resources or incredible cash flow to be able to invest an entire day on each candidate and then pull team members off "paying" tasks and projects to prepare mock programming exercises. If you're talking junior or intermediate roles, this might work. But good luck getting any senior developer with decent experience and programming chops to spend 5 hours of their day on so-called "challenges" unless you're one of the Googles or Facebooks of the world.

The only thing I think this article gets wrong is the 1 month contract idea. It is problematic for 2 reasons: 1. Often 1 month is not enough of a trial period. 2. You will lose tons of great developers who simply will not work on a contract basis.

I think the way to approach this is actually a 6 month contract with a garaunteed cash payout at the end equivalent to 6 months of contract value that you get regardless of whether the company renews the contract.

I've met Matt Rogish and he is one of the most in-tune people I've met on how technology management should work. Everything I've read of his is worth reading.