> 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.
> 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.
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.