> Go back and replace jQuery with underscore, lodash, ramda... It's literally built into the language, and the person added a script tag to include an 85kb file just to run a loop over 3 elements. THAT'S the problem.

Well, jQuery in particular is somewhat of an exception. It achieved such a high level of ubiquity, and solved such a vast array of cross browser issues, it was not unreasonable for a front-end dev to add jQuery as the first step in any project. Similarly, while its "literally built into the language" that's only true in cases where you can drop IE8 support. I would personally be very surprised if there weren't still more quality developers who knew the jQuery or underscore api's better than the native javascript ones.

I think the more general sentiment here is: If you use map / reduce / forEach / etc with jQuery / underscore very well, you can very easily transition into dropping or changing those libraries. But your comment made it sound like you were less interested in how well they could code and more interested in which API's they knew (and knocking them for defaulting to the most widely known ones).

To add onto this, this was not an attack or criticism against your methods lloyd-christmas. This was more the fact that I was pointing out that the front end dev world is so fragmented that almost any view point is something you'll come across while interviewing. Your point that this is a simple task to solve without a library is a valid one, but you'd also be as likely to find a team who expects you to default to a library because any non trivial project would require it. The main problem that I think is at the heart of this conversation is that the expectations of what you know and how you work is far too fragmented for most people to keep up with