It's amazing how many cold calls you get if you mention Hadoop in your LinkedIn profile or resume. It's also a bit myopic: the strength of Hadoop and MapReduce in general is a simple, scale agnostic programming model. I can give somebody Tom White's book and they'll be able to write working code in few days.
My team uses Hadoop extensively, but while a background with Hadoop never hurts (it's a great system that solves a difficult problem, but it has many quirks and rough edges that need to be worked around) it's much more important that the candidate is a great programmer and has domain specific skills (in data processing, information retrieval, machine learning, statistics, numerical analysis -- the tasks you typically use Hadoop for).
Asking "how do you compute <some function> over <some dataset> on a cluster of unreliable, commodity machines, communicating through message passing" is a much better interview question to use than "what is the difference between TextInputFormat and SequenceFileInputFormat" and "what is the interface you implement to specify a custom partitioner and how do you configure the M/R job to use it".
Yeah, but its a practical necessity to have at least one person on the team who really groks hadoop, and has experience with the "quirks and rough edges." I wonder how many of the companies calling you need that person, or are just looking to add more programmers.
> Yeah, but its a practical necessity to have at least one person on the team who really groks hadoop, and has experience with the "quirks and rough edges." I wonder how many of the companies calling you need that person, or are just looking to add more programmers.
This is true for an architect or principal-level position (but how frequently do people hire externally via a recruiter for that? Typically such people are promoted from within or are referrals), but if you need somebody to develop data infrastructure (whether on top of Hadoop or not) Hadoop knowledge, while very useful (more so than for a data application development position), is still secondary to ability to reason about distributed systems (a parallel and asynchronous system lives in an Einstenian universe with each processing having its own frame of reference, as opposed to a synchronous shared memory system which lives in a Newtonian universe with an absolute frame of reference), understanding of storage hardware/operating systems/memory management/network communications (other important domain specific skills) and general programming (particularly being able to come up to speed with a large, fast changing open source code base).
You're right however, at times companies may be looking to sex up a position to attract enthusiastic but young/inexperienced developers who don't understand that learning any specific technology is not as important as learning new concepts or being up to speed on new technologies in general (a narrow focus of one company may put one out of touch with the overall technology curve).
