I think someone once asked me the simplified variant of that question.
What is the result of:
[]+[]
And I didn’t know the answer to that (I mean, who does that kind of fuckery in Javascript, you can’t sum arrays). I would have no chance with these Google level questions.
That's an idiotic interview question. I've experienced this at young companies where both the company and its engineers are too immature to understand basic etiquette in the industry. Btw I doubt Google would ask a stupid "gotcha" question like that. They tend to ask hard algorithmic questions.
FWIW I’ve had Google recruiters ask me stuff where they don’t understand the answer and the questions are things like “what is the protocol number for ICMP” and “what port does NTP use”. If one doesn’t work with these things very often, they’re very forgettable as they’re so easy to google and find the correct answer to in seconds, and therefore not worth memorizing. No idea if they’re still doing this, but it was like a crappy version of Hacker Jeopardy (#DFIU!). After about 6 months of back and forth with the recruiter and a few interviewers missing interviews, I just gave up and told them I was no longer interested.
I went through the swe generalist interview pipeline 3 times at Google, so that's about 15 interviews. All the questions have been standard , except this one dumb question, which was along the lines of "explain how multithreading works". I suppose he wanted me to follow up with some questions to narrow down the topic, but I was stressed out enough that I just started with the basics, like cores, processes, OS threads, and shared memory, trying to explain it in simple terms. He interrupted me about 5 minutes in and moved on.
Having interviewed people myself, I think that's an overly broad question to ask in an interview and if the candidate starts answering it as asked, then you're not going to get a lot of signal from it.
Otherwise I thought the problems asked weren't that difficult, one was even directly taken from Cracking the Coding Interview - if only I had read that chapter ahead of the interview...
Heh, what's this? You can't answer this question off the top of your head after I spent 2 hours purposefully researching obscure edge cases to craft it? I guess you're not a real engineer. Did you even pass the 101 courses? No, no, no... You're no fit for us here. You see, some of us have to actually work for a living. Try pulling yourself up by the bootstraps next time, kiddo!
Only in Amazon interviews I've had actual trivia questions, like having been asked questions that'd require you to know all POSIX signals by memory (that could be fair if you squint a bit) or, more absurdly, solve a problem tailored for a particular flag of the find utility (which I realized when I looked at the manual for the thing again), as any other solution was too complicated to be satisfactory.
This is in my opinion actually a decent interview question. If you know JS in detail, if you know how the "+" operator works, it's a super easy question. If you don't know JS in detail, if you don't know how the "+" operator works, it's pretty tough. If you want an engineer who knows JS in detail, asking this question can be valuable.
"+" isn't some singular operator. They are different operators for different types using the same character. You'd have to memorize a table of all JS types and what "+" does for each, which is silly considering that the only place it should really be used in modern JS is arithmetic and the occasional string concatenation.
afaik these two places ( arithmetic and string concatenation ) are the only ones where + operation is defined. JS picks one of these two operations and casts the operands accordingly.
Edit: Wait, there is also the unary + which takes only one argument, but it also could be considered arithmetic.
The + operator doesn’t work on arrays, but tries to cast the sides of it to a string. Arrays implement the toString function, which shows the toString of the individual values comma separated. An empty array returns an empty string. Which means that this is equivalent to empty string + empty string.
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.
What is the result of:
And I didn’t know the answer to that (I mean, who does that kind of fuckery in Javascript, you can’t sum arrays). I would have no chance with these Google level questions.