3 ms·

> but I can damn sure find it and understand it in 5 mins if you let me Precisely this. That's one of the key things from our "experience" and "seniority". We'

> but I can damn sure find it and understand it in 5 mins if you let me Precisely this. That's one of the key things from our "experience" and "seniority". We've seen things, we know how to be pragmatic and learn/relearn X to finish Y and deliver value. I'm yet to see an interview that covers this. I'm clinging to my current job because I'm not sure I can face the job market in my current age.

urthen 6y ago
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 6y ago
  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.

urthen 6y ago

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 6y ago
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.