Every now and then articles are posted how to interview a programmer. We even had this very discussion at my shop last week.
The last round of interviews in which I was involved, our guidelines were to follow a program of:
- Ask some pre-interview company specific questions
- Follow a pre-canned program with specific questions (program name withheld)
The program name would be excellent for hiring basically non-technical positions: Customer Service reps, call center agents, etc. They give you a well rounded idea of this individuals character.
The company specific questions helped us deep-dive (as much as you can in a 3-part interview process) into the individuals professional history, asking basic questions of best and worst experiences.
- NOTE: anyone saying they did not have a quickly expressing they didn’t have a “worst” experience is a red-flag. This is an imperfect world, with imperfect people, and imperfect systems. Something on a year-over-year basis usually deploys/executes less than nominal.
My personal practice: use the Pre-Interview questions to get a background feel, then use one a couple of the canned questions (sought by the head-hunters) to get thought process/patterns, and spend the majority of time asking technical questions to demonstrate competency in our area.
This is the main point (straight out of the opening paragraph):
Evaluating a programmer’s level of expertise is one of the hardest things in the hiring process. We are talking about actual programming experience, not theory. We are not taking a theoretical approach here because one can read the theory on any topic and master it.
A chuckle for myself, I had to lookup this point:
- Tell us the difference between equality and equivalence :
- This little blog gave the quick (and obvious) answer : int a=3 <> double b=3.0; int a=3 == int b=3;
But the point is made, and is a good one.