Recently there have been a couple articles I’ve read that give different sides to the argument over whether technical interviews are effective, valuable or worthwhile.
Anything to put them under stress … This is your one chance to see how they handle stress before the brown stuff actually hits the fan. Ideally, a senior DBA is someone who’s had their cage rattled more than once, and they’re comfortable under the gun.
With a different point of view, Phil Factor has an article titled Technical Interviews, and tests, have got to stop! He begins by saying:
… I’d like more successful developers to confess their inability to remember much more than their name under the pressure of a technical interview. The most extreme geeks all have brains that blue-screen with a temporary aphasia under stress.
Phil Factor then goes on to argue for a different (albeit unconventional) interview technique that measures determination.
I have to side with Brent on this one for a few reasons:
Jobs are stressful. I don’t know of any IT job that is so cushy that the employee is not expected to work under pressure from time to time. It’s nice to see a candidate who has that grace under pressure. Confidence is the key I think.
These questions are not like academic exams. Phil Factor’s assumption is that the only point of these technical questions are to see whether the candidate gets the right answer or not. 5 marks for getting the right answer! And perhaps some interviewers do treat questions that way. But better interviewers care as much (or more) about the candidate’s approach to problem solving and behaviour under stress. And I think Brent and Phil can both agree on that point.
Bias disclaimer: I love puzzles. I love challenges like that. So I’ve never had a fear of taking technical quizzes. In his article Brent posed the question of solving the FizzBuzz problem with SQL code. I stopped reading the article right there and solved it before returning to the article. (
See problem as posed by Brent here) If asked about trivial stuff like which port SQL Server typically listens on for secure connections. I have no problem quickly saying “I don’t know that off the top of my head I’d have to look that up”
So I say yes! Good, keep the technical interviews coming!
Michael J. Swart
I agree with both you and Phil – asking arcane technical questions doesn’t tell me whether a candidate is qualified. Back in the 90s, I remember hearing someone ask what the resistance was of a coax network cable terminator, and I thought, “Yeah, I bet that knowledge comes in handy.” These days, that’s what Google is for.
Comment by Brent Ozar — January 23, 2009 @ 7:39 am
I would have no objection to any test that genuinely selected good DBAs or developers, and could be proved to do so. Until I’ve seen a proper scientific validation, I’ll assume that it is witchcraft.
The stress of life as a DBA is quite different from interview stress. the latter is more like stagefright. What Brent is talking about is the valuable ability to be able to thrive under a constant level of high stress due to the responsibility of the job.
The reason I get angry about it is that we end up just a small selected subset of the population of people who could do the job well. That’s unfair
Phil Factor
Comment by Anonymous — January 24, 2009 @ 10:23 am
Well, No-one will ever see a test that can be proved to select good DBAs. The problem is is that there’s no good way for a scientific study to measure how good a DBA is. I suppose someone could come up with some criteria, but once they do, then all they’re doing is finding a correlation between two different sets of criteria.
So then: Any interview process is imperfect and will only select a subset of the population of people who could do the job well. Unfair, but it’s the best anybody can do.
I think what Phil is trying to say is that technical tests select a smaller subset of qualified candidates than other methods. And that’s certainly up for debate.
Comment by Michael J. Swart — January 25, 2009 @ 12:28 pm