I pretty frequently ask the question "Name any algorithm -- it can be bubblesort, and tell me when you use it, how it works, and what its performance is." I would like this to be the start of a conversation where I drill down and hear how a candidate explains technical details. But more often than not (!) I get answers like, "I haven't thought about algorithms since school and I can't think of any now", or "oh, bubblesort -- yeah, that's the one where you split the list into two parts and then I can't really remember what happens next," or "how does my binary search perform? Well, it's better than a linear search, that's for sure!"
I also ask people to explain database normalization -- most people give passable answers, but very few people can give good, concrete explanations, immediately.
Steve Yegge goes into more detail about the sorts of gaps he sees. I tend to see less of these problems, perhaps because the algorithm question weeds them out first.
Typical programmers don't remember these things because they're rarely relevant for typical enterprise software development*. If they're specifically important to what you're doing it may make sense to ask about them, but I don't think these kind of questions should be used just as some generalized "programming intelligence test".
* DB normalization is more likely to be relevant than algorithms, but often the database already exists.
This is the sixth bimonthly 'What are you working On?' thread. Previous threads are here. So here's the question:
What are you working on?
Here are some guidelines: