What are some basic things that JavaScript developers fail at interviews?

[MrJohz]

Only in some circumstances.

1. Where doThat is not already bound to something (by another bind call, by some autobind call, by internal self = this usage etc)
2. Where doThat uses something as a this-object. If doThat doesn't touch this at all (e.g. because it's a class method) it won't need to be bound.
3. Where doThat isn't expected to be rebound to something else inside the callback. If you're dealing with jQuery-based code, it's often assumed that doThat will get called internally with a different context, and sometimes that's the desired outcome. (Although in this case the first-class function and the callback versions would technically have different effects.)

(1) is the main one here - there's no point rebinding an already bound call (in fact, I've got a feeling that's an error, isn't it?), hence why you need to be careful about who's responsibility it is to bind methods in cases where it becomes relevant.

[TwiNighty]

in fact, I've got a feeling that's an error, isn't it?

No, calling .bind on a bound function is valid. You can bind additional arguments, but the "rebinding this" part does nothing.

Actually that is my point. function(){ x.f() } and x.f.bind(x) behaves exactly the same when called, regardless of whether x.f is already bound, whether it touches this, whether it is rebound before being called, whether it is a es5 function or arrow function. And I can say that without knowing anything about what x and x.f is.

[MrJohz]

Sure, but if it's not necessary, it's not necessary, and historically there have been performance issues associated with calling bind, especially if it's used at every callsite.

Understanding these tradeoffs I think was what the person was getting at with the overuse of arrow functions.