Hacker News Reader

Comment by Uberphallus | Hacker News Reader

I kind of agree with your cynicism, but I'm partial due to having been refused by Facebook, twice.

The first time I made the mistake of using Python (because of its whiteboard value) while not being proficient in it. They really didn't like me Googling some basic stuff.

The second time I still used Python, but had 5 years experience using it behind. Can't be objective but it was probably the best interview I've ever done. Reviewed my code afterwards, and could only come up with minor improvements. Got refused, I asked what could I improve and I got a very generic "not a good match for the team" which, in retrospect, reading your comment, could have been very accurate.

View on HN

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.

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.

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

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.)

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.

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.

Coding a good solution is necessary but not sufficient to pass an interview. Maybe you asked too many questions or not enough, maybe you solved the problem too slowly. Interviewers for better or worse look for specific signals that clue them into your being a good coworker. It's why even if you're a good programmer you may need to apply multiple times before the right set of interviewers grant you admission into their club.

> It's why even if you're a good programmer you may need to apply multiple times before the right set of interviewers grant you admission into their club.

That would imply to me that their interview process is fundamentally broken.

It could also imply that they simply get more good applications than they need. Everyone and their grandma seems to want to work for Big N, after all.

Can fail behavioral or design interviews while passing coding and not get hired. Can also have written what you thought was good code but have been given too many hints. Or, could have written good code to the question asked, but took so long that interviewer didn't get to a second question and you wouldn't ever know that.

Reply on news.ycombinator.com