The biggest reason I've seen FAANG candidates (mostly Google, FB, and Amazon) get rejected is too much experience with proprietary technology, esp. if they've been there a long time, like 5+ years. I've even spoke to some FAANG candidates who think their internal proprietary tech is widely known or commercial products.
For example the right decisions in a small company vs. FANG is often quite different, potentially outright the opposite. Not just because of differences in people, time and money resources but also due to scale.
Like you spending a day or even week to optimize something to be a bit faster can save millions in just a year if used on the scale of google. But in a startup the pure salary cost of spending a day on it can easily be more then it saves in 5 years. And due to the small number of time and human resources the actual cost can easily be much higher.
You can see this in some of the design decisions around open source tooling from FANG companies. They are often designed for a context of: "Many highly qualified people working at the same time at the same project. And micro optimizations being important."
But what smaller companies have is: "A small group of very mixed qualified people working one it. Rarely more then very small number at the same time on the same component. Most micro optimizations being clearly out of scope. Constantly chasing a schedule where a single larger delay can be a catastrophe for the company."
For example for a FANK company breaking changes on internal APIs are often a no go, but for small companies they can often be a no brainier especially if it doesn't involve any migration complications.
Or for example for Google a single service stopping is often worse then it running amok and creating a mess, for a small company which might only provide one or two services such a mess can mean insolvency, but an outage might not.
Or for example in a small company having a repo where you define all the (internal & external) APIs and use it to generate glue code to bind all your services together in a "type safe" manner can be a grate thing to have (if you have the right tooling). For a FANG company where not just many people but many teams might work on code interacting with the same overlapping APIs this isn't a viable approach at all.
I spent a long, long time in startups before moving to larger companies, and eventually a FAANG. The folks I worked with at the FAANG were incredibly smart, motivated, and collaborative, but a huge percentage of them had no experience outside of the FAANG. They were able to use the in-house systems for build, deploy, data storage, etc. but had never actually had to design and/or build or even think too much about how such things work. It's a great luxury that lets them focus on the product they're building vs. foundational infra, but it's a huge detriment when looking to go outside of those things.
It's ironic, because the System Design interview is a major delineator between lower and higher level Engineers when they interview at these companies, yet many of the tenured people would do very poorly because many of the questions and considerations of the problems presented in such interviews are effectively solved problems in their daily work that they've never had to think about.
Yup, this. I found many ex-Googlers who just don't know how to count up. In the past, "we don't know how to count that low" was a valid joke, but, these days, it seems like a lot of young engineers don't really understand how things work beneath their feet. Every level from 1 to 1k to 1m to 1b is a unique problem, but these kids only learnt how to float above the clouds.
Yeup. I had a similar comment above. I tried phone screening someone, and they had no working knowledge of the commercial apps that we integrate with, the databases we use, etc. And I can hire literally for half the price someone with working knowlege AND know they won't be resentful about the job....
FWIW, I've been trying to make the jump from FAANG to a smaller, stable company for the past few years. I started off in the smaller companies and miss it terribly. I made a bunch of extra money in the FAANG space, but I'm unhappy. Resentful is the last thing I'd ever be, but the lack of working knowledge is a huge issue. I work weekends on building knowledge, but the lack of direct experience running something at scale means I'll never get the chance to make the jump back to the environment I want and thrive in. I honestly wish I never made the jump for the money in the first place.
Exactly. I'm also seeing this trend among new grads/early career SWEs. AWS, MongoDB, and all sorts of cloud first product companies have been plugging their software to the university system, and these kids come out of college w/o understanding of the computing layer below these products. Like they don't know what a server is, what a data center is, how storage works. Is that not being taught in CS programs?
Ugh. I've been interviewing Ops/Sec candidates lately, and I'm genuinely confused every time an experienced candidate struggles with their chosen shell.
> they don't know what a server is, what a data center is, how storage works. Is that not being taught in CS programs?
Not what CS is. (Although I did take a chip-level architecture and asm class, that's the closest it gets to hardware.) If you want a Network/Storage Engineer, hire one.
