It is clearer how to interview someone experienced in Java / C++ or other languages closer to C#. In these cases the language and specific technologies are less important; what matters are the OOP principles.
But how to do it with someone that comes from Progress to .NET and also, me as an interviewer, not knowing Progress at all?
How much does Progress experience count for .NET/C# or OOP?
Are there programming principles in common between the two worlds?
Are these realy two different worlds?
I personally don't think the interview should change based on the persons background.
I don't think interviews should focus on a specific language/tech but rather fundamentals of programming. If the person can't understand basic OOP/database/whatever you need - then that is the problem.
Asking questions about specific tech - be it what he has used, or what you wish to use - doesn't work very well in my opinion.
Ask him about good experiences and bad experiences, ask him to bring some code he is proud of and explain it to you (his ability to communicate is more important than you understanding the code), ask him generic problems that are not tech specific e.g. algorithms/design approaches.
Experience depends on the person, good people will adapt with some time/help, and those who can't are the problem. A good grasp of fundamentals rather than being tied into one specific tech is what you need - after all, you'll want to move to .net 3,4,5,6 etc - you need someone who can handle those changes too.
It bugs the life out of me when people ask questions like what a method/function signature is in a specific language. WHY?!?! Won't you give me a nice powerful IDE if I got the job who remembers this stuff for me? Won't I have access to books/Google/api docs?
Work out if the person has fundamentals and good problem solving - just because another candidate has 'worked with' your tech for 2 years, won't tell you if they have a clue.
I agree with @Jonno. I would add a few things.
Technology changes so rapidly that you really should be looking for intelligent and productive people instead of people with a certain skill set. Whatever they know now will be obsolete in 5 years anyways. A good programmer can pick up a new language in a week or two.
Second, always, without exception, have interviewees write code in the interview. Give them a problem and tell them that they can use the language of their choice. Then evaluate the process they went through to write the code and the correctness of their algorithm.
I also usually give employees a small test that consists mostly of pointer arithmetic and a few recursive algorithms that I want them to convert to functions. Of course, if the potential hire doesn't know C, then that may be out.
No two programming languages are completely different worlds if a person understands the fundamental principles of programming languages. C and c# aren't all that different, just like VB and Pascal aren't all that different. Given that you know programming, it is all pretty easy to understand once you understand how they all work. However, usually a guy that only knows JAVA or C# isn't fit for hiring for this very reason. You don't have to understand much about computers or the theory of programming languages to pass yourself off as a competent JAVA/C# programmer. Also, I would be somewhat skeptical of a one-trick pony.
I usually want people to know c/c++ or something like Lisp at a bare minimum. Not because, they have to know it to do their job, but because it separates the good programmers from the probably bad.
I know this seems somewhat contradictory, and I would join it all together by saying: You don't want to grep people's resumes for a bunch of keywords and find out all of the stuff they know and hire them based on that. You also don't want to just hire people with a background in .NET, because it is easy anyways. You do however, need to find a way to find out if they are a good programmer or not. C is a pretty good indicator.
