I actually can program in C, C++, Java and Python just fine, and I've repeatedly told the companies so (and have published portfolio work in Java and Python). Where they faulted me was for falling back on Scala syntax in my psuedocode answers to interview questions, rather than immediately jumping into "ordinary thought" in an imperative, weakly-typed, object-oriented language.
If I worked with X most recently and I tell you so, could you allow that I'll have X at the top of my head in the interview rather than Y, Z, A or B? I'm not going to totally swap-out everything about my last job and my hobby projects from my brain for the sake of someone who hasn't even offered me a job yet.
"being more familiar with Scala than Java" is a few miles east from "cannot/will not write pseudocode comprehensible to people who don't grok functional languages".
As with most communications distances, that depends entirely on where the other person is sitting. I never use monads, for instance, and only use type-classes when they look really applicable. Still, if the person I'm talking to has never heard of a map() primitive outside of MapReduce, that causes issues.
And then the #1 thing that really causes friction is recursion. Most people interviewing on behalf of BigCo's seem to think recursive algorithms are dirty and will always/almost-always overflow your stack. I learned in second-semester of freshman year of college that with a little work, every recursive algorithm can be made tail-recursive can be made iterative, and that rejecting recursion wholesale is premature optimization.
The best interviewer I had on the topic (who couldn't offer me a job because I'm a hardcore algorithms/CS guy and he ended up needing front-end web developers, no harm no foul) accepted my recursive answer and then proceeded by asking me to make it iterative. That was the best, in my opinion, both because it shows a level of "academic" knowledge about recursion and iteration, but also because it was exactly what I would have to do in a real job situation: transform a theoretically correct algorithm into a usable implementation that can perform well.
The people I want to criticize are the ones who seem to believe, or want to believe, that no such usable implementations of functional or academic techniques can exist, categorically, and hence that anyone who answers a question with anything so "functional" as a recursive algorithm must be a stack-overflowing, head-in-the-clouds academic or simply an amateur. Hence why I bring up Scala and why I'm not much of a Haskell programmer: it's damn well readable and usable for people who aren't functional-programming gurus, you can write code in it that plays well with CPU and memory, you can use a wide ecosystem full of libraries, and it comes with just enough functional magic baked into itself in just the right way to make the "magic" parts (like the Option functor) easy to learn and use for people who don't care about functional programming theory.
Funny, a lot of the technical questions I had to do in pre-screens and in the interview itself were naturally solved via recursion and were what the interviewer was looking for. This is both with Google and large financial companies.
Like I said, the interviewer who asked me to convert recursion to iteration, who knew something about it beyond "Dirty!", was a great guy with whom I had a great time. The fact that my quite-sufficient-in-his-opinion algorithmic skills ended up not being what his company actually needed doesn't change that it was a wonderful interview.
I write tail-recursive functions in C using gotos sometimes. I figure why bother with recursion when the function call would be two jmps, register spills, and stack growth?
I'd say you are doing it right, it's just too bad the companies you had these experiences with don't understand you are a solid candidate.
It's really not that bad. I ended up back in academia getting a funded MSc, and at this level I'll be interviewing in summers or at the end of my degree for industrial positions that are more in line with what I want anyway. Why not walk to the door that says, "Research and Development Engineer" rather than "Generic Software Engineer N+1"?
If I worked with X most recently and I tell you so, could you allow that I'll have X at the top of my head in the interview rather than Y, Z, A or B? I'm not going to totally swap-out everything about my last job and my hobby projects from my brain for the sake of someone who hasn't even offered me a job yet.