Out of the thirty applicants for our web developer opening, one man stood out. His resume impressed, his code was clean, and he didn't seriously offend anyone during his time with us. That man is Chad Cunningham, and he's one of us now.

Seriously, congratulations to Chad on his recent hire.

As awesome as Chad is, I'm going to rant for a while about our awesome developer-driven hiring process!

Most companies have the standard "management-driven" hiring process: essentially, management (or management's agents in the hiring world, the HR department) handles the process of putting up a job ad, filtering resumes, interviewing candidates, and making the final decision as to who gets a job and who doesn't.

Maybe that's a great way to do it if you're a super-large company, but Innova isn't, so we don't play those kinds of games. We're small yet (Chad is No. 11), so we leverage that when we hire people.

First, we gather resumes like any other company. I like to think my awesome ad is a step-above the rest in terms of getting eyes onto your job ad, but that's neither here nor there.

Then, we filter out the spam and the obvious rejects, and we have Kent phone up the remaining candidates. Those that pass our quick little "can you do these things to our satisfaction" questions are progressed to the meat of the interview: the Code Day.

We ask the candidate to take a day and come into our offices. We give him a spec, a cubicle, and a machine. The candidate is to create this application somehow — we don't care how. Most of the candidates choose PHP since that's what we use for the bulk of our work, but we've had people try others, notably one done in Python / GTK and one done in Delphi.

The entire team helps out here. I sit close to where the applicants usually sit and so I'm their main go-to if they have problems with our servers, or code compilation issues or whatever. Eddie usually walks them through their application design, and Bruce usually walks them through their database design. And we encourage everyone to stop by the applicant's station and say 'Hi', check up on progress, whatever. We also encourage the applicant to eat lunch with us, although they might decline if they want to keep working, we don't dock them if they choose to hang out for an hour with some food.

After about eight hours with us, we stop them. Everyone gathers around and the applicant demonstrates his program. We essentially collaboratively review his code: ask about problem areas, identify the general design by reading his code and watching it work, and ask him to defend any questionable decisions. Everyone (with the exception of Eddie) takes care not to be too harsh on the candidate. After the candidate leaves, we usually spend a half-hour to and hour discussing whether or not he fits in. We discuss how good his code is vs. how good we thought it would be based on resume and phone interview, but we also judge if the candidate would fit in socially, which is almost more important. Bad programming practices can be fixed; bad personalities matches usually cannot. And that's it. Chad presented a good resume, passed our phone interview with flying colors, came in and turned in some awesome code, and fit in with our group enough that we wanted to work with him. In the end, the entire team knows what it's getting.
This is the kind of experience you just don't get with the normal management-driven interview process.