This kind of thing does happen in the wild, through no fault of anyone in arms' reach, in particular when service APIs change in subtle and unexpected ways.
You might have a service that yesterday returned a JSON payload:
{ tasks: 5, ... }
but today returns:
{ tasks: [{...}, ...], ...}
If you had an array of these objects and were trying to sum the count of tasks, now your code returns weird results. Knowing how the JS engine's type coercion works is then invaluable for figuring out the problem quickly.
Yes, it's shitty code, and a change of API like that is shitty. But we don't always get to choose what code we're interfacing with, particularly when it comes to web services.
Sure, but in the wild, you would actually run the thing in the repl to see what it does. So either you know the answer or you don't and it doesn't affect whether or not you can do the job well. In my opinion binary knowledge-based questions are seldom useful unless you specifically are checking for that exact knowledge. You can have someone who is totally terrible in general but just knows that one thing or the answer to that specific trick question and you can have people who would be fantastic for the role but either don't know the answer or can't think of it because of a mental block in the moment. ie the false negative and false positive rate are too high and your question is just a random classifier.
Questions that allow a person to show their skill and their thought process are much more revealing. They're much harder to fake and bluff your way through for poor candidates and they allow good candidates to show their skill. They require a bit more effort from the interviewer though because there isn't just one right answer and you have to sacrifice the idea that you get an ego boost by dunking on some poor candidate with your trick question.
An example of a question I used to ask when interviewing candidates who said they were good at unix: "Say I have a directory full of files called a, b, c, etc and I want to rename them all to a.bar, b.bar, c.bar etc how do I do that"? Then I would follow up with "Ok now I have a directory full of files called a.bar, b.bar, c.bar etc and I want to rename them back to a, b, c, how do I do that?".
Now if you know unix you know there are a bunch of ways to do this, there are a bunch of traps you can fall into, what if there are too many files for shell expansion, what if the file names contain spaces etc. It's not hard for someone skillful to come up with a few ways that deal with these issues and if they can talk through how they did it and why then any of them are fine.
Edit to add: There is a kernel of value here though, which is say you were debugging a thing where the result was an empty string and you thought "wow, that makes no sense", maybe you get to understanding what went wrong when you see that two arrays are getting type coerced or something.
My reply was less about whether or not it's a good interview question and more about the comments people are making in this thread that the question is completely invalid because only a "fool" would write code like that.
In practice, unless you have some extremely pedantic, end to end testing, your first hint that something is going wrong is probably going to be malformed output. TypeScript won't catch this error because it doesn't do runtime checking, it trusts that type annotations are correct. It's very possible for code like this to pass through without causing any exceptions to throw. Indeed, JavaScript was originally designed to "keep on trucking" in this way, and that's why we have this degree of type coercion. So you're going to be working backwards from a result rather than forward from a source. If you already know how your code works and you see a weird result like that, knowing the type coercion gotchas can help you work backwards to understanding where the change occurred.
But in the former issue, I don't think the question on its own is bad for job interviews. How the question is used is what determines if it's good or bad. For example, it is a little unreasonable to expect people to know every single, little gotcha in JavaScript and the exact way in which they misbehave. But I do think it's reasonable to expect people to know that there are gotchas and that this is a common one. I'd accept as a valid answer, "I don't know the exact results, but I do know that this doesn't concatenate arrays and instead does something unexpected".
> My reply was less about whether or not it's a good interview question and more about the comments people are making in this thread that the question is completely invalid because only a "fool" would write code like that.
If you ask about how to uppercase a string, certain constructs like []+[], or whether camelCase or PascalCase is superior you will get the people who know the answers to those questions.
You might have a service that yesterday returned a JSON payload:
but today returns: If you had an array of these objects and were trying to sum the count of tasks, now your code returns weird results. Knowing how the JS engine's type coercion works is then invaluable for figuring out the problem quickly.Yes, it's shitty code, and a change of API like that is shitty. But we don't always get to choose what code we're interfacing with, particularly when it comes to web services.