I tend to think that "concurrency" is currently hyped, overly feared and therefore a good litmus test if you're looking for a "good, up-to-date" developer. Let me elaborate:
1. Concurrency is not trivial, but it's a well-researched, well-understood and really well documented area, where the only really new development is the wide-spread awareness that it's relevant for all developers, not just those in a niche.
2. However, all that's really required to master this topic is the usual process of skills-acquisition that good developers go through all the time - what steps that entails, exactly, depends on personality: for me it always starts with first reading the masters (Doug Lea, "Concurrent Programming in Java"; Doug Schmidt, "POSA 2"; Josh Bloch, "Effective Java", the Java Language spec (for the memory model), the Enterprise JavaBeans spec if relevant ... and yes, Ben Evans' and Martijn's "The Well-Grounded Java Developer"), then the relevant blogs and articles, and then the really good JavaDocs for java.util.concurrent, etc. when writing code.
3. The only real difference in understanding concurrency vs. many other development topics is that due to the probabilistic nature of concurrency "just trying it out" will never be enough: some understanding of the underlying theory and conceptual models is really necessary.
4. Even newer developments, like Akka or the concurrent Scala collections, are just variations on the classical concurrency themes: there's lots of accidental complexity to master, to be sure, but nothing inherently new.
5. But because concurrency right now has a lot of mind-share, it's probably a good topic to ask in an interview even for jobs where previously it wasn't considered central. That's a good thing IMHO, because concurrency knowledge probably does tell something about the developer applying for the job, even if she won't be writing concurrent code day-in, day-out.