Anyway a lot of these examples can be explained if you know how type coercion works in JS and are aware what the `valueOf` method exists for.
Here's a nice write-up about this mechanism: http://2ality.com/2011/12/fake-operator-overloading.html
There's absolutely 0 benefit from an engineering standpoint in having type coercion memorized in JavaScript.
I'd personally immediately terminate every interview that posed such questions ({} + [] + '' or whatever).
I mean no offense, but I'd ask you to reconsider. People who ask trick/puzzle questions and hacks in interviews do not understand (or haven't thought deeply enough) how to properly screen JS developers which eventually goes through to the team itself. There are at least a dozen more interesting topics to question on if you want to assign extra points than useless stuff that should never be into production in the first place.
I would argue there is one:
tl;dr: Planning for the worst from the people who tend to generate code which is, in one word, bad but which they managed to push to production.
===
When you know you're going to work with people who are not familiar with this concept, but still managed to shoehorn some code that looks a lot like these examples.
Recent case: A local front-end server for development purposes and an SPA with a login form. The server checks for certain, hard-coded credentials and if they match lets the user through. Problem was, if you didn't get them right at the first try the proper credentials stopped working until you reloaded the page.
How did that happen? There's an extra field in the form that is initialized to an empty string, but if the form is reset(on login failure) it is set to null, while the server checks for: field == '', because somebody assumed this would be enough.
Null is falsy, but it's not equal to other falsy values. People who don't know that are usually left scratching their heads.
===
Anyway no offense taken and I'd be happy to hear some suggestions on how I could improve this process. Usually when I ask a "trick" question I give a warning beforehand indicating, that this is not something which is going to affect their score negatively. I found that normally people like this part and are often curious about the proper answer.
EDIT: One thing I would like to note is that I conduct interviews for the project which I'm currently in, so I'm going to suffer the consequences of any bad decisions on my part eventually.
I worked a couple times with a guy who was very smart but also quite arrogant. Each interview was an opportunity for him to show that he was "superior" to the candidate he was interviewing. One that sticks out in my mind was that this arrogant guy used to work at Amdahl and thus was knowledgeable about the IBM 370 instruction set. When the candidate said they had worked as a COBOL programmer on an IBM mainframe, arrogant guy jumped into action.
"Ah, so you know the 370? OK, then, when executing the numeric EDIT instruction and the format field is smaller than the number of digits required to hold the argument and there are an odd number of digits after the decimal point, what will the carry flag be set to upon exit?" Of course, the candidate didn't know the answer, and arrogant guy was quite dismissive of the candidate's abilities.
In my experience qualified people are first and foremost curious and usually bored enough with the usual stuff to start looking into things like these.