For many years I recruited exclusively for clients that were seeking to hire Java developers and architects at all levels. When I opened my new recruiting practice almost four years ago, I made the decision to expand my focus and include development shops that were not using Java as their primary language (or at all in many cases).
My strategy to move beyond Java was based on obvious trends in my circles. First and foremost, I wanted to recruit primarily for startups and smaller companies, and I found that startups were not choosing the Java language as regularly as they had earlier in my career. Second, many of the Java pros in my wide network (including many of the most skilled among them) had moved on to focus on other languages. After over ten years building my reputation as the "Java recruiter", I decided it was time to follow some of the crowd.
I can only speak from my own experience interacting with perhaps a couple hundred companies and thousands of job seekers, but I quickly noticed some patterns and trends in hiring preferences within these different language communities that were new to me. The standard comment to articles about languages and hiring will be the thought that language is just a tool, and I get that. Hiring managers might use dozens of criteria (some more applicable than others) to evaluate candidates on paper and my observations may not reflect your personal experience, but I thought it would be worth sharing my experience and hopefully hearing from some readers on what they have witnessed.
Python or Ruby Accepted Here - Shops using Python or Ruby as their primary language widely accepted devs from the other camp interchangably. I can't think of an instance where a candidate was rejected for not knowing the used language if they knew the other. If you know Ruby or Python, it seems you can get hired to use either.
Young Managers and Java "Discrimination" - Younger CTOs and hiring managers seemed less open to Java devs with particular disinterest in Java devs from traditional enterprises. There might be an inclination to claim ageism based on demographics of the Java community, but I found this trend regardless of a candidate's age. A Java developer in her mid-20's at banks or pharmas had it no different than someone twice as old. I also found this trend in shops using other JVM languages. I feel that Java developers from large companies, particularly those with long tenures at one employer, face the most "discrimination" in the startup hiring market today.
Older Managers, Flexibility, and Simpatico - Companies with older hiring managers or CTOs expressed openness to multiple language backgrounds, treating language as a tool. The most experienced managers often cited some obscure language or tool commonality with a candidate ("I too wrote $LANGUAGE once...") or declared that their interest was due to a well-worded project description that caught their attention ("I'd love to hear about what he did on $PROJECT").
For Functional Languages and Go, Interest = Experience - Several clients using functional languages in production treated personal interest in any functional language (demonstrated through self-study, user groups, etc.) as sufficient to grant interviews, and I've found this true (with an admittedly smaller data set) in the Go community as well. This may be due to the relative newness of FP, although I don't tend to find this in other hot language markets with low supply. Self-study and a single GitHub repo seems likely to get you into an interview at a Clojure or Go shop, but might not be enough for companies hiring Node or Angular talent.
Java Shops Most Specific - Companies (regardless of age or size) that primarily use Java have been the most specific on their job requirements and are much more likely to give minimum number of years with the language and related tools than my non-Java clients. One likely explanation for this is that Java shops might be more particular simply because they can be. With the millions of Java devs worldwide, hiring managers can probably find someone with experience using certain frameworks and tools.
I'd be curious as to what readers have experienced out in the wild.