3 ms·

There is this weird meme that using Python is beneficial during interviewing -- you mention it, the OP mentions it, I have experienced it myself and seen friend

There is this weird meme that using Python is beneficial during interviewing -- you mention it, the OP mentions it, I have experienced it myself and seen friends mention it. I don't know how or why this meme infects people; in my interview experience (MSFT, Google, Oracle, FB, Amazon, other smaller places) nobody ever batted an eyelid on me using C#. My advice would be to only use a language you know best, as long as it's appropriate for the role -- and most mainstream languages would be appropriate for generic FAANG SDE roles. Using the language you know best will bring all sort of benefits -- you'll code faster, you'll be more confident, you might even find a place to show off a little. There is no good reason to give this advantage up.

kenhwang 6y ago
Python is beneficial in that everyone understands or can learn to understand basic Python in the time it takes to do an interview. However, due to the whiteboard and performance focused aspect of the typical coding interview, Python is actually kinda an awful language to interview with. Plus, if you want to be terse with Python (whiteboard space is limited after all), it quickly becomes alphabet soup. If I had to describe the perfect interviewing language, it'd be something with C/Java-like syntax, but without the cruft, that can optionally be typed, with easy fine grain control over looping. All the big-tech companies work with way too much Java, but Java is way too verbose for coding by hand. C# is about as close to Java as they come. Scala/Kotlin is excellent if you write it like Java.
- pseudalopex 6y ago
  O(n) is O(n) in any language. And how does Python become alphabet soup?
MakersF 6y ago
This, absolutely this! I did a lot of interviews (as interviewer) at a non-fang-but-close-enough, the guideline was to tell interviewees to pick the language they most prefer. Even if we didn't know it, the valuable part was the problem solving, and the candidate could display good communication skills by explaining the language features you were not familiar with. This is much better than picking a language that you don't know (happened several times that someone picked python, and when asked to write a class said "I know how to write classes in java". We switched to java, no problem.)
sombremesa 6y ago
It took me 1 second to think that Python has divmod built-in whereas you must import Math in C# to use DivRem. It's just little things like that - as well as boilerplate - that really makes a difference in these interviews. How many of these interviews resulted in a job offer? I disagree with eyelid-batting being the new success metric.
- wanderer2323 6y ago
  I feel that you think of the interviews as if they were a competitive programming contest. If I needed a DivRem function I'd just write it in, `import Math` optional. In fact I probably wouldn't remember the exact name of the function and would've just 'created' a new one: `Tuple<int, int> DivideWithRemainder(int dividend, int divisor)`. You can just write signatures for functions like that on a separate side of the whiteboard and invite your interviewer to tell you if they want to see any of them implemented. I would advice this as a general approach -- split things into (reasonable) parts and implement them in order of importance. In one interview (Amazon) I ended up implementing every small thing I parceled out. In others my interviewers seemed to appreciate that we both care a lot about the `solution flow` and the `technically hard` parts and not at all about `DivideWithRemainder` or `import Math`. I got offers from most of the places that I interviewed at.

kenhwang 6y ago

Python is beneficial in that everyone understands or can learn to understand basic Python in the time it takes to do an interview. However, due to the whiteboard and performance focused aspect of the typical coding interview, Python is actually kinda an awful language to interview with. Plus, if you want to be terse with Python (whiteboard space is limited after all), it quickly becomes alphabet soup. If I had to describe the perfect interviewing language, it'd be something with C/Java-like syntax, but without the cruft, that can optionally be typed, with easy fine grain control over looping. All the big-tech companies work with way too much Java, but Java is way too verbose for coding by hand. C# is about as close to Java as they come. Scala/Kotlin is excellent if you write it like Java.

pseudalopex 6y ago
O(n) is O(n) in any language. And how does Python become alphabet soup?

MakersF 6y ago

This, absolutely this! I did a lot of interviews (as interviewer) at a non-fang-but-close-enough, the guideline was to tell interviewees to pick the language they most prefer. Even if we didn't know it, the valuable part was the problem solving, and the candidate could display good communication skills by explaining the language features you were not familiar with. This is much better than picking a language that you don't know (happened several times that someone picked python, and when asked to write a class said "I know how to write classes in java". We switched to java, no problem.)

sombremesa 6y ago

It took me 1 second to think that Python has divmod built-in whereas you must import Math in C# to use DivRem. It's just little things like that - as well as boilerplate - that really makes a difference in these interviews. How many of these interviews resulted in a job offer? I disagree with eyelid-batting being the new success metric.

wanderer2323 6y ago
I feel that you think of the interviews as if they were a competitive programming contest. If I needed a DivRem function I'd just write it in, `import Math` optional. In fact I probably wouldn't remember the exact name of the function and would've just 'created' a new one: `Tuple<int, int> DivideWithRemainder(int dividend, int divisor)`. You can just write signatures for functions like that on a separate side of the whiteboard and invite your interviewer to tell you if they want to see any of them implemented. I would advice this as a general approach -- split things into (reasonable) parts and implement them in order of importance. In one interview (Amazon) I ended up implementing every small thing I parceled out. In others my interviewers seemed to appreciate that we both care a lot about the `solution flow` and the `technically hard` parts and not at all about `DivideWithRemainder` or `import Math`. I got offers from most of the places that I interviewed at.