There is a lot of resentment towards Algorithmic challenges here, I guess most of it is from folks with non-CS backgrounds and possibly from folks who are "non-FAANG".

First off, I hate the "FAANG" acronym, its become a status symbol of some sort and is used so frequently in d*ck measuring contests on social media. I am cognizant of the fact that there are SDEs and great SDEs even outside of BigTech.

The reason Algorithmic challenges are used so frequently in FAANG companies is that when done properly they can be standardized pretty well with minimal source of biases. When done properly, you can observe candidates thinking out loud, communicate properly under time pressure which is what is required at most tech companies. Also, LC style problems cannot be memorized, you have to be incredibly lucky to see a problem you solved recently or the company's hiring process is so broken that their questions are already known to public.

Algorithm challenges are basically testing what you learnt in your undergrad CS curriculum, the topics are limited to fairly standard stuff you learn at university, regular DS like Stacks, Queues, LL etc and algorithmic techniques like DFS, BFS, Sorting, DP etc. Once you have done enough of these problems and understand them well enough, the LC interview isn't that tough. This is coming from someone who has been giving at-least 2 interviews a day for the past 2-3 weeks. I won't say my hit rate is 100% but I am fairly confident that given a problem I haven't seen before, I could solve it in an interview setting under time pressure. You face this situation quite frequently at most tech companies as part of your job.

At the same time, I would whole-heartedly agree that 90% of the work at tech companies doesn't involve applying Algorithms in real life. Never have I faced a situation where I have read an algorithm in textbook and applied it at work. Although, having worked at one tech company, I did see quite a few DS/Algorithms being used in real-life in Large scale services. I remember seeing Tries being used to speed up string search in some services in Exchange at MSFT, I did see clever applications of Bloom Filters, if you peek into the source for .NET Dictionary and you see how hashing is implemented in the real world. Say that the Keys you use in your real-world application are for some reason unevenly distributed and you store them in .NET dictionary, your read queries would considerably slow down and that might not be optimal for your customers. I wish that this were a contrived example but it isn't, I have seen many such situations occur at MSFT where Engineers didn't properly think of trade-offs when designing large scale systems. Algorithmic interviews can be a good filter to test these skills.

Also most tech companies don't necessarily want to hire domain experts. That does happen but only rarely and most teams are fairly generic, they aren't working in specific areas like Databases, Networks, OSs etc. I see folks saying that they are really great with specific frameworks but truth be told, Tech companies would rather hire someone who can learn specific frameworks on the job under extreme time constraints. I know that this is the exact opposite of Startups and smaller companies who need "domain experts" to ship stuff sooner. Amazon doesn't require new folks to know Spring MVC, MSFT doesn't require new hires to know .NET MVC etc, they all want developers who can pick up any XYZ skill whenever the job demands it. I know that quite a few of HN users might look down upon that and you have every right to, but that really is the job at BigTech. Most engineers are fungible, even though you cannot like for like replace engineers you lose. But at the scale that they are operating that is the only way.

Algo challenges test for raw intelligence, period. Now, even Algo challenges have varied levels of difficulties. I have heard horror stories of interviewees being asked questions that require particular tricks or complicated DS like Segment Trees etc. Unfortunately that does happen.

Also, most companies have rounds where they do test "domain knowledge", skills like OOD, System Design etc. Although I admit, these two are also beginning to be gamed. There are websites that sell "courses" for these and its getting to a point where interviewees just regurgitate info from these courses even if they haven't used them in real life at work but that is what happens when you deviate to something that is difficult to standardize. Additionally, from the interviewers perspective its difficult to judge what contributions interviewees have made to an organization when they haven't closely worked with them and the work might be in a domain they aren't familiar with, that is unless you have made major contributions to OSS, which can be verified easily.

Finally, I have to admit that in all this frenzy I just seem to have gotten lucky. I finished university four years ago. Algo challenges were wildly popular during my time and I still like solving them, although I am not as prolific as some of the folks I know in Bigtech. I did a lot of it in University and that helped me tremendously in interviewing at Bigtech. I realise that HN folks come from a diverse set of backgrounds. Some of you are much older and have familial commitments which certainly makes it tough to "practice LC" along with your work and spending time with family. In that, LC is really a young man's (or woman's) game and I have to admit that I have been a beneficiary of that. I can only soothe you by saying something cliched, Life isn't always fair.