As a side note: never interview in C++. For these types of problems java is just so much easier to work with, and it's easy to learn enough java to interview with in a weekend from a C++ base.
In my experience, interviewers always prefer a good easy solution (java) to a so-so difficult one (C++). Ruby and python are worth a try too, but often they make things so easy that the interviewer disregards the answer--many common string manipulation interview questions are one-liners in ruby.
> Ruby and python are worth a try too, but often they make things so easy that the interviewer disregards the answer--many common string manipulation interview questions are one-liners in ruby.
The problem is not that they are one-liners, the problem is that the algorithm is already implemented for you as a library function, and you just call it.
OTOH, in Haskell a one-liner could perfectly contain the whole description of an algorithm.
I don't think that this is a deal-breaker though. In my opinion the best response you could give in this situation is: "I would use <Library function> [showing you know libraries], however if this was not available I would implement it operating on characters as follows... [showing you understand algorithms]".
A good interviewer isn't going to huff because you have "foiled his master plan to trick you", since they are exploring the limits of your understanding.
I always tell candidates "I am multi-lingual, feel free to answer in any language you want, with bonus points for Lisp or Scheme."
So far no one has taken me up on the latter option. :(
Everyone ends up coding in straight C, rather annoying really. I'd kill for someone to pull out Python or some other language more suited to the problem.
All that said, straight Java is also likely a horrible choice. Boilerplate code sucks. If the interviewer allows it (and some are super strict about these things...) ask if it is OK to mix and match syntax. If someone wants to pull in C# lambda syntax along with making up their own multi-valued return syntax, fine.
Some problems are about demonstrating language mastery (especially for some positions!), other problems are about determining candidate problem solving abilities. For general problem solving ability questions, I'd prefer the candidate demonstrate the ability to think outside the bounds of any one language!
I don't know Clojure, too much time in the MS ecosystem, I don't even have a JVM installed anymore. (I got tired of the constant security holes and updates that try to bundled software.)
I would suggest that you pick the language that you and the interviewer are both the most comfortable that doesn't make you look like an idiot because you barely know it. So for instance if you know java/c++/javascript and the interviewer is a Java coder, go with java. Don't pick some language you are messing around with on the weekend.
It may be a bit counter-intuitive but the person doing the interview can have about as much mental overhead as you while solving the problem. They are likely writing down the answer you are giving and their thoughts on how you are doing. They also have to see where they think you are going to make a mistake and decide if/how to guide you to keep you on track. They also have to handle different styles of answering the question and have to know very quickly if it will work. So using a language they are comfortable with makes it easier on them and since in then end the job comes down to how they "feel" about your performance, making them feel better during the interview is going to help.
That said I did do an interview for a gaming company in ruby because I didn't want to embarrass myself in c++ (which I barely knew at the time). They said after I took the job that it was hard to evaluate me because I was coding in ruby on the board and they were unfamilliar with it. Also I got several "You can do that in ruby?" questions. And one shake of the head when I defined a ease of use method on Hash on the fly to make the solution read nicer.
Eh, I don't know. Always interviewed with C++ with great results. Probably because I know the language and the standard library well enough to be able to write out the solution without looking into google or a textbook. ALWAYS use the language you're most comfortable with. If it's Java, let it be Java. If it's Python, let it be Python. Also, NEVER try to show off by programming your solution in some language you read about on the internet the day before because it's just asking for trouble.
Google's interviews always claim "assuming you have these functions there, now just do the rest." I think in all fairness, C++ isn't making interview harder, it is the type of problem that people need to solve that makes the interview harder. Well, I think that's "no duh..."
Regardless of which language you use, whether it's pseudo or not, you still have to solve problem...
I was interviewed twice this year. In both interviews I answered a question by saying "first, let me cheat a bit" and providing a Python one-liner. Then, I'd proceed to develop a longer version in C. Both times my interviewers were impressed.
I think knowing how to solve a problem in Python (or any high-level language) demonstrated pragmatism and knowledge of the language and its stdlib.
Because in all likelihood, the jobs most of us will be interviewing for will never require us to touch Haskell or ML. I haven't worked with it, but I've worked with Lisp/Scheme/PROLOG and others. I'm always down for learning something new, but I doubt many people here get paid to write Haskell on a regular basis. Or maybe I'm wrong?
And that will continue to be the case, because the overwhelming majority of programmers even in really cutting-edge areas don't need it, so being able to speak Java is still valuable.
Knowing how to write code in functional languages has helped me write Java, too.
Also, of course knowing the functional paradigm helps you write code in all languages but why subject yourself to that level of pain? I'd prefer to let the compiler do the compiling and so I choose an expressive language to begin with.
In my experience, interviewers always prefer a good easy solution (java) to a so-so difficult one (C++). Ruby and python are worth a try too, but often they make things so easy that the interviewer disregards the answer--many common string manipulation interview questions are one-liners in ruby.