I would never treat someone like they're stupid in an interview, but being completely unfamiliar with common programming concepts and treating them as irrelevant or trivial things is definitely a red flag.
Once a guy asked me to write out merge sort on a whiteboard and I couldn't. I didn't get the job. Surprisingly I'm doing just fine in my current position and am very productive (as much as I may say so myself) and have never heard complaints from anyone that I don't know what I'm doing.
So if you don't see a CS degree in the resume then don't ask what a closure is or to implement a merge sort in the interview. Ask them to solve a real problem. The top computer scientists didn't discover the merge sort for years or decades and you want me to figure it out on the spot? Or you just expect me to memorize useless shit like this? Give a problem a programmer would encounter on a day to day basis that wouldn't need a lot of googling. Let them figure out how to solve it and see if it works for you.
i lived mostly in the java world, and discovered closures when i was getting wacky results while playing around with a Clojure looping example.
then ran into similar situations about once a year when doing something in javascript -- usually passing some function for a callback, and needing access to 'this' in the original/calling scope - which only confused things when i needed access to 'this' in the (local?) function scope, too.
guess i'm not against closures -- they just seem mysterious to me.
ditto lambdas. they seem like a good way to write esoteric code, and write more error-prone/less-defensive code -- that, for instance, might be more likely to produce NPEs, and generally be less maintainable b/c of the focus on brevity instead of clarity, and be geared more towards expert users/coders instead of the generalists (like me) who are often brought in to maintain older code.
The only reason I know what a closure is in JavaScript is because I have heavily practiced for Frontend interviews.
I've been otherwise using them productively forever now.
...that statement looks kinda sus. In a code review I'd maybe get you to simplify it or break it up to confirm the negatives end up meaning what you wanted them to mean.
The inordinate amount of space the article devotes to complaining about 'credentialism' just reinforces the impression that the writer hasn't taken the time to know his tools/languages/frameworks at a deeper level, and is dismayed to have been found out in interviews.
1) You're looking for someone with deep knowledge of that subject
2) You don't treat it as an automatic fail when they get it wrong
If I'm interviewing for a senior role, and I ask them a few super obscure questions about the language/framework/platform I need them to be an expert on, that serves as a litmus test for their overall depth of knowledge. Those facts individually may not be required for the job, but they give a read on how deep the person's knowledge goes in general.
But, as you pointed out, I wouldn't really even put closures in that category. For JS it would be something more like, "What does '{} + 12' evaluate to?"
It would be really hard for me to take the process serious if I was asked that during an interview.
evaluates to
"[object Object]12"
omg, I need to learn / start using typescript
x = {} + 12;
x has the value "[object Object]12". So, it' not always 12 :P
https://replit.com/@atlwellwell/EsotericJSInterviewQuestion#...
at this point, i'd love to know when the answer is just '12'.
i remember going at it with some dude back in the day who was 100% certain, and got visibly upset, when i stood my ground that java only used pass by value. i allowed that even object references were being passed, but that they were passed by value.
i didn't get the job.
Ctrl+Shift+k in a browser (firefox) opens a console. Just write {}+12 there and hit enter.
My guess is that {} is (in some circumstances) evaluated as a block of code (instead of an empty object). Since the block is empty it evaluates to undefined. The +12 is considered another block of code ( the + operation takes here only one parameter - so it is not a sum ). Consecutive blocks of code are evaluated to the value of the last block of code, which is +12.
{}/12 for example doesn't work at all - which is a hint that the + is not a summation operation.
Edit: I'm wondering why we use 12 and not 42
Edit2: Technically you are correct about java being pass by value. But at this point I'm questioning the sanity of the distinction. It feels more and more like a philosophical discussion.