If You Interviewing Programmers Like This, You Are Doing It Wrong

The best job interviews I have ever been on have been simple chats between peers. Yet the trend today (especially in big companies) is more like 24 hours of hell.

Give me a few minutes of prep time, a single hour at most, and I can tell you if a peer programmer or architect candidate for a job is worth hiring.

That said, if you want to work for Google, Apple, Amazon, Microsoft or a host of other big name companies in most cases you will be in many interviews with a host of people. From reading the stories of interviews (there are many site devoted to this topic) you can see that the interview process of today is often way out of control. It appears as if companies are so fearful of making an error in the hiring process that they think that sheer quantity of interviews will weed out all but the most perfect programmer employees. If the process is so painful and intimidating that only potential Nobel prize candidates will survive then the company will produce perfect products with nary a bug to be found.

Bullshit, I say. Donkey-doo if you like it kinder, gentler.

Having been on both sides of the equation I have seen all the variations over my 30 years as a professional programmer.

My first job interview at General Dynamics was a single manager. I had no paid experience programming or even a degree in it (but did have almost a Masters in Chemistry) and he asked me a explain a few programming questions which I was able to in about 30 minutes. I got the job based on nothing but that.

For my startup (that built Trapeze) I interview two friends over lunch. Ever noticed that the most important employees ever in a startup are usually people known to the founder? Those first few programmers determine the ultimate future of the company yet almost never is the interview more than cursory - yet big companies act as if making an error in judgement in the hiring process is life or death. My rule of thumb is one hour total unless the potential for mass death is involved. Microsoft kill anyone lately with a bug?

I worked a contract at Remedy in 1994 based solely on a 20 minute phone call cross-country. Even for my contract at Apple DTS it was about an hour with two people.

My favorite interview was at a financial services company (a source of many of my most popular blog posts over the years). The other two architects took turns telling me horror stories about the company's software and systems just to see if I would run away screaming. That was years ago and today I had lunch again with one of them who is still there and it's still a crazy place. But I make a difference during my time there.

I had an interview over the phone for a rich Bay Area startup recently, and it was entirely a chat between two people with tons of experience and interests and not anything like an interview. They wanted to hire me based solely on that but the company's product was not very interesting so I declined.

But there was also the 8 interviews at a Mortgage trading unit of a big Wall Street firm, one after another, for a contract no less. I don't remember why I wasn't offered the contract (I think the other candidate was internal) but later that year the unit was blamed for multi-billion dollar trading losses and disbanded, so I'm glad I didn't work there. I don't the programmer was to blame despite the ridiculous interview process.

The point is that it's not the quantity of interview that is important, it's the quality. Many places where large numbers of interviews are required the programmers are asked to interview people constantly, which they grow very tired of. Generally most of them don't ever read the resume or read their blog or do any prep at all, as the process interferes with what they are actually getting paid to do -- program. I would bet that in companies that schedule 8 interviews with each candidate, the end result is 7 "Seems OK to me" and maybe 1 person with two sentences. Redundancy that accomplishes nothing but wasted time and money.

Of course so many interviews wind up almost the same since it's hard to be clever after your 15th interview this month. Some companies even write required interview questions or puzzles or create long forms to be filled out for each candidate. So the candidate winds up going through myriads of virtually identical interviews, writing link-list code on the whiteboard, solving pirate gold management issues, and wishing they had taken up ditch-digging instead. The interviewers range from the more common I-hate-this-waste-of-time, the occasional closet torturer, the manager with no clue, the chatty HR person, and usually ending with the long-winded proselytizer of all the technologies you don't know.

My feeling is that if you think this is just fine and it's important to keep ditch-diggers out of your programming staff so thoroughness is necessary -- do contract to hire. A month of two is more than enough time to see if they can comprehend your incomprehensibles, or dig a latrine.

Clearly interviewing students with no experience is a different matter in which all you can do is ask them to write link-list code. But senior level people are different. You can't ask them to do something mundane and expect anything that will tell you how they will work at real work. Would you hire a contractor to build a house by asking then to hammer a nail? If I asked a senior level person to write a link-list routine on the whiteboard, I would expect them to tell me how stupid this is since virtually every language/framework/environment already provides this. Even if they write it, given the large number of interview question sites out there, they could have just memorized the common ones. It's pointless. Someone who might write tens of thousands of lines of code during their stay at your company cannot be judged by one routine.

I've worked one guy who had all the Java Certifications but couldn't write one functional application, one guy who knew every buzzword in the Java universe but wrote no code in all the months I worked with them (and called himself Java God), and another smart guy who could not write a single line of code without getting everyone's suggestions each morning. Yet all of them could pass interviews with ease. The latter guy even went to NASA.

So what can you do? I can't speak for Apple (where I would love to work but refuse the process) or Google et al, but my recipe is pretty easy. Read the damn resume. If they have a blog or linked in or reference open source work READ IT. Go into the interview armed with knowledge. Then pick things in the resume that seem prominently mentioned and talk about it. Find out what they did, why the project was done, how it was managed, what technologies were used and why, things that only a person who was actively involved and paid attention would know. Ask about new technologies in the news relating to their experience and what they thought about them. If I felt a need to explore what they know ask everyday working programmer questions, like why would I use this data structure over that one, or explain memory management issues. In general stuff a real programmer would know or be able to explain easily. It's not rocket science - real programmers talk like real programmers and they wrote real programs that they can talk about.

I still remember almost every detail of all the stuff on my resume I spent any time on at all. Ask me about memory management (I wrote a commercial allocator library pre-OSX) and I can talk for hours. The fuzzy search engine for Consumer's Digest (long gone they never paid their bill) or even Trapeze or Deltagraph from 15-20 years ago; I can talk for hours on design issues and how it was coded and problems overcome, etc. Any decent programmer can. That's the key - if they know nothing about something they supposedly spent months on, then don't hire them. It's basic psychology -- people can talk for hours on things they are knowledgeable about, but they can't lie for more than a few minutes. If you are a prepared peer then you can tell the difference easily. You don't need all the gang interviews, the pirate gold, the manhole covers and the video coding sessions.

Plus, when you do get the job after this type of interview, you won't have to waste man-months of your life doing the pirate gold manhole linked-list tango.