[wschroed]

Is that a problem of not knowing the language or a problem of not having exposure to better patterns [1] that are generally language-agnostic? I get what you mean about the idioms of some language: code is easier to maintain when it looks like what others on the team are accustomed to. But if that's the problem we're trying to solve, isn't that what initial code reviews of new team members can help resolve, among other things? And isn't that a benefit to hiring people who know other languages well? that they bring in new perspectives and ideas, such that the whole team can grow, over time learning and incorporating those new patterns?

Personally, I look for people who can think, who have exposure to a variety of patterns and can synthesize those patterns into their work, making appropriate choices. More power to us if, for our Perl shop, we hire someone with a strong background in modern Fortran because that different perspective is part of what makes the team diverse, creative, and successful.

I don't look for an expert in Perl to be even a senior developer here. It helps, but the primary consideration is their ability to work with abstract information. The language is just one of many tools to express that solution, and the language choice can change over time to suit needs.

[1] Not to be confused with "design patterns". I am using the term more fundamentally.