Notes and Ramblings

Traditionally, one asks technical questions at an interview to verify that a candidate actually knows what he claims to know. Such questions may target professional certifications, specific technical trivia, or code written previously. The primary weakness of such methods is that the candidate has significant control over which claims are open to verification. The candidate may be tempted to bluff, for example, by cramming facts during the few days prior to the interview.

We suggest using technical questions to gauge a candidate's self-study ability. Ask a candidate to solve a programming problem on the spot -- but determine in advance how much familiarity the candidate is likely to have with the given problem.

For example, imagine you ask the candidate to write C code to reverse a string in-place. How do you interpret the candidate's performance? There are three cases:

1. If the candidate claims to be a expert, you can expect convergence to a correct solution with negligible trial and error.
2. If the candidate is somewhat familiar with the problem domain, it's hard to know what to expect. It is not clear how this uncertain kind of questioning provides useful data to the interviewer.
3. If the candidate is unfamiliar with the problem domain, you are tapping his ability to learn new material. When a candidate is denied access to a domain expert, self-study ability can be revealed.

Hence, the interviewer must carefully select programming assignments using data uncovered by traditional technical inquiry. On one hand, a candidate wants to answer technical questions comprehensively. On the other hand, comprehensive answers better reveal what the candidate doesn't know. These two opposing goals work to keep the candidate honest.

Posted by: SWeidner / 2/27/2006 09:38:00 PM