It used to be that this was a valid interview tactic - asking people hard/obscure stuff and seeing if you could get them to admit they didn't know, then get the

It used to be that this was a valid interview tactic - asking people hard/obscure stuff and seeing if you could get them to admit they didn't know, then get them to explain where they'd go to find out. It used to be that there were many different places to go to find disparate bits of technical know-how, each specific to the task in hand. It used to be that knowing how to find out was a valuable skill, required of any developer - every developer looks stuff up, no-one can know everything. This has changed a lot over the last few years - now the answer to all of that is basically just 'Google it.'. The only value left in this interview tactic is to probe the depth/breadth of the candidates knowledge and to see how they respond when they get to the end of it, in an interview/pressured situation. It's a good sign when they calmly admit they don't know and suggest sensible strategies for finding out. It is, however, a terrible sign if their domain knowledge stops before you get to 'What's a class?' - you really need to know the important stuff, end of story. I'm always shocked by the number of candidates that I've intervied who get weeded out by questions like that.