3 ms·

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

by Bahamut 12y ago

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.

byoung2 12y ago
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.
- Bahamut 12y ago
  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.
atmosx 12y ago
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.

by Bahamut 12y ago

byoung2 12y ago

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.

Bahamut 12y ago
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.

atmosx 12y ago

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.