There is a culture of the job interview "riddles" among the big tech companies like Microsoft and Google. You can find a collection at this site if you are interested. These are all fine and good, but I always have an important question: what does this have to do with the job? I've railed about the need for authentic assessment in this space before, and this seems to be the exact same problem. Why have me do things in the interview that I won't do in the job? They seem to be falling into the IQ trap, assuming that you can design a test that somehow gets at the fundamental kernel of general intelligence when a) you are very likely only testing a very specific set of skills and b) high-stakes testing almost never tells you anything about a subject's ability. Maybe there is a decent correlation between people who excel at those riddles and people who excel within the company, but I kind of doubt it, and I'm guessing it tends to eliminate good candidates who are just bad at on-the-spot puzzle solving.

So, can I do any better? What would I ask a potential hire for my notional debugging company?

1. Do you own a set of Torx screwdrivers?
2. In as much detail as you are able, describe one of the following:
1. What happens between the time that you enter the URL of a website into your browser and that page displays (or fails to display)?
2. What happens between the time that you enter an SQL query into a database and the results are returned to you?
3. What happens between the time that you press the power button on your computer, and the login screen appears on your desktop (in the OS of your choice)?
4. What happens between the time that you hit send on an email message and the time that the recipient receives the message?
3. This computer won't boot up. What's wrong with it?
4. Are there devices in your house that have either software or hardware that they did not ship with, and how and why did they get modified?

The justifications:

1. This might seem like a silly question, and it borders on a non-authentic question. However, the only people I've ever met who own them are people who like to open things up and find out what's going on inside.
2. This is the first big hurdle. I am consistently shocked at the gaps and misconceptions people have in their technical knowledge. I figure that a good interview subject could probably spend upwards of an hour on any one of these questions, and the choices are broad enough (networking, databases, operating systems/computer theory, general IT) and common enough that a potential hire should be able to speak about at least one of them at length. They all have interesting possibilities for discussion along the way, and the questions that they ask in response would be informative as well.
3. This is the critical portion of the interview, and the key to authentic assessment since this is really what they would be doing. I don't care so much if they manage to fix it or not, but I care about how they approach the problem. Do they start by asking me some background questions, or do they just pop the thing open (both of which might have merit)? Where do they start looking if they pop it open? If they ask questions, do they seem to be trying to work on a theory? Are they just totally overwhelmed or bored by the task or do they seem excited to work on it?
4. Again, bordering on non-authentic, but this speaks to the other thing I look for besides skill: enthusiasm. I like to say that you can teach skill but you can't teach enthusiasm. Someone who hacks the stuff in their house or likes to have hacked stuff in their house is interested in learning about and fixing things independent of their work, and that speaks to engagement with the subject.

So that's my interview in a nutshell. I think it would appropriately identify the people with the requisite skill and interest for a job debugging full-time.