Technical Interviews
I have interviewed a number of candidates in the past, mostly on their technical skills. I also have been interviewed a few times over the years. There is one thing that I really dislike about technical interviews, it is the technical questions.
Now not so much the technical questions but the ones that ask about things like the “final” or “synchronized” keywords in java or the types of joins in SQL. I could concede that a few are fair game. They are sometimes used by managers to filter candidates. However in that case I would suggest something shallow and short that enables you to terminate the interview quickly and save time. Otherwise you risk two things. One the candidate may have a deeper understanding of the problem than the interviewer (and possibly than the person who wrote the question, especially for standardised questionnaires in large organisations) and therefore give an answer the interviewer misjudges as wrong. The other is that people who have no practical experience in the matter but only read a few books (say to get a Java certification) can answer these flawlessly.
So aside from my personal preference when I am interviewed, it seems to me these questions are typically of little value to evaluate the candidate’s possible contribution to a team or company. My personal approach is on the completely opposite side. I try to have the candidate talk about his experiences in some technical details. This provides more details about the actual work than what typically appears on the resume (and discovered in many cases that it was a lot less interesting than presented). It also gives me an idea on what the person actually did in the project described in the resume. I was never disappointed with this approach. And I don’t think it takes significantly more time to filter out bad candidates.
Now there is a third, rather interesting approach. I had the privilege to be interviewed for a job opening a few weeks ago. I was actually interviewed three times by three different persons. Two of them were asking questions in the bookish style (by the way there is always the pitfall in that type of questioning that you actually have the wrong answers). The third one (well actually the second one in order of appearance) started with the bookish questions but used them to trigger deeper conversations on the subject. I found this way of driving the interview extremely interesting. First from a candidate’s point of view you suddenly feel as if you were comparing notes with a peer rather than being formally interviewed. Which means that both the interviewer and the candidate quickly get a feel of how things would go if they were team-mates. It goes beyond the mere questioning to establish a rapport which in turn gives more useful information for both sides.
Unfortunately, my other interviewers at that company must have felt differently because I got asked twice the same questions plus a few that were inspired (or directly lifted ?) from logical quizzes and internet riddles (like the three blue hat). Also, by contrast, at no point during these other interviews did I feel like I truly wanted to work at that company…
