This reminds me of something I was working on back at AV that required a call to one of the Perl library functions. In testing, it worked most of the time, but there were some odd corner cases that didn't work quite right. I wound up having to catch exceptions for this particular call. The Perl documentation didn't say anything about this bug or the need to catch exceptions; I had to look at the sources for the library to figure this out.
So I guess I can see why an interviewer might prefer someone who'd worked extensively with a language's library routines. However, I still question the specificity of some of the interview questions. Maybe it's just me – I don't commit that level of detail to long-term memory (especially since I'm unlikely to remember on an interview). I tend to think more of the (general) problem I was trying to solve. If I remember something like that on an interview, it's a coincidence. I think there are other ways for a candidate to be tested on their knowledge and use of APIs. For example, the interviewer could make a design problem out of it: give an example of a library routine that has a bug and ask candidates how they'd resolve it. One can even make variations on the question, such as when sources are/aren't available; when you do/don't have permission to make changes to libraries; when there is/isn't information on the web about it.
I remember once on a screen, being asked which Perl CPAN modules I'd used recently. Fortunately, having read on an interviewing site that such a question might be asked, I thought of a couple I'd used for the log processing. But there are zillions of CPAN modules (and new ones are added all the time); there's no way I could possibly keep track of all of them, let alone memorize what they do. (I didn't get the job.)
As an aside, in the first Google phone screen I ever had back in 2001, I was asked what command is used to get the process id of a TCP connection on a Unix machine. Now I had done this, back in the 1980s, as part of debugging some kernel code, but I didn't know of a (user-level) command that did this offhand, because back then, people used awk scripts with kernel debuggers to print out data structures associated with protocol control blocks, and there was a pointer in one of them to the data structures where process ids were kept. So I said that, but the screener seemed disappointed. After the screen, I poked around the man pages a bit, which brought back a vague memory that this could be done with sockstat. I remember thinking that this was a very odd question, especially from Google, which (at the time) was not very big, and most of the people I knew of were more research-oriented than development-oriented (some of these people came from Digital's research labs, and had even worked on AltaVista). So I thought the questions would be more concept-oriented, and that understanding how the kernel data structures were organized would be more valuable to them. I knew very little about the "new order" of candidate assessment; was I in for a surprise.