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.

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.

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

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?

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.

>plug into a position like lego blocks

Every time I hear someone from big tech talk about being a "L"-something (or in this blog they're "E" levels), I wonder if they know they sound exactly like the bureaucracy talk of the US Federal Government employees and their "GS" "E" or "O" levels.

For better or worse, when you get to a certain size you absolutely NEED that level of bureaucracy. You can't get 120,000 full time employees plus probably another 100,000 contractors to work together without establishing a clear hierarchy that everyone inside it understands. A smaller company can have different approaches because they will have a dense network of employee relationships, and can work together off of those relationships. However, at six figure employee scale by necessity you will end up with a very very sparse matrix of employee relationships, so you have to have something else to get results.

A lot of really big companies have super flat hierarchies when I worked at one we had MPG2, MPG4 then Senior Management U,T,S

Promotion was brutal you might have 20 MPG4 slots every 18 Months for the entire Division (60k FTE) - just getting to the Board Stage was tough enough.

I think a MPG2 was equivalent to a Captain an S was a Grade 7 (GS15 in US terms I think) Full Colonel

You just proved the GP's point. Whether the hierarchy is flat or not is irrelevant, they still have the bureaucracy around leveling and authority/responsibility.

You can't be more far away from the truth.

Thinking outside of the box is very much encouraged and more senior engineers are expected to come up or shape, lead and deliver projects.

FB is company where individual engineers could go and do any project they want - they can even invent it - if they believe that it will deliver big enough impact. After 1 year at FB you can switch team any time you like and your manager does not even need to know what you are working on (it's probably better if they know, as they could many times help you, but no one is micro managing you).

You are assessed every 6 months based on impact you deliver. Your manager supports you, but you need to drive it and deliver it.

Tooling/languages are standardised, but FB does not care whether you do know Hack, or JS. You can do interview in any language (if you are going for generic engineering role). So far at FB I have coded in 4 different languages and picked up all of them as I joined teams.

Even though FB is enterprise company, it feels like startup with great salary, benefits and more manageable work-life balance. Before FB I was 7 years in startups and I have worked longer hours, got paid much less and wasted more time.

I also think FB, contrary to many other massive enterprises, suffers extra much from this bcs it doesn't even make sense as a massive enterprise. It's a social network platform and when it grew too large it mutated into something that in its worst days looks like a scene out of 1984. Hence Lego recruits are needed not just bcs its massive but because they shouldn't be asking the difficult questions.