Interview Programmers Like Your Pants Were On Fire

Reading about the layoffs at Zynga, people pointed out how great the laid off workers would be to hire, because they had a very rigorous hiring process.

I had to laugh. What a waste of time and energy to spend long hours interviewing people trying to find "rock stars" and then getting rid of them not long afterwards. The longer you take to interview your programming team members the less useful it becomes.

Yet I know a lot of companies seem to revel in full day or even multi-day interview processes, trying to eliminate even the tiniest chance that the person won't be Nobel material. A programmer I know was interviewed at Microsoft so many times, all of them long distance travel, he virtually lived there. I was interviewed with travel for a contract position of all things: 8 serial interviews with different people.

It's ludicrous to imagine that so much energy, especially on the part of the interviewers themselves, could possibly be worth it. As I've written many times before if you can't discover everything you need to know about a candidate in the first hour, then you aren't do it right.

Why do I think that's sufficient? Contract-to-hire. You cannot discern how someone will fit in, contribute and be a valuable addition to your team under some artificial circumstance. The only way you can really know is to have them work with you and next to you, sitting at their desk and using whatever computer, tools and language you use. Not in some test but doing real work like everyone else on the team does for long enough that their skill and ability becomes discernible.

I hate when people bring out the old saw (yes, it's a pun) that "you wouldn't hire a carpenter without seeing if they can hammer a nail?" Programmers are not carpenters. We work in teams on projects, interacting with designers and QA, under some kind of management or development process, and dealing with tight schedules and maybe even tough decision making. Thinking you can figure out how someone will do this by making them reverse a linked list or distribute gold to pirates is nuts. I don't do that all day; in fact I never do that (if I had gold I'd keep it all and go home).

The big down side to doing long interview processes is that the poor programmers who have to do the interviews wind up wasting valuable time sitting in rooms talking all day instead of doing programmer things. I've been in places where I had to interview so many people I felt like making the next interview my own at some other employer. Most programmers rank interviewing slightly above 8 hour meetings.

When I had the 8 serial interviews, one guy went home and another simply refused to do his slot leaving me talking with some HR guy for an hour. None of the programmers read my resume and none of them knew much about the need (Java Swing) so mostly we chatted about random stuff. They had done several of these that week and were simply tired of the whole process. I didn't get the contract which was just as well as two months later the whole division was shut down having lost a billion dollars or something. I think one guy could have asked a couple of questions on what I knew about Swing and that would have nailed it (not much). They could have done it on the phone.

Obviously you need some reasonable phone screen system to weed out the completely pointless, but in-person should be as minimal as possible. A mid or senior level programmer should be able to talk like one, being able to expound in detail about anything on their resume. As along as they can talk the talk, the whole point of contract-to-hire is you can see what they can do, and if they can't you can generally drop them on the fly. At my present job we had six months contract-to-hire for programmers, and after 4 months I was hired full time, as everyone knew I could not only do the work but do things they didn't know I could do. It's not rocket science. I had one interview of about an hour and spent most of it explain how ARC worked in Objective-C.

I've said this before as well, if you measured the quality of the ultimate work between a long interview process versus a short one followed by contract-to-hire, the latter would be a far better measure of any candidate. Plus, your existing team would be much happier as well!

Sometimes I wonder why Zynga spent a lot of effort hiring people who would then write yet another clone of Farmville. Maybe it's tougher than it sounds, but having worked on a physically modeled MMO FPS type game I have a hard time imagining it. I almost interviewed there once but it didn't appeal to me as they were still doing mostly Facebook games at the time.

If I ever have to be in such a ridiculously long interview process I'd probably decline or just point out my many blog posts on the subject. Sadly only one time did anyone actually take the time to read this blog, and they offered me the job basically on the phone; the one in-person interview consisted the two other architects taking turns trying to scare me with horror stories about the job. These days you can tell a lot of about people by what they do online like blogs or open source projects. It's worth it to check this kind of stuff out up front.

It's even good to read a resume before you meet the person, another thing that happens rarely because the interviewer is sick and tired of interviewing. Why waste everyone's time with days of torture. Rarely if ever is any programming job going to involve rocket science or death rays where you need an Einstein Von Braun. Most of the time you need a good team member who can contribute.

So go ahead and keep it short and let them prove themselves in real work. Like going to that 8 hour long meeting!