Precision is different from recall.
You're asking trivia. I'd rather ask questions that can't be studied for, only practiced through years of experience.
I also sometimes hire people who don't know JavaScript, yet.
Separately, if it's the kind of thing that can be learned in less than a year of experience, it's not helpful for determining whether someone should be hired as a senior engineer.
You're saying "you shouldn't have to study for an interview because you either have the experience or you don't" and then you're equating being able to answer a trivia question with experience.
The irony is extremely rich. Being able to answer any particular question cannot measure if someone has the requisite experience. The only thing it tells you is that they can answer that question.
Your judgement of them based on your question is extremely subjective and doesn't tell you whether they "REALLY know the subject" or not. You are just testing your own biases which may yield good results, but call a spade a spade.
> When I do interviews I make sure the candidate is aware that studying will be a pointless endeavor and if I can tell your answers come from one of the interview prep books I'll end the interview early. My interviews ask questions that will tell me if you REALLY know the subject. For example if JavaScript is a requirement I'll throw this at you
How can you tell if someone had simply memorized a few pieces of JS trivia and is regurgitating it to answer your question? The code is not that complex or "totally weird".
Your trivia knowledge is great to impress like minded people but irrelevant if the problem space doesn't depend on it.
PS: Someone could consider you a pretty junior engineer if you ship: "if(!!1 && b.some(e=>e>6)){
foo();
}"
because the you're increasing the risk of error in a codebase that would likely be maintained by people of varying skills. You write code to solve problems and you write code so regular earth humans can grok it and manipulate it to solve problems.
Writing code with a high risk of introducing problems and misunderstanding does not signal senior in many domains.
a.filter(x=>1)
!!1
b.some(e=>e>6)
so both arms of the && are true, so foo() gets called every time.
I don't think this is a very good test if someone like me can pass it just by making educated guesses.
...that said. This kind of thing annoys me. You shouldn't have to study for an interview. Either you meet the requirement and have the experience or you don't. Reading books and stuff like this is really a cheat by the person being interviewed. You many have studied enough to "pass the test" but you really don't have a deep usable knowledge of the material and will likely forget much of what was studied.
When I do interviews I make sure the candidate is aware that studying will be a pointless endeavor and if I can tell your answers come from one of the interview prep books I'll end the interview early. My interviews ask questions that will tell me if you REALLY know the subject. For example if JavaScript is a requirement I'll throw this at you
const a = [1,2,3,4,5,6,7,8,9];
const b = a.filter(x=>1);
if(!!1 && b.some(e=>e>6)){
foo();
}
and ask you to tell me what it does. Its totally weird code and seeing that in actual code is highly unacceptable BUT if you really know JavaScript you will be able to tell me what this does in less than 30 seconds. Immediately if you're going for a Senior position.
I'm known for hiring the best engineers.