Hacker News Reader

Comment by byoung2 | Hacker News Reader

To find the last new hire, 95% were weeded out just based on resume for lack of experience, or non-relevant experience. Of the remaining 5% who made it to a phone screen, 80% were weeded out because they could not convince me that their knowledge matched their experience (e.g. 10 years of Javascript but they can't explain Function.prototype.call() or Function.prototype.bind()). The rest who passed the phone screen, the decision to not make an offer came down to personality fit or geography (quite a few people were out of state, and would not be able to move here quickly).

View on HN

I'm continually amazed when I hear numbers like this. For the last two frontend hires, I went through maybe 20 resumes (resume reviewing, phone screens, and in person interviews). A few were personal referrals. One of the hires was a referral of mine from IRC - he turned out to be an excellent hire.

IMO, some of what you describe sounds like the wrong way to hire. Stuff like Function.prototype.bind can be easily found By Googling. You want candidates who can adapt to the unknown. I remember a well-known PHP developer in the DC area telling me a story about him guest interviewing candidates for a friend's company - he asked a lot of intense edge questions about PHP to candidates, and only one would give him straightforward answers about not knowing the answer and being willing to Google the answer. That candidate ended up being a phenomenal hire for that company.

Stuff like Function.prototype.bind can be easily found By Googling. You want candidates who can adapt to the unknown.

That is true, but it is a warning sign that someone with 10 years of working with Javascript has never had to use those functions (even if they had to Google it 5 years ago, they should remember it now). It would be like hiring a driver with 10 years of experience who didn't know what the parking brake was for. Granted it is possible to live your whole life in a flat state and never have to use it, but that's rare, and even if true, I want a driver who has seen at least a hill or two.

Once you've passed the basic questions like this, we definitely get to more difficult and tricky questions, and even a question that has no answer to force the candidate to either BS or admit he doesn't know.

I still prefer to give a candidate the benefit of the doubt there, unless there is more supporting evidence.

I have more sympathy towards people who may have not been fortunate to have seen the more challenging aspects of development and help them get there - only 2 1/2 years ago, I was unemployed for the past 2 1/2 years out of grad school without any company having given me such a shot at any career, and here I am now as a lead frontend engineer who is trusted to solve any problem thrown at me and build a team. Just as I was pissed off that so many companies were originally dismissive of me despite my education pedigree, I try not to be dismissive of candidates because they didn't happen to use [insert feature]. Stuff like that is easily studied or taught, and I evaluate almost wholly on things that (almost) can't be studied since it pre-empts candidates from giving me answers that hide important characteristics about them.

I understand what Function.prototype.call() does (and I'm an amateur ruby dev), I don't know what .bind() does but could go for a wild guess. Explaining something like this, might be more tricky. However with 10+ years of experience I'd expect someone to make rounds around things like that.

On the other hand an excellent hire might be a cheat that put the effort to become a good developer once he joined the company or... You might hire a very promising young man who (because this or that) he ended up being a bad hire.

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?

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