I happily and successfully hire people who don't speak the language(s) we use, but use languages in the same general area. I've shied away from hiring people who have no experience in the area at all. For instance, I'll hire within (Java, C#, C++, Objective C) reasonably happily (and that's not a complete list), or (Python, Perl, Ruby, Lua, JS) fairly happily (with a special callout for JS to distinguish between "JS but only in the browser" and "actually knows JS", the former not necessarily counting as knowing how to program at all), but I hesitate to hire if you have no experience in the target cluster.

I think it's a big mistake to avoid hiring a Python programmer because they don't know Ruby, but it's one people seem happy to make, even in otherwise relatively enlightened organizations.

Unless you rely on a whole tightly coupled environment, like .NET+WCF, or some enterprise Java solutions and the question is based on them - the language in the answer shouldn't matter. If the candidate knows more than one language, they can learn more. Unless you need some specific framework/library knowledge, the rest is just syntax. And that's the least important part of programming.

Exception: first jobs and very inexperienced people. Basically if the answer is given in a specific language because they don't know any other and couldn't produce the answer you want after short time of studying relevant docs, then it may be a real problem.

The only real difference I see is whether or not I personally know my way around the language in use. If I don't know much about it (Haskell comes to mind), I have the candidate explain how to read the code. Doesn't happen often frankly, but I find it quite interesting, also gives me insight into how well I can understand stuff the candidate is explaining.

I suppose the only thing that would make me frown is if the candidate was evidently a huge language zealot and wanted to use nothing but their language of choice. But I've never interviewed such a person actually.

I don't place much importance on the language used, but then my team uses a bunch of different programming languages because we integrate existing systems more than we write new ones from scratch. However, I do think the language choice itself says a lot about the person. If they reach for C, they're probably more interested in systems programming. If they reach for Ruby, they're probably more interested in web app development. If they reach for Bash, they're probably interested in SysAdmin-type work. Does their language choice reflect an interest in the job they're applying for? If it's reasonable to expect the person to know multiple languages well (i.e. they're not doing their first internship in college or something) I also want to see them pick an appropriate tool for the job. What I'm really looking for, is if the language they know best is actually a language they know well. If it's not, that's a red flag to me. I wouldn't say it's bad to do an interview in C# when applying for a job at a Java shop, but all other things being equal, using Java would be better, IMO.

For general roles, it's a question of how much you are willing to invest in a candidate before he/she starts producing. Big firms like Google/MS/Amazon are willing to hire strong candidates who aren't familiar with a given stack. A young startup might (understandably) not be able to pay someone for a few months to ramp up on a stack that's not familiar to the candidate.

That is subtly wrong, because there are really two things there: there is the language itself, and there is what has already been built with it. Say you get a really strong Perl guy, but you use Python. At a startup, he just has to learn the language. At a big company, he has to learn the language and the last decade's worth of codebase.

You are missing the point - startups don't always have the time/money to train someone in a new language. That's why they are looking for Javascript Ninjas who can hit the ground running. Established firms inherently have money to invest in training if they choose to.

If you have hired the right person they will very quickly "train" themselves and the only cost to you will be a slightly slower start (which will resolve itself in days to a couple of weeks max) at producing real code.

Well worth it if the alternative is hiring someone who knows the language/framework you're working in, but pretty much only knows that language/framework.