> and the Javascript question was to test whether you've ever done anything numerical in JS.

It's a lousy test, then. The fact that someone can't tell you the answer to that question, off the top of their head under interview conditions, might mean they are a newbie claiming to know languages they really don't. However, it could also just mean that they have experience with several dynamically typed languages but, since they would never write something daft like '4'+4 in real code, they would have to look up which interpretation JS happens to use.

In case anyone is wondering, in JavaScript, the answer is 44. However, in Perl, it is 8. In PHP, it is also 8. In Python, it is a type error without an explicit cast. You get the idea.

Of course it's a bad test.

Google says they only hire people above the mean skill level of a Google engineer, so you need to look better than an average Googler to get in.

http://googleresearch.blogspot.com/2006/03/hiring-lake-wobeg...

> since they would never write something daft like '4'+4

The question is an artificial simplification. They don't care about that literal construct. They care if you know what the + operator does on strings vs. numbers and what the implicit type conversion rules of the language are (and what the resulting 'gotcha' is). No one is worried about you literally writing '4'+4. They are worried about you writing foo + bar and being sloppy about the types of your variables.

> They are worried about you writing foo + bar and being sloppy about the types of your variables.

In that case, perhaps a better question would determine whether the candidate understood that in a dynamically typed language, variables don't have types, values do...

I realize you are trying to make some sort of "Aha! You don't know what you're talking about!" point here, but in practice taking advantage of the fact that you can store multiple types of values in the same variable in a dynamic language is almost always a bad idea and subjects you to exactly the sort of bugs that this question is bringing to light. So, enjoy your sense of superiority because I made a slight mis-statement. The point that the question is phrased for simplicity as a concrete example, in order to see if you are aware of certain general facts, stands.

Apologies if the similar wording came across as some sort of personal jibe. I was merely trying to point out that even if the question was a simplification as you said, it was still a poor way to assess a candidate, because it's still getting hung up on a technicality rather than determining whether the candidate understands the underlying issue.

I guess I read too much into your comment. Apologies in my part for overreacting.

As to the technical issue, I don't think this has anything to do with dynamic vs. static typing. It would be theoretically possible to define operator+ in C++ to produce the same behavior as Javascript.

> I don't think this has anything to do with dynamic vs. static typing.

Well, yes and no.

In a sense, the real problem here is the overloaded + operator, which has two quite different meanings, numerical addition and string concatenation, depending on context. This is particularly a problem in a dynamically typed language, though, because you don't know in advance what that context is and therefore which overload will be chosen.

> It would be theoretically possible to define operator+ in C++ to produce the same behavior as Javascript.

In C++, you can't actually change the behaviour in this particular case, because you can only define overloaded operators where at least one operand has a user-defined type.

So in fact, just to make things simple, the C++ answer on most modern computers will be 56. Go figure. :-)

The rudest thing about what GP describes is that the interviewers had demanded quite a bit of his time via the AJAX app but weren't willing to investment an equivalent amount of time in determining his skills - especially when they had the AJAX app they could have asked questions about.