[urthen]

I've done coding interviews for nearly 10 years now where I present a coding problem, but I never expect syntax correctness. I'll explicitly say I don't care if the function signatures are right or you remember the exact method to call on a given class or whatever; so long as I can tell what you're trying to make the program do. I have to look basic stuff up online every day anyway because nobody can remember it all, I'm not going to knock a candidate for that.

Other than basic filtering questions so I can see if someone is trying to fake their way through an interview, I never ask functional specifics. Even then it's usually just to make sure they at least basically know everything they claim to on their resume - if you don't claim to know JS, I'm not going to ask you about what bind() does, but if you rate yourself a 10/10 JS expert, you should probably have a good answer.

Interviews should be about your thought process and how well you can solve real world problems, not trivia about how well you've memorized an API. I don't understand why so many other interviewers (Even at companies I've worked for) ask coding "gotchas" and reject candidates because they don't remember the semantics of some obscure language feature.

[nonines]

To be fair most of the interviewers seemed to work along these lines that you describe. (That's why I managed to get quite close quite a few times - I was never big on memory so it's impossible get the details on WB).

Yet, if the string of interviews is too long (and it is) the probability of hitting a "reef" is really big. And it seems that either you get a unanimous "yes" or you fail.