5 ms·

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 pho

by byoung2 12y ago

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

peterchon 12y ago
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?
- byoung2 12y ago
  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)).
  - SamReidHughes 12y ago
    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.
    - ricardobeat 12y ago
      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.
      - SamReidHughes 12y ago
        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.
        ricardobeat 12y ago
        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.
        SamReidHughes 12y ago
        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.)
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.

by byoung2 12y ago

peterchon 12y ago

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?

byoung2 12y ago
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)).
- SamReidHughes 12y ago
  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.
  - ricardobeat 12y ago
    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.
    - SamReidHughes 12y ago
      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.
      - ricardobeat 12y ago
        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.
        SamReidHughes 12y ago
        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.)

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.