What about kind 3, the ones that can derive the solution from scratch, in their heads? I thought that was the point of most of those questions. Like "given two linked lists, what's the fastest way to determine if they share any nodes (not values, but actual nodes)"? MS gave me that one in a phone screen and I'd never written a linked list before. But if you actually know what a linked list is, this should be simple for you to derive relatively quickly (not Googling for a day).

If a candidate needs a day to learn up about something trivial they should be able to derive in minutes, then that kind of thing might compound and end up producing a huge difference in actual productivity ("all other things being equal").

You end up having no way to evaluate candidates. You have no way to distinguish the following -

1. Those who had seen the question before, decided not to tell you they had, and faked figuring it out.

2. Those who had never seen the question before, but were able to figure it out.

You can, of course, distinguish them from the following, but you can't distinguish the following from each other.

3. Those who have never seen the problem before, could figure it out, but do poorly in the pressures of an interview.

4. Those who have never seen the problem before, and could never figure it out.

And it is -possible- you get the honest candidate -

5. They've seen the problem before, they -tell- you they've seen the problem before, and go on to solve it easily.

#1 looks the best, and you've learned nothing about them (and they have nothing in their favor other than having seen the problem before). #2 looks okay, but pales in comparison to #1, despite having actually demonstrated ability. #3 looks poor, but you have actually learned nothing about them, and they may in fact be absolutely amazing, except not good with interview pressures. #4 looks poor, and is indistinguishable from #3 (unless they do so badly that it's clear they have no idea what they're doing, rather than just being off in the weeds somewhere). #5 you now know is honest, and that they've boned up for your trivia challenge, but nothing else.

You haven't measured anything you set out to measure. You wanted coding ability and/or ability to reason out a problem; all you got was whether off the top of their head they were able to solve this particular problem. If that was what the job entailed, parroting back answers from Cracking the Coding Interview and the like, then you'd have a good test, but that's probably not what you need in a developer.

> But if you actually know what a linked list is, this should be simple for you to derive relatively quickly (not Googling for a day).

Actually I think this is the worst kind of question to ask, because it measures: can the candidate code under pressure? Not "we need to get this done by launch/before client meeting" pressure, but right now pressure.

If a company wants literal coding ninjas who can reason about computation while in the middle of lightsaber battles, sure. But in the much more likely event that they're hiring people to sit for days on end and work on a large project, then this is an unnecessary obstacle.

OK, so make it a conversation. Have them draw on paper, or talk it out.

I'm probably on the wrong side of reality since plenty of people make lots of usable stuff while using vastly suboptimal approaches. OTOH if someone doesn't known very basic stuff, it seems unlikely they're gonna Google stuff and become wise. We're not talking about anything advanced; these are basic algorithms and data structures. Some people just aren't going to be able to handle the concept of memory layout so might as well figure that out sooner than later, right?

This is an even worse idea than just asking for white-board coding, but it seems to come along every time. Not only are you putting the candidate under pressure, where thinking is difficult, now you expect them to walk you through their thought process and narrate what they're thinking, disrupting the thought process. I personally need to think things on my own without having the pressure of having to tell the interviewer what I'm thinking. Not only does it alter my thought pattern and remove a lot of the ability to think, but the extra pressure from wondering whether I'm saying the right things or taking too long to think before stopping myself so I can please the interviewer pretty much removes my ability to solve any sort of complex problem I haven't solved before. Not to mention the anger under the surface at such a daft and counter-productive approach to problem solving. This might work on TV and might be useful when collaboratively brainstorming, but in an interview, the only thing it's testing is the interviewee's ability to deal with social pressure.

I will have to disagree with this part:

> Not only are you putting the candidate under pressure, where thinking is difficult, now you expect them to walk you through their thought process and narrate what they're thinking, disrupting the thought process.

I expect a capable developer to be able to explain to themselves why they are choosing (or avoiding) an approach. If they cannot to that, would I trust them to be able to explain their methods or WIP problems to other developers?

When I do interviews, I care less about the solution the candidate comes up with, and a lot more how they ended up with the particular solution they used. The process of iteration and dead-end elimination is fascinating. This means that the best questions have N+1 different solutions. Some will be less optimal, but that's life. I also find discussing the effects of different solutions fruitful, on the less common occasions when the candidate ends up tossing one approach and settling on something altogether different.

And by the way, I really dislike the idea that you're supposed to do an interview in less than 1h. For anything remotely realistic, that doesn't even let you scratch the surface.