From the article: "what is a class?" can easily be answered as a definition from a Google search, but that definition doesn't help you write a class, use a class, etc. Similarly, you can search for a definition of a join, but if you can't come up with an answer off the top of your head, you don't have the skill to use a join.

This is different from, say, being asked what the "succ" method of the Ruby Integer class does. Or, the preg_replace in PHP takes 5 parameters, which position do you place the subject string in?

Those are two different types of questions. The first paragraph has questions about key computer science/database topics that, if you don't know, it will take learning and mastery to use them in a practical application. The second paragraph has questions of an arbitrary nature - knowing argument order in one language doesn't prove you understand regular expressions nor does knowing what a somewhat ambiguously named method does - especially a method that is also called "next" and can be accomplished as "var += 1" both of which seem clearer.

But there definitely are some things that can be answered by searching that don't necessarily mean that the person has a mastery of the topic that would be required to actually use the definition. Now, the second set of questions might be a clue that this isn't a good place to work since they emphasize random knowledge that doesn't actually prove any competency, but that's another story.

1. Internal memory is a pretty good predictor of sincere interest in a subject. Ever notice how baseball fans know every stat of every player? They don't spend hours rote-memorizing tables; their passion for the sport induces remembering facts about it.

2. Interview answers reveal how you problem-solve as well as what you know. Saying "I'd Google it" indicates to me at least that you go for the fastest method of solving the problem. Better would be "I don't know, but I'd look it up in a textbook on X" or something, which reveals a willingness to take the time to learn something in depth rather than just copy-paste someone else's code.

In contrast, if I see a resume with a few years of experience writing Java code (working full-time on 90%+ Java systems), then I think it's reasonable to discuss the specifics of the language/platform. If you've supposedly been writing Java code for a few years and you can't tell me how exceptions work, then you're a moron or a liar.

Interview questions aren't always about what the answer is, but how you answer it.