Ask HN: Why did you Not hire that candidate?

In the interview itself, as I said, no coding. Sometimes I will ask the candidate to spot bugs in a function, or read code and say what it outputs, or have a whole function written with one thing missing, and ask what's missing. But asking the candidate to create something where nothing yet exists is not fair, I think. Whiteboard coding and all that, it's no good.

When I say the candidate didn't know the language well, I meant conceptually. Like, imagine if someone told you C had a built-in array type, for example. It was that sort of thing. And remember, this was a person claiming expertise.

One of the principal things I look for in candidates is ability to speak comfortably about their thought processes & confidence level -- because it's so much more valuable to have a developer say "well, I can think of two ways to solve this, but I'll have a much more solid answer if I can take 10 minutes to refresh my memory on a project I did 5 years ago" than one who says "there are 2 options".

This shows up in interviews (and I look for it); if you give a wrong answer to a question, but you seem to be confident, that's bad. If you give the same wrong answer, but you mention that you don't use the construct (and thus aren't fully confident on your response), that can even be better than giving the right answer.

An interview that only saw correct answers can easily be less informative than one that ran into areas of uncertainty -- because it's crucial to see how they handle that. Do they realize they're guessing? If not: don't hire. Are they comfortable revealing uncertainty or missing knowledge? If not, don't hire.

Ideally they should know how roughly how confident they should be, and also know how to get to a better answer quickly. Real development isn't at all like a closed-book test, and interviews that operate like a closed-book test aren't useful for that reason.

'That's the kind of person you don't want to hire to work on a PHP app.' Definitely. I would also be surprised if they were even technically capable of giving a good answer, given that attitude.

'You also don't want an arrogant know-it-all on your team, even if he is a genius with code.' Agreed. And since nobody else wants to work with someone like this, this type has a tendency either tone down their attitude or to get weeded out before they can really grow technical expertise. I've interviewed hundreds of people and can only think of a couple of examples that were close to that, and those were either for internships or people fresh out of college. Do you often run into people that are technically a great fit but are too arrogant to hire?

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

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.

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.

Example:

var a = function(x){ this.x = x+1; return this; }

var b = function(){ this.x *= 2; return this.x; }

a(3).b(); //result = 8

  function myFunction() {
    var a, b, func;

    func = function () {
      return {
        attrA: function (attr) {
          a = attr;
          return this;
        },
        
        attrB: function (attr) {
          b = attr;
          return this;
        },

        toString: function () {
          console.log([a, b].join(' '));
          return this;
        }
      }
    }

    return func();
  }

I like this question because it covers closures, this, objects and functions. It also doesn't qualify as a brain teaser, IMO.

I don't necessarily expect perfection in code design - I can help teach that, but a good foundation is paramount.