Blah.Blah.Blog

I should state upfront that I absolutely adore doing technical interviews and usually only wish for more time to chat rather than the 60 minutes to which we're normally constrained by various factors. I have no formal training for interviewing, but have had a considerable amount of experience (for a developer) over the last 10 years or so.

The original review raised for me a few specific questions about technical interview techniques and the objective of the overall exercise:

What place do pre-prepared technical questions have in technical interviews?

This technique was used by one of the aforementioned interviewers and the complexity of the questions did cause some amount of consternation in the interviewee.

In isolation, I don't think this is such a bad thing: although I'm a big advocate of putting the interviewee at ease (in order to ellicit their best performance), surely the main objective of a technical interview is to guage the technical knowledge/aptitude of the candidate. Given that, I can think of no better way of achieving this goal than to ask some questions that the candidate cannot answer, or at least not answer completely.

Fundamentally, you're attempting to find the boundaries of the candidate's knowledge/ability in some direction/problem domain. In essence you're employing a search algorithm over a data structure to find where the data runs out. How you do that is largely up to you, but I would imagine some rough form of linear search would be most people's first choice. Something along the lines of:

• Ask first question... OK, they're obviously way within their comfort zone still - let's push a bit more down the same path
• Ask second question... Still answered quickly and confidently - let's keep ramping the questions up
• Ask third question... Took a while to formulate the answer this time. It sounds like we're getting into less well-known territory. No need to advance so quickly this time
• Ask fourth question... Ahah, didn't really have a good handle on this one. So now I know their knowledge in this area tends to fall off somewhere between Questions 3 and 4

Obviously finding an area where gaining knowledge is so sequential and well-defined would be difficult, but you get the general idea.

Should the interviewee walk out of the interview thinking they're a shoe-in for the job?

The answer to this question obviously lies in exactly how the interview went, but I don't think even the most successful interview should leave the interviewee thinking he/she will be starting on Monday morning.

Firstly, if you employ the above approach for defining the boundaries of the interviewee's knowledge in relevant technical areas, then they'll naturally have struggled with some questions. If you haven't adopted this approach, you have no real feeling for the amount of expertise they have in - presumably - areas germane to potential problem domains/technical environments. If this is the case, I put it to you that the interviewer has failed in their role.

Secondly, an HR manager of mine mentioned that it's always a good idea to at least give the candidate some doubt as to how the interview went, should they be refused a position. There's nothing worse than flying through an interview only to receive a "Sorry, given the high standard of our applicants for this position..."-style form letter afterwards. The interviewee would have every right to wonder "what did I do wrong?".

Here endeth my braindump, although there's obviously reams more that can be written on the art of technical interviewing. Many thanks to Jules for helping my consolidate my thoughts on this over lunch.