So I took some time awhile back to pick on recruiters a bit and wanted to take a few minutes and jot down some thoughts about the technical interview process for developers.  Time to pick on interviewers, including myself for awhile.  First, you must all go read my favorite post ever about technical interviews.  You have to admit, Jason has an interesting view of the world yes?  I've interviewed at MS and it wasnt' very fun...I was poorly prepared and not in the right mindset.  I'll probably never be in the right mindset for that organization but one should still strive to minimize the number of times they look stupid in front of an industry leader.  Now, most of what I know about interview prep (for myself and others) comes from the likes of Gladwell, Spolsky, and Hanselman.  In fact, like alot of other folks I know, I spent a lot of sleepless nights up doing research when Scott started posting his "everybody should know these technical questions" lists.  And that's fine, it keeps one sharp if folks like Scott are always challenging us and thousands of tech leads the world over are stealing his questions to ask me in an interview. 

Where I break from the crowd is how I define smart and get's things done.  Remember that one?  Joel On Software gave us that little ditty in the link noted above...it even became a book!  Most folks hinge their judgement of the above cliche first on a list of trivia questions and on the use of the "impossible question", the "Microsoft question", etc.  It's the question interviewers ask so they can variously see how you attack a problem, see how your mind works, see how the stain spreads as you pee yourself, etc.  By the way, for an interesting dissection of this heuristic by Steve Yegge of Google, have a gander over here. There exists a variant of the impossible question known as the ridiculous or spurious question which essentially takes a non-problem and makes it a problem by imposing artificial limits.  For example, I was once asked to use a one dimensional array to store and retrieve two dimensional data and provide a mathematical relationship for how the two dimensional data mapped into the one dimensional array. 

Me: Well, I'd actually just use a two dimensional array for data storage and retrieval. Interviewer: Right, but I don't want you to do that, I want you to do it this other way. Me: So let me get this straight.  You, as my potential employer/boss want me to ignore tools available to me and do things the hard way whilst making implementation decisions for me at the same time?

There are two fundamental problems with the asking how many fire hyrants are in LA or how many gas stations are in Seattle or telling people to use inappropriate data structures in their code. Problem 1: They know it's coming These types of questions have been written about ad naseum on the internet.  Go ahead and Google "microsoft interview"...see what I mean?  If you are a company of decent calibre and you are recruiting individuals who have not been living in a ping pong ball for the last 10 years, they know the question is coming and they know what the expected response is.  They will have picked a number (an old statistics professor told me once that the correct answer was always 300) and will feign interest in the problem to look like a real go getter.

Me: So John Smith, work through this problem with me.  How many licks does it take to get to the tootsie roll center of a tootsie pop? Candidate: Well, something, something Dark Side of the Force and the answer is 12, give or take a million.

Notice the candidate still got it wrong...any kid who grew up in the '80s knows it's three!  The only way this situation can benefit the employer given the popularity of ridiculous or spurious questions is if the candidate is blindsided...NO HIRE.  If they had no clue it was coming, clearly they don't even have an internet connection. Problem 2: Attempting to answer is an indictment If you want folks that are smart and get things done, why waste their time?  Anyone who is smart and wants to accomplish actual work will recognize that attempting to sit in someone else's office and calculate the number of widgets in a hypothetical box is a fool's errand.  Anyone who is smart will know they're getting their chain yanked.  Anyone who get's things done recognizes the importance of a business case for getting things done.  As a rule I will avoid asking or answering the impossible question no matter which side of the interview table I sit on.  Don't waste your candidate's time...ask them something meaningful.  If I'm a candidate in your shop, don't waste mine.  If I want four quarts of water, I'll put it in a four quart container and move on to my next programming or architecture task.  I will not use a sorted hash table when sorting is not required and will not use inappropriately sized tupperware to contain water of a given volume. So, what's my interview outline?  I do follow Joel's advice and take just a few minutes before interviewing a candidate to jot down an outline and I move fairly quickly once I'm in with a candidate unless we're having a compelling coversation. 1. Introduce myself and the firm.  I'm not a classically trained programmer and we're not your typical consulting organization so this is actually a good spot for me to lay the foundation for how we communicate.  2. Ask the candidate to introduce him/herself.  How does he/she communicate?  Do they start back in childhood or do they know to just call out the salient points over the last year or two combined with a little personal background? Eye contact, confidence and presence are all biggies here. 3. Question on a recent project.  This is verbatim from Joel's list.  And I'm looking for the same stuff he is...excitement about what they're doing. Do they make the leap and show excitement or interest on recent technology or industry trends? Or do they linger and bad mouth the current employer or PM?..no Hire. 4. Technical trivia.  Usually a mix of standard .NET, GIS, and Web 2.0 techncial questions.  We have a standard dictionary of questions by level of difficulty and I just make them harder until I find some the candidate can't answer.  This also allows us to say we technically evaluate every candidate equally. 5. Programming problem.  Whiteboard time!  This is where things get interesting. I'm less interested in specific syntax than I am in form of the code/pseudo code.  Any problem will do...however simple.  When I started using this in my interviews I took Joel's advice and kept it simple.  Calculate the area of a circle given radius, sum the members of an int[] array, etc.  You'd be surprised at what comes out on the board.  Again, pseudo code is fine but there are some things to look for:  Does the candidate place opening/closing brackets in pairs, going back to fill in later?  Is "try...catch...finally" habitual? Always make them find the bug and fix it even if it takes some coaching and guidance...don't just leave them hanging.  Entry level folks get these softball problems, more advanced candidates may get a singleton or multi caste delegate problem. 6. Design problem.  Parking lot, car, house...it doesn't really matter.  I pick a real world object as the system and have the candidate do a UML class diagram on the white board.  I'm looking for the OOP/OOD understanding.  Are relationships like using, realization, generalization used properly?  Do they ask questions and seek additional input and detail before leaping into anything? 7. Open ended architectural questions and soft skills scenarios.  For the architecture questions, there are no right or wrong answers, I just want to see if they understand the implications of their architectural decisions and if they can defend their positions.  The soft skills questions are really the "too easy" questions that Gladwell calls out and I don't bust many people...but I bust enough.  These questions all involve "difficult" clients and awkward situations and basically I ask them becuase they continue to flag a few no hires here and there.  They also give me an opportunity to gauge the consulting experience of the candidate.  Can they give me examples of similar issues?  Are they going to be trainwreck in front of the client alone? 8. I always leave time for candidate questions.  That's my basic outline.  Sure being smart and getting things done is important, but knowing when you're getting your chain yanked on a question is a huge component of that.  Don't waste the time of your own firm or your candidate by trying to come to some sort of pseudo answer on how many blades of grass are in your front lawn.