> He was fixated on this one very specific piece of knowledge.
IMHO, that's what makes writing interview questions so hard: you really have to know the topic inside and out to know (or at least recognize) all the answers. If you only know one, your question is shit and you might as well have the applicant play guess the number.
That is silly. Trying to know all the possible answers is a losing game.
If I as an interviewer ask that same question and get the freopen answer, and let's say its not one I'm familiar with I can just simply say "I'm not familiar with freopen, could you tell me more about it?" And then I listen to what they say. A competent developer who is worth their salt will be able to summarise the gist of it quickly. Then if I want even more info I might describe the solution I know about and ask the interviewee to compare the two solutions, describe the pros and cons as they see them. What I would be looking for is the proof that the person I'm talking with is able to communicate complicated things clearly, and can think about code.
These skills are exactly what one needs in their everyday work, so why not use the opportunity to evaluate them? Does anyone really think that the goal of an interview question is to query if they know that specific trivia you happen to know?
And besides if I have doubts about that they are just hoodwinking me with this freopen I can just crosscheck what they told me with the reference. If it turns out to be not a thing at all, that's not a good sign and I will not recommend them to be hired, but otherwise they passed with flying colours.
IMHO, that's what makes writing interview questions so hard: you really have to know the topic inside and out to know (or at least recognize) all the answers. If you only know one, your question is shit and you might as well have the applicant play guess the number.