Hacker News Reader

Comment by lhorie | Hacker News Reader

> would have given the interviewer information about the interviewee's knowledge of: "==" vs "===" operators, .toString() and .valueOf() functions, function overriding, and object variables

Sure, the interviewer could have spent some more time to lead the interview in a more productive manner, but at the same time I'm left wondering: what does the interviewer get from answers to those questions? Do the answers say anything meaningful about the candidate's ability to write code (other than a weak-ish probably-can-code/not-a-coder signal)? What about ability to test? Design? Function as a team member? IMHO, the question wastes a lot of time building up to an aha moment, while only getting a glimpse of the candidate's ability to memorize various bits of trivia that are easy to google.

View on HN

I actually see two red flags based on the candidate’s response, so I’d argue that this answer is rather telling.

1) The candidate demonstrates a lack of intellectual curiosity (and maybe even common sense) when they say “that’s impossible!” and move on.

2) The candidate attempted to pass off their (inaccurate) assessment as fact without even a shred of self-doubt. Colleagues like this are infuriating to work with.

But do you actually think you have found an effective measurement device for intellectual curiosity, persistence despite failure, or ability to examine personal errors?

If we are trying to measure some kind of mental ability as a predictor to work performance, one might question whether interviewer ability to extract such deeper insights from these questions is actually more effective than a g test.

You can criticize any interview technique by questioning whether it can really effectively measure <X>. The answer is always no, and even if it were yes, you can go on to point out that <Y> is also important and is not effectively measured.

I would probably not give this question in an interview, but if I did, I'd care a lot more about how the interviewee reacted to it than about getting the right answer. The people I want to work with are people who respond to weird questions with curiosity, not with guesses and a lack of followup. For a question that presumably would only take a few minutes to ask, it's decent enough. A bad question would be one that by design gives no information (or worse, gives misleading information), and this question does better than that.

Am I guaranteed to learn about their curiosity? No. In particular, candidates who are very nervous are more likely to clam up than start teasing out the details of the question. That's unfortunate, but hopefully this isn't your only interview question so there are still other opportunities for the candidate to show their stuff.

Questions like this don't tell much about a candidate's ability to design, write, and test maintainable code, however they do give information on a candidate's specific area of knowledge.

These questions are useful if you are looking for an experienced X programmer who can immediately start being productive in an X code base. While the original problem is definitely a trick question, I don't believe that any of the individual pieces of knowledge required are merely "bits of trivia" for an experienced Javascript developer.

It's the interviewer's responsibility to know what areas of knowledge are required for a role, and how important it is that a candidate is familiar with them. Memorizing the intricacies of "==" vs "===" may not be important, but I'd expect an experienced Javascript developer to know something about it.

What about ability to test? Design? Function as a team member?

Those skills are much harder to test for so most companies ignore them during the interview process and instead focus on attributes which can be tested for, and accept that the process is not 100% reliable.

Reply on news.ycombinator.com