[mathgeek]

I've been to more than one interview where I defaulted to jQuery and was immediately disqualified, based on the looks on the interviewers' faces. As a ruby developer, it certainly feels like keeping up-to-date on JS takes more work than the other 90% of languages that I'm familiar with.

[sangnoir]

> I've been to more than one interview where I defaulted to jQuery and was immediately disqualified

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')

[mathgeek]

> Was the role more biased to front end development?

These were Rails positions, which in my experience almost always equates to the same skillset expectations as a front-end engineer.

[SZJX]

That probably depends. If the company is really small then you may end up doing quite some frontend work but there can still be significant backend logic going on in Rails.

[raverbashing]

Oh I'm sure that's not what they mean. 100% sure

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)

[jerkstate]

You sound like the article

[snlacks]

Yeah, it's true, but I've also been in interviews where I told them I was using a tool that I think they thought was too hipster and ended up just being ahead of the curve (Babel or TypeScript, don't remember which one, both were just picking up popularity) while still being looked down on because of jQuery.

These interviews usually end and then when I look up the company 3 months later they don't exist anymore or have pivoted.

[morsmodr]

As was said earlier, finding the right tool is essential. jQuery can still be used if the problem you are solving is limited and confined in scope. We had a website where angular is almost everywhere, we created a new page where there is just a list of check boxes, and another dev did that with Backend code. I just added a small jQuery event listener as the page needed nothing more than to disable a certain set of buttons when one from a set is selected. I could have re-written the entire stuff making angular get the model from server and then using angular in the view. But no, it was just not worth it. If you see that your jQuery component is building up (adding more functionality) then it gets messy/spaghetti etc. But if the interviewer straight away dismissed you at the sound of jQuery you are better off not working there.

[lloyd-christmas]

Interview question: "iterate over an array":

  angular.forEach([1,2,3] ...

  $.each([ 1, 2, 3 ], ...

  [1,2,3].forEach(...

One of these things is not like the other. I hire people that know javascript, not ones that only know the tool we use. The tool we use today may not be the tool we use 6 months from now. I've never asked a javascript question that required framework knowledge unless it was explicitly about concepts of the framework. Someone taking the time to include jQuery is instantly out the door. Walking through people's code demonstrates whether or not they default to other people's solutions than their own.

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.

[dasil003]

> Walking through people's code demonstrates whether or not they default to other people's solutions than their own.

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.

[marrs]

I have to say, this strikes me as an odd way of filtering out bad developers. jQuery is a time-saving library.

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.

[lloyd-christmas]

> I have to say, this strikes me as an odd way of filtering out bad developers.

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.

[mathgeek]

My original comment was actually in the opposite direction: the interviewers were looking for comfort with a framework other than jQuery that showed that I knew more than vanilla JS. That was the frustrating part.

[lovich]

@cloverich I think this comment is showing exactly how the author of the article wasn't exaggerating

[lloyd-christmas]

I don't follow. Are you saying _I_ demonstrate why the article isn't exaggerating, or that some of the people I've interviewed are?

[lovich]

I am saying that you demonstrate why the article wasnt exaggerating. Cloverich stated that using jQuery was fine and the article was exaggerating how far it has fallen out of favor, but you have stated that anyone using jQuery is out the door when interviewing with you. Therefore theres at least a group of people that article is accurately describing

[lloyd-christmas]

> Cloverich stated that using jQuery was fine and the article was exaggerating how far it has fallen out of favor, but you have stated that anyone using jQuery is out the door when interviewing with you

That isn't what I said in the slightest. My criticism had nothing to do with jQuery. Go back and replace jQuery with underscore, lodash, ramda... I'm not saying that I would turn away a jQuery developer when interviewing for an angular position. I said that a negative defaulting to a framework/library to solve a vanilla problem is a problem in and of itself. "One of these things is not like the other" is the native Array.prototype.forEach(). 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.

[cloverich]

> 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).

[lovich]

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

[tomatsu]

> Interview question: "iterate over an array":

  for(let thing of things) {...}

forEach only obfuscates the imperative nature of your loop.

[raverbashing]

Good, but that's more modern

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-...