In part one, I discuss some of the problems I see with the currently-fashionable puzzle/testing interviewing technique.

Software engineers as engineers

My reaction to the puzzle/test interviewing style: If you are looking for an engineer, you should be interested in knowing how well they 'engineer', not how well they tap-dance. Engineering is a discipline that involves thought, reflection, and sustained effort.

So, unlike juggling or tap-dancing, which involve reflex and muscle memory and very little in the way of thought process, I am skeptical that one can rely solely on such a test of problem-solving acumen.

How would you interview a building architect? Ask him/her to design you a building on the whiteboard while you check your email? What would that test prove about the architect's *true* ability? (I admit it might provide interesting opportunities to learn how the architect's thought processes work, or provide opportunities to talk thru some problems, which *is* a potential and oft-touted benefit of the whiteboard interview model.) No, I suspect you'd want to see the architect's portfolio, some prior work samples, check references, discuss what you wanted the architect to do, and have the architect come back with some proposals for you to review.

Why can't we interview software engineers in a similar way?

Preliminary interview: See if the engineer is alive and breathing and can communicate, check out the portfolio, and see if things seem like a good general match.

Do you like the candidate, and think he or she would fit the team? Move on to a secondary interview: Give the engineer a problem to solve that is somewhat applicable to the problems you expect the candidate to solve. Now, the important part: Send them away, ask them to come back with a proposed solution, and *then* you do the technical interview. Tear into the solution. Walk thru it. Ask questions. You'll find out pretty damn quickly if the candidate has his or her act together, and if the proposed design / implementation strategy is solid, or if they plagiarized it, etc. You would also find out how well they communicate: if they didn't get everything they needed in order to come back with a design, did they ask followup questions?

I can think of lots of reasons why this style is not used (practical issues, mostly, but also some possible legal issues) but I still wonder why most organizations favor the 'blink' style of interviewing rather than trying a more substantive style that involves thought and preparation for both interviewer and interviewee.