6 ms·
This could be an acceptable interview question for Javascript developers, but from the SO question it looks like the interviewer screwed it up: My answer was t
by 8_hours_ago 9y ago
This could be an acceptable interview question for Javascript developers, but from the SO question it looks like the interviewer screwed it up:
My answer was that it's impossible. They said nothing is impossible. It happened 2 weeks back, but I'm still trying to find the answer.
The interviewer should have gone into much more depth instead of (presumably) marking that question as failed and moving on. This was a perfect opportunity to find out more about the interviewee's knowledge of Javascript instead of whether they immediately knew the answer to a trick question.
The interviewer could have asked about the difference between "==" and "===" operators, which any experienced Javascript developer should know at least a little about.
Then they could have asked if the interviewee knows how "==" converts types before comparing them, and find out if they know that it uses .toString() and .valueOf().
Then the interviewer could have asked about if those functions can be overridden, and how that can be done.
At this point, the interviewee's eyes may have lit up and they may have been able to solve the original question.
This approach would have given the interviewer information about the interviewee's knowledge of: "==" vs "===" operators, .toString() and .valueOf() functions, function overriding, and object variables. Instead the only knowledge that the interviewer learned was whether the interviewee had seen a similar problem before or was able to immediately recognize the answer.
- mixmastamyk 9y agoSigh, the sad state of dev interviews in a nutshell.
- lhorie 9y ago> 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.
- 8_hours_ago 9y agoQuestions 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.
- rmrfrmrf 9y agoI 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.
- threatofrain 9y agoBut 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.
- somestag 9y agoYou 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.
- Joe-Z 9y agoI just sent the SO-link to a friend remarking: "...but I think if I were asked this in an interview, I'd just walk out" Asking only this question, without using the various other avenues one could explore from there, like you suggested, makes me actually question the competency of the interviewer. That is of course the competency in finding suitable applicants for the role they want to fill, assuming they're not looking only for people writing quirky 5-liners all day long which exploit some weird language behaviour.