Previous month:
November 2011
Next month:
January 2012

A Different Way To Look At Technical Interviews

An interviewer and a candidate are in a room, conducting an interview for a software programmer. 

In front of the candidate is a question about a complex coding problem.  The interviewer asks the candidate a series of generic questions and then tells him it's time for the technical part of the interview, and motions to the question. 

The candidate begins, but quickly finds themselves stumped.  Maybe the room is too hot.  Maybe he's nervous, but he's drawing a blank. 

Here's what should happen. 

Candidate:  I'm a little lost on this.  Let me ask you, what would you do?

Interviewer:  Actually, this test is designed to find out what you would do.

Candidate:  This is what I'd do.  When I'm stumped, I reach out to other people to see if they have ideas.  

Interviewer:  I'm afraid I can't help you. 

Candidate:  Can I use my phone?  Or my tablet? 

Interviewer: This is a mental test. 

Candidate:  Yes, but my mental model includes reaching out to trusted sources and looking for information online quickly, in order to fill in gaps and check my work. 

Interviewer:  That's a bit unorthodox. 

Candidate:  For an interview maybe, but not for actual work.  Do you ask your programmers to solve problems with pencil and paper in a small, hot room under a deadline?  Or do you sit them at a desk with a phone, a computer, and access to other smart people?  One of those ways is a test on how well you test.  The other is a test of how you successfuly do your job as a developer. 

Interviewer:  You're hired.