

How to Interview Programmers - MattRogish
http://mattrogish.com/blog/2013/06/26/how-to-interview-programmers/

======
Djonckheere
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.

------
kasey_junk
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.

------
michaelochurch
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.

