Rather than simply speaking broadly, here's a very simple example of when I would expect someone who is sophisticated on the topic of programming languages to excel over applicants who are merely practitioners. (In practice, I actually do see this fairly frequently.)

Both C++ and Java provide "dynamic dispatch" as a language feature. However, by default, C++ does not use it; by default, it uses "ad hoc polymorphism" on the static types of its arguments, including the argument passed as the implicit this pointer. In order to enable "dynamic dispatch", the member function you want it applied to must be decorated with the "virtual" keyword.

If someone is able to reason at the level of "dynamic dispatch" and "ad hoc polymorphism" and how to activate these features, s/he should be able to write correct, OO code on a whiteboard. However, if s/he is not formally trained in programming languages, while this person may understand this on some level in practice, s/he may under pressure lose this distinction in whiteboard code, particularly if there is no test environment available.

I don't honestly believe that anyone who has done OOP in C++ has never run into this, so I chalk it up to lack of formal training on programming languages. And while this person may not be appropriate for a company that requires sophistication on the very specific topic of programming languages, this person may be appropriate for another.

I have plenty more examples, but this is a simple one that I think illustrates my point for most people.

On a side note, becoming somewhat formally trained in programming languages, whether or not this is the field of computer science you are interested in, allows you to easily pick up powerful languages, such as Scala, which some people are apparently unable to pick up.

EDIT: Fixed a typo.

I would consider this to be a pretty fine-grained differentiator in who you want to hire however. The formal training aspect gives you the name of things, but it doesn't make you better at reasoning in general. Given the choice between the faster, smarter thinker and the guy with the more specific domain and terminology knowledge which would you hire?

Must I choose? May I choose the smarter, faster thinker with domain knowledge? :P

I do not think domain expertise should be marginalized, especially when the domain is deep. Someone who is smart and fast but who has only ever thought in Spring and Hibernate isn't going to be able to start collapsing strongly connected components in call graphs. There is far too much distance between a blank slate and being able to do that effectively.

And how can a person who is able to achieve mastery of a particularly difficult domain be unintelligent? Truly becoming a master at something is a rare trait. I read in _Coders at Work_ that Ken Thompson, the inventor of Unix, looks specifically for the ability to acquire mastery: He picks an item on the candidate's resume, whether or not he himself knows anything about it, and proceeds to grill the interviewee about it. He reasons that, if the candidate is unable to convincingly convey mastery to someone who is entirely uninitiated to the topic, then how can this person be an effective programmer and team mate (at Google)? On the other hand, if this very same tactic actually sets the candidate off -- that is, the candidate starts waxing romantic about the topic while deftly dispatching any technical concerns -- then not only will this person be effective but this is someone who will be a pleasure to work with.

BTW, I believe that knowing the terminology is of only secondary importance. Its purpose is to effectively verbalize fine distinctions to team mates and often serves as a marker for greater sophistication. (Note that plenty of people throws terms around _incorrectly_, often very much so; I am specifically not referring to these people.)