Hacker News Reader

Comment by peterchon | Hacker News Reader

I think that's interesting. I understand that you're looking for someone with basic/foundational knowledge - but can you really judge them on not knowing (or be able to explain) a specific function?

Wouldn't it be better to ask a problem and see how the person might solve the problem?

View on HN

Of course I would never eliminate anyone on the basis of not being able to explain a specific function. That said, there are some questions you can ask that if the client can't answer correctly usually further questions only confirm my initial suspicion. These aren't brain teasers or anything like that. For a Javascript developer with 10 years of experience not to have even encountered bind(), apply() and call() is telling. Maybe it's just interview nerves, so you can ask a followup, like:

let's say you have a callback function cb that is going to be called by some async process, and in this callback we refer to this.method(). At the time we defined the callback, "this" referred to someObject. How can we be sure that when the callback is called, this.method() refers to someObject.method()

In nearly every case where the candidate could not tell me about bind(), call(), or apply(), they can't explain a clean way to do what is described in the followup (e.g. pass your callback as cb.bind(this)).

Maybe the problem is that you're asking questions built around bad ways of writing code, that good developers simply avoid. bind() doesn't even work on IE 6, and nobody in their right mind would pass a callback function around that uses "this" and later check that "this" refers to the same object.

How is modifying the context of a function related to "bad ways of writing code"? Using `bind()` is absolutely common, and even game way to new syntax (arrow functions) in ES6. In any case the point here is to ask a very practical question that anyone with minimal experience with the language should be able to answer.

If you're writing a function that uses "this"... and using "bind" at where the function expression is written, you should just name the object itself and refer to it in the function body that way. If you're defining the function one place with the expectation that "this" is bound to the right thing by code in another place, you should make your function take an explicit argument and pass it that way. That's how.

That would still be a satisfactory answer, and demonstrate that the person has the necessary knowledge. You need to know how to manipulate `this` before you can reach the [subjective] conclusion that it is bad code.

The thing is, if you're interviewing and throwing away candidates because you're expecting knowledge of stuff that, for example, doesn't work in IE 6, or is based on your specific way of writing Javascript code, you're just throwing away good candidates.

(Also, coding standards are not subjective. Some ways of writing code are more productive than others. The idea that it's subjective is nice to believe, because then you can pretend that nobody is wrong.)

I would question anyone who cites IE6 as a reason for coding a certain way in 2015. IE6 hasn't been relevant for at least 5 years now. But if a candidate said that he was familiar with bind() but would avoid it for the sake of compatibility with IE6 that at least shows familiarity with it. Using your logic, it would be ok for a candidate to say he had never heard of transparent PNGs because IE6 doesn't support them.

I'm citing it as a reason for somebody not being familiar with it. IE6 certainly was a restriction in some environments in the past five years or less. And that's on top of the reason that there's no good reason to use bind in what many people consider to be reasonably written code. Knowledge of these sorts of library features is a terrible proxy for actual ability to write good Javascript. There are better ways to test for that in a phone screen.

It's still relevant today, unfortunately, in some industries where upgrading is prohibitively expensive.

E.g., you'd need to buy a new POS system, or paid millions to have custom-made medical software recertified (or re-written) to work on a newer browser, etc..

It's much rarer -- most places have bitten the bullet by now -- but I still see it (and IE7 is certainly still around).

Reply on news.ycombinator.com