Hiring: Why Interviewing Should be Technology Agnostic

There are a lot of hiring managers and potential employers who somehow managed to get stuck on "we need a person who is an expert in xxxx technology".  Sometimes, you may have a business case why you need a specialist or a specialized set of skills, but for the majority of circumstances I would argue it is much better to hire an individual for their raw intellectual horsepower and attitude than their knowledge.Objection #1: We are working in Java, so I need someone who can be productive quickly and write code in Java.Yes, if you have someone who has experience with the technology they may be able to ramp up a bit quicker (typically measured in weeks) than a candidate without (even though, in my experience, this has not always been the case).  However, they will still have ramp up time (learning your business, code and technology base, any specialized software, developer tools, etc.).  If you aim to hire someone smart, they will be able to learn on the job (since any new hire will have to do get up to speed quickly).  Candidates who have experience with different technologies are often able to pick up new ones quickly as they are able to apply patterns or methodologies that are familiar to them from past experiences.  This is particularly important because technology changes so much over time.  Ten years ago C was the language to know (followed shortly by c++), whereas now, most interviewers are interested in C# or Java.  You have to be able to jive with the times and continually stay abreast of the tools and technologies that make your skills better.  It is like that saying "It does no good to have great knife skills in a gun fight".Objection #2: Interviews should be given in the language we use.I always have to ask "Why?"  What is the reason that a person needs to write Java because you use Java?  Most interview questions that require candidates to write code are all about the candidate being able to demonstrate how they think.  I am almost always most interested in learning how a candidate solves a problem (are they smart enough to figure out an answer without getting flustered) and then is able to translate their idea into code. Since I know a bunch of different languages I can almost always understand what they write (every once and while there will be the smart ass candidate who wants to write a solution in some obscure language--but thankfully I have dabbled in a bit of those too).  By letting a candidate write a solution in a language they are most comfortable in, chances are they are going to produce a better solution.  And when you are trying to judge a thought process and general smarts--doesn't it make more sense to let the candidate use the tools they are most proficient in?  So as long as you are smart enough to read the solution, you should let the candidate use the language they think they can perform the answer best.Objection #3: Why should I pay for someone to learn on my dime?Well, first making an investment in your people is *never* a bad thing.  But most of all, good hires are hard to find!  There is a reason the recruiting industry is as profitable as it is.  By limiting your frame of vision and looking for such a specific candidate you may be overlooking and missing some incredible talent right beneath your nose.  It is worth training your team on how to interview and calibrate for super bright and talented candidates.  You would be amazed at how many more "qualified" candidates you might find.