Interview Technique: A Topdown Approach

Having spent too much of life on both ends of interviewing people (mostly as the interviewee lately) I've seen and experienced a world of different styles. The intent of a first interview is usually to separate the ditch-digger from the real coder.

Most of the interview techniques suck.

Interviewers often begin with asking the interviewee about programming basics, to describe object-oriented programming concepts, to describe simple language constructs, or the like. The assumption is that the ditch digger doesn't know anything like that. Of course, an experienced programmer might be good at coding but not be able to answer theoretical questions, or be good at complex concepts but spend little time with language or framework features that the IDE takes care of. Basic knowledge is also no guarantee they know how to use it. I once new a guy who aced a Java Certification test but was utterly incapable of writing even the simplest actual program.

So, OK, you say, it's just a phone screen. Now we will make them take tests, talk with some managers, perhaps solve some Pirate Puzzles or even survive a battery of intense interviews from bored (and sometimes cruel) developers. Then we will sort out the tired, the poor and the huddled masses, oh wait, wrong concept. We will then hire the brightest, smartest person in the world!

Yet after all this massive effort on the part of many people in the organization, you still wind up with programmers who are average or worse in delivering real applications.

Clearly finding the right people is more of a crapshoot than most companies would admit to. The one thing you really want to know is "will the candidate be able to write functional code, deliver it in a reasonable time, with good quality and maintainability". Sadly that's the hardest thing to figure out without actually hiring them and seeing how well they do. I do see more people these days doing contract-to-hire.

In my experience on the hiring side, the quickest type of screen to see how well they might function in real development is to pick a random entry in their resume that appeared to be significant, and ask them to describe the requirements, the technologies, the choices, the history and what their precise role was. The assumption is that someone who actually did a real project could describe it in great detail. For me, I can still remember all the details of virtually everything on my resume, since most of them took months (or in couple cases years) out of my life. It's is very hard to riff some random details and fool a competent engineer or even manager. I want to know how intimate do you know something you say you did for a fairly long period of time, even if it's a few years in the past. You may forget the syntax or some method calls, but not something that you spent months doing.

The process of programming is a lot of little details, many of which have to be mastered and reused in most projects, even as the technologies and environment changes. Dealing with managers, requirements, plans, code management systems, testing, QA, debugging, making choices in tools or frameworks all are things you do in most projects but the details change. I want to know how the candidate thinks about the work of programming, and how they have done more so than some intimate details about a language or tool or API. These things change from time to time, the ability to actually deliver does not.

I think very little of the bottom-up approach that many companies take. They focus on weeding out the ditch-diggers and then hope some deliverers survive. I would rather find the deliverers and let the others weed themselves out.

Of course this isn't a perfect solution either, nothing is short of having people work for you for a few months and see if they can deliver. I would rather know that a person can articulate what they have done on projects and understand the process of delivery (which of course means designing, coding, testing, debugging and understanding what to do) and work the interview from that perspective.

After all, no one ever asks a ditch digger to define dirt, they want to know if they can dig it.