As someone who regularly interviews prospective engineers at my current gig, I see no problem with expecting candidates to arrive prepared to answer algorithm questions or questions about their strongest programming language.
And as someone growing to be an expert in programming languages, I'd appreciate if Google didn't immediately peg me as "useless academic" for using something other than C++, Java, and Python.
Ditto on Amazon.
I'm reasonably sure I failed a couple of job interviews for being more familiar with Scala than Java.
But given your claim to be an expert in programming languages and that many teams need C++, Java, and Python skills, perhaps a little flexibility on your part would go a long way?
Or given that such flexibility is not an option, why not target teams that need Scala skills instead of complaining about the teams that don't?
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"?
Actually, for reference of why I mentioned those languages in specific, it's because the following scene happened in these interviews:
Interviewer: Could you figure out how to solve a blah blah blah for me in whatever language you prefer?
Myself: By "whatever" language, do you mean whatever language? Is Scala ok?
Interviewer: We'd prefer C++, Java, or maybe Python. Try with one of those.
It's one of those things like the "pieces of flair" in Office Space. If you require an object-oriented, weakly-typed, imperative language whose syntax you've seen a thousand times before, please specify so. Don't put out job ads looking for creative, intelligent professionals who think outside the box and then tell me, when I come to the interview, that I can paint it any color as long as it's black.
A (very naive) friend of mine started programming in Haskell for a job interview because he thought it'd show the interviewer that he was creative, liked to learn things out of the beaten path, etc (after all they said 'your favorite language').
Needless to say the interviewer was very confused and irritated, and asked him to switch to Python/C++/Java after 15 minutes. He didn't get a followup interview (this was with a big major tech company too)
The point of these programming tasks is not to show off your prowess; most of the time the interviewer is trying understand your thought process and maybe some basic programming abilities. Think of it like a sanity-check.
Showing off turns people off because it can lead to negative team behaviors. Being creative to make life better is good, but there's a line between that and being too clever to work with other people.
What's sad is that he wasn't really showing off— he's just one of those computer scientists who loves to geek out and doesn't really think how other people could interpret it; and I guess he was hoping the interviewer would just start nerding out with him, that they'd start talking about how GHC handles lazy evaluation, and that everything would be perfect.
And the interview did its function properly - the position isn't a good fit for that person. If nerding out during the interview about lazy evaluation and purity isn't happening, then its probably all for the better that the interview failed, then to have a disfunctional team with the odd language nerd.
I (and some others) once interviewed a guy who had recently started learning Lisp. He wanted to show off and use it on the whiteboard. Not a problem, theoretically - we've had a guy give us Prolog solutions beautifully explained.
He botched it. We laughed and let him retry in C. He solved it successfully - and also more people than myself could read the solution. Since he was a really junior chap, we didn't really have an issue with the botching.
I am OK with someone showing off. But you have to actually make the run successfully, IMO. Personally, if you can write FizzBuzz as a call/cc continuation, more power to you. I really want to see if you can grasp the upper reaches of computational abstraction in our field, i.e., show off. But trying and failing doesn't really win you points, at least with me.
Comments
As someone who regularly interviews prospective engineers at my current gig, I see no problem with expecting candidates to arrive prepared to answer algorithm questions or questions about their strongest programming language.
And as someone growing to be an expert in programming languages, I'd appreciate if Google didn't immediately peg me as "useless academic" for using something other than C++, Java, and Python.
Ditto on Amazon.
I'm reasonably sure I failed a couple of job interviews for being more familiar with Scala than Java.
Scala is great, I wish it saw wider use.
But given your claim to be an expert in programming languages and that many teams need C++, Java, and Python skills, perhaps a little flexibility on your part would go a long way?
Or given that such flexibility is not an option, why not target teams that need Scala skills instead of complaining about the teams that don't?
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"?
Definitely; I'd much rather do R&D as well. Good luck!
Actually, for reference of why I mentioned those languages in specific, it's because the following scene happened in these interviews:
Interviewer: Could you figure out how to solve a blah blah blah for me in whatever language you prefer?
Myself: By "whatever" language, do you mean whatever language? Is Scala ok?
Interviewer: We'd prefer C++, Java, or maybe Python. Try with one of those.
It's one of those things like the "pieces of flair" in Office Space. If you require an object-oriented, weakly-typed, imperative language whose syntax you've seen a thousand times before, please specify so. Don't put out job ads looking for creative, intelligent professionals who think outside the box and then tell me, when I come to the interview, that I can paint it any color as long as it's black.
A (very naive) friend of mine started programming in Haskell for a job interview because he thought it'd show the interviewer that he was creative, liked to learn things out of the beaten path, etc (after all they said 'your favorite language').
Needless to say the interviewer was very confused and irritated, and asked him to switch to Python/C++/Java after 15 minutes. He didn't get a followup interview (this was with a big major tech company too)
One mistake (of his):
The point of these programming tasks is not to show off your prowess; most of the time the interviewer is trying understand your thought process and maybe some basic programming abilities. Think of it like a sanity-check.
Showing off turns people off because it can lead to negative team behaviors. Being creative to make life better is good, but there's a line between that and being too clever to work with other people.
Yup, that's basically what I told him.
What's sad is that he wasn't really showing off— he's just one of those computer scientists who loves to geek out and doesn't really think how other people could interpret it; and I guess he was hoping the interviewer would just start nerding out with him, that they'd start talking about how GHC handles lazy evaluation, and that everything would be perfect.
And the interview did its function properly - the position isn't a good fit for that person. If nerding out during the interview about lazy evaluation and purity isn't happening, then its probably all for the better that the interview failed, then to have a disfunctional team with the odd language nerd.
I (and some others) once interviewed a guy who had recently started learning Lisp. He wanted to show off and use it on the whiteboard. Not a problem, theoretically - we've had a guy give us Prolog solutions beautifully explained.
He botched it. We laughed and let him retry in C. He solved it successfully - and also more people than myself could read the solution. Since he was a really junior chap, we didn't really have an issue with the botching.
I am OK with someone showing off. But you have to actually make the run successfully, IMO. Personally, if you can write FizzBuzz as a call/cc continuation, more power to you. I really want to see if you can grasp the upper reaches of computational abstraction in our field, i.e., show off. But trying and failing doesn't really win you points, at least with me.
It's only showing off if you think Haskell programmers are better than everyone else ;-).