How effective are coding interviews?

It's all about scale IMO. If you're a massive company getting thousands of applicants, you simply need to weed out some of them with a basic test.

Personally, I hate "leet-code" style interview questions and nebulously defined take-home tasks.

The best interview questions I've had to answer are where you are given a series of contrived issues on an imaginary system which you have to diagnose and fix. It opens up the room for discussion and it's much closer to reality than fizz-buzz.

That's not the consensus. Indeed, I would say that there is no consensus. Every HN submission about coding interviews results in massive disagreements and arguments.

If the Amazon guy really said that ("inferior human beings") I would not trust his views on anything to do with people.

Leetcode style screens foremost for people who will commit to doing a lot of interview prep. Especially for entry level jobs, some coding is useful to make the person knows a language and how to write code, because there are people that e.g. have done a python tutorial and put that they know it on their resume.

Passing coding interviews is a skill that's different from the skills you need to be successful at (most) programming jobs, but if you've got the skills to be good at most programming jobs, you can get good at passing coding interviews if you put the time in. So yeah, it's a somewhat arbitrary filter, but one that should be surmountable if you put the time and effort in to it.

From the interviewer side, I've definitely encountered candidates who don't seem to know how to write software, so yeah, you have to filter with _something_.

I'm not sure there are any great solutions that work for both sides of the table, but at least if you know how the game is played, you can optimize your performance for it.

A database developer probably can write an arcane form of some radix tree without even putting in effort. I can do that too, but it will take hours and it is questionable if the interviewer is that patient.

If you have done it a few times, it becomes trivial and this is of course also a form of memorization. What you are testing is if a developer has faced similar challenges before and most problems aren't as universal as we often believe. There might just be 0.5 hours of training that puts candidates on basically the same level.

There are maybe are a few tests that can check if a developer is able to solve any problem at all.

I am sure some codegolf form of FizzBuzz will impress most interviewers too. It is fun to do that, but not a required skill at all. Most leet code interviewers tend to be quite inexperienced if they don't know about and cannot assess the limits of their own knowledge. If they did, they would know that they pick people more or less randomly.

If a company looks for a developer for hard problems, they should look for an experienced developer in that field and pay a fitting wage in the first place. And if a position is that expensive already, a direct interview with other domain experts should not be skipped in any case. And sometimes a definite answer is only available after a few months of working together. There might just be very few shortcuts here, you cannot scale that indefinitely.

Aside that, companies are unlikely to have that many hard to solve problems in the first place. They just want cheap labor that is universally good and shove them in a position where they have to solve some Excel problem of management (which of course could also be infinitely hard in some cases).

I think it depends. I like coding interviews cause it can reveal a bit about what it would be like to work with the person. I have to chuckle 'cause MSFT's coding interviews are either "guess what I'm thinking" or impossible problems. I was supposed to code a calculator for one guy and I asked if I could do an RPN calculator, so I did it and after I was finished he asked what the he'll I had done and I said "an RPN calculator" and only then did he ask "what the he'll is RPN?"

I decided I didn't want that job if that's the kind of people I would be working with.

I think my point is coding interviews work both ways and you can tell a lot about a team by how they conduct them.

[edit - it's okay if you don't know what RPN is, the problem is they interviewer committed to a course of action he completely didn't understand instead of asking clarifying questions.]