I worked at a company, not a FANG, but had interviews like a FANG. We had a solid team. But some of us believed we wouldn't be able to pass our own interviews.

isn't this what's happening at FANG companies: the gatekeepers (i.e. people giving interviews) have an incentive to not let people in too easily? This limits the pool of employees, and since what's rare is expensive, makes insiders more valuable?

Also at FANG companies, interviewing feels (to me) like hazing that is unrelated to what the day-to-day job will be like. Some interviewers I had obviously had a very high opinion of themselves..

Our incentive is not (as you imply) a selfish desire to enrich ourselves though artificial scarcity, but rather the knowledge that a weak team member hurts everyone and is hard to get rid of. At my firm we have the explicit goal of hiring people who are better than half the developers at similar level. A little math will show you that if you do not do this, your average talent level goes down over time.

Oh I wasn't thinking of selfishness in this situation (I didn't use that word, but i was thinking of how purely rational economic actors would act), merely that there is a subconscious incentive to act one way. Of course you are right, interviews serve as a filter, one wants the newcomer to increase the output of the team, not decrease it ;-)

Another issue is that hiring is expensive and FANG companies have a ton of applicants. Raising the bar on algorithmic interview performance is a straightforward way to filter applicants that is relevant to job performance. After the initial screen it's still hard to make the case to hire a smart engineer if one or two of the interviewers have concerns about their interview performance.

I think there's a natural desire to want to hire people who are better than you are. Sprinkle in a little dunning kruger effect and I can see how a good team can end up feeling like that.

These days I honestly think that a developer who is marginally above average but plays well as part of the team is much more valuable than someone super smart who isn't a team player. We rarely need to solve complex algorithmic problems these days, just plug some components together and work out why they aren't working.

I have not seen any interview problems where you have to debug an issue having limited information as often is the case in embedded systems. You have a set of logs and the source code to look at. The description of the problem is "X doesn't work" where X is some protocol or procedure. This is something that took me a lot of time to become good at (to not freak out, but to be systematic).

I saw it once, I think it might have been in an interview with Scale API?