A physicist we hired, partly because of her impressive "language lawyer" level of C++ expertise, left for a two-week trip back to her home country, after several months of knocking out project features at what had seemed to be a very respectable pace.  In her absence, the project technical lead tried to implement what should have been a minor change, and ended up spending several days tearing his hair out, just trying to make some sense of her code.  When the original developer returned, she explained that MFC simply wasn't "object-oriented enough", and that she had essentially just replaced large areas of the framework with her own, more "correct", versions of existing APIs.  According to the usual definition of "Mort"s and "Einstein"s, this engineer was definitely an Einstein, but she was an Einstein who was FOCUSED ON THE WRONG THINGS!  Aside from the fact that our code base was now inconsistent with all published API information and no one else could ever hope to understand or work on her code, her decision also guaranteed that we would be treated to all kinds of random errors whenever Microsoft got around to updating its MFC dlls. 

As frustrating as it can be to deal with "Mort"s, the tendency of many "Einsteins" to resist learning (or unnecessarily insist on replacing) standard framework capabilities, can derail projects, and permanently cripple code bases, so it always bothers me when I hear respected figures in the developer community suggest that testing for knowledge of specific APIs is irrelevant when it comes to evaluating engineering candidates.

"Our philosophy is that we're hiring for the long term, and any technology you happen to know right now may well be obsolete next year"

- from Joel Spolsky's (in all other respects, definitive) guide to hiring developers, "Smart And Gets Things Done"

I agree, in principle, when Joel says it makes absolutely no difference whether an engineering candidate is familiar with a particular technology or buzzword -- until you discover that those same developers who are unfamiliar with "MSMQ" turn out to have been supporting a .Net-based client-server application for the past several years, and written a complete network fault recovery system from scratch... or their own transaction support... or their own approximation of role-based security...  Again, these are examples of Einsteins hard at work, when what you really needed was an API expert (at least until they could demonstrate actual DEFICIENIES that couldn't be addressed just by modifying or extending the existing feature set).  Similarly, the Einstein who claims that an understanding of Design Patterns and Object-Oriented (Behaviour-Driven) design, and unit testing... trumps any need for expertise with a specific development framework... may now be sidetracking the members of your project into building and supporting a "better" MVP-based UI framework, when the cost-benefit trade off on that, especially for non-trivial, highly-customized, WPF-based UIs, is still far from clear. 

For the kind of projects I work on, (and that most companies who are interviewing Windows developers usually seem to be seeking to staff), the ability to write low level data structures or sorting algorithms, which is how many organizations test for what they think are Einsteins... is completely irrelevant (and absolutely the LAST thing you ever want your developers to even THINK about doing), while an in-depth understanding of the various considerations involved in using, combining, and modifying, elements chosen from the huge pool of components available in the BCL and elsewhere... is absolutely ESSENTIAL.  Testing a candidate's understanding of specific APIs also gives you some indication of whether that developer has the potential to be productive IMMEDIATELY.  you want your new engineering hires to be familiarizing themselves with the PROBLEM DOMAIN rather than spending their time to learn a new development API.  You also want to ensure that a new developer's code is not going to cause problems for everyone else on the project and, no matter how brilliant someone may be when it comes to CS fundamentals or high-level concepts, with the learning curve for new technologies like WPF, and the breadth and depth of the ever-evolving framework, its probably not unreasonable to expect code written in the first six months against an unfamiliar API to require an extensive amount of rework.

I've occassionally recommended candidates who impressed me as being super-smart, even though they had no direct experience with the specific Windows development technology we were expecting them to use, but only when their performance in the interview suggested they had made the effort to aquire an IN-DEPTH understanding of whatever technology they HAD been using -- with special bonus points for the rare candidate who could demonstrate familiarity with preliminary CTP releases of UPCOMING Windows dev. technologies, since they were unlikely to waste time inventing their own solutions without bothering to at least first fully understand the capabilities of solutions already provided, or which might soon be available.

In fifteen years as a developer, I've had to rewrite ALOT of code created by Einsteins with advanced degrees (my only degree is in Asian Studies), and show them how to write maintainable code and make proper use of available framework features... while I freely admit that I couldn't write a basic sorting algorithm or low-level data structure to save my life.

The only time I ever missed not having a more formal Math/Engineering background, was when I once got stuck trying to calculate a particular coordinate in the drawing routine for my ActiveX "CoolLabel" control, and I ended up finding the solution (calculation of a "polar" coordinate) only by flipping through an illustrated Math encyclopedia three days later.

(Hey, this feature wowed them back in '97, and the associated mapping product sold hundreds of thousands of copies)