First of all, this was many, many years ago. Nowadays my interview is half an hour of (hopefully) nice chat, followed by half an hour of technical questions fol

First of all, this was many, many years ago. Nowadays my interview is half an hour of (hopefully) nice chat, followed by half an hour of technical questions followed by half an hour to an hour of coding exercise with real IDE. We all learn on mistakes, my interviewing process evolves as I learn which things do and which don't work. Second, one of the goals of the interview is to see whether you can deal with the problem analytically. I am purposefully setting up problems that do not require (much) prior knowledge to observe the process of how the candidate deals with the problems. While our knowledge of particular topics changes, our general approach to solving problems is almost set in stone for similar/related categories of problems. If you are developer who does not predict how the code is going to work but rather rely on running it umpteen number of times and reshuffling instructions until you happen to make it work, this isn't just a sign of your lack of knowledge but rather your general approach to dealing with them. I bet, and I have observed it many times, that the person will do roughly the same when faced with a number of varied problems.