Was the role more biased to front end development? Speaking as someone who has been on the other side of the interviewing table, you won't believe the number of people who can use jQuery but are otherwise unfamiliar with vanilla Javascript. I suspect the question itself could have been solved by via plain JS, and you did the equivalent of $('#id') instead of document.getElementByID('id')
These were Rails positions, which in my experience almost always equates to the same skillset expectations as a front-end engineer.
While knowing how to use vanilla js is important, nobody uses getElementByID anymore, unless you're doing something very, very simple (or building a library yourself)
These interviews usually end and then when I look up the company 3 months later they don't exist anymore or have pivoted.
angular.forEach([1,2,3] ...
$.each([ 1, 2, 3 ], ...
[1,2,3].forEach(...
This isn't to say your experience didn't happen, I'm just pointing out that there is a lot more that goes into it than just which framework the cool kids are using nowadays.
Sorry, what does this even mean? When we consider it bad to use an external solution we call it Introducing Unnecessary Dependencies, when we consider it good to use an external solution we call it Not Reinventing The Wheel.
What you're doing here is fetishizing some arbitrary knowledge that you've set up as a litmus test. I've hired probably close to a hundred engineers by this point in my career, and I have to say, unless you are hiring for specialists to fill a very specific purpose, the only test that matters is Joel Spolsky's smart-and-gets-things-done test. There are plenty of web developers out there who only ever used jQuery and thus never learned javascript properly—that says nothing about their talent. There is a good portion of them who, upon being told, "we don't use jQuery here, just raw javascript" will learn and be better at it than you in a couple months. Even more importantly, any good engineer is going to have a lot experience which you don't have, and which to you is an unknown unknown. The best team is made up of diverse backgrounds and experience, not a bunch of people who managed to pass through a series of arbitrary knowledge gates.
It seems like you're presuming that they must lack proficiency in the DOM if they're choosing to use jQuery. Perhaps you're trying to say you want to see them demonstrate that they're not just copy/paste coders.
Given your code example above, I wouldn't want a candidate to know the difference between each `forEach` method, but I would expect them to know that each provides a means of iterating over a set of values.
I don't use this in my interviews, and I'm surprised everyone took this literally given that we have a weekly blog article about the villainy of technical interviews and how they destroy the very fabric of software development. I'm using a hyperbolic example to demonstrate what I perceive as a negative trait; A reach for unnecessary tooling to solve simple problems. My hiring experiences have pointed towards it being indicative of a comfortable one-trick-pony.
> Given your code example above, I wouldn't want a candidate to know the difference between each `forEach` method, but I would expect them to know that each provides a means of iterating over a set of values.
Likewise. However, if I'm hiring someone for a back end role, I'd expect them to be able to know basic SQL and not just their language's ORM. I'd expect them to be able to type `cd` and not just navigate through their IDE. I don't think there is anything different between that and the relationship of jQuery/angular and vanilla js. jQuery isn't written in jQuery. Debugging rarely stops at the script tag/require statement.
for(let thing of things) {...}
for in, on the other hand is wrong
https://developer.mozilla.org/en/docs/Web/JavaScript/Referen...
https://stackoverflow.com/questions/500504/why-is-using-for-...