Leetcode style coding interviews are great because:

• They allow companies to efficiently filter applications.
• They are standard and transparent, which makes them relatively fair.
• They show your ability to commit to learning something.
• They ensure the candidate will not write plain bad code in some rare situations.
• Grinding leetcode makes you a better engineer (if you leave out the opportunity cost)

But they have many drawbacks:

• They have little to do with the work you’ll be doing.
• Some people optimise for it, you end up with great leetcoders that could be very bad on the job. It’s even sadder when it’s students.
• Amazing engineers got where they are through hard work in their fields, not grinding leetcode everytime they are switching companies (appart if it’s a hobby for them). Despite being amazing they will fail if not trained specifically for that.
• The output is almost always binary, you solved or you didn’t solve the problem. A lot of the SDEs I have around me will not let you pass if you didn’t solve their problem, even if you showed [how?] “great communication skills”. Also, most problems only allow for a binary output, very few inherently have intermediary milestones.
• Sometimes, the interviewer themself would not be able to solve the problem they are giving, which is 1) ironic and 2) makes them not competent to guide the interviewee and therefore more likely to make their decision rely solely on whether the problem was solved/not solved.
• There are interviewers whose primary focus is that the code you wrote in Arial on a Google Doc compiles.
• Sometimes, the same question gets asked twice in the same interview process or the interviewee already trained on the problem.
• It makes some people anxious, even some great engineers.
• Out of the people that find it absurd, the leetcode interview will favour the ones who are most willing to tolerate its absurdity.

Now some notes:

• Leetcode sucks, but if you use it in your process anyway, at least please don’t use it for internal transfers, and train interviewers.
• I know teams at Amazon who don’t do leetcode interviews, so if a team does it, know that it is not necessarily because of an Amazon wide hiring guidelines.
• Categorically refusing leetcode interviews could make you miss out on opportunities that could make your life better for multiple years, even if it sucks it’s maybe worth the time.
• I know people who think leetcode sucks but still ask those questions when interviewing candidates. Provided this is not obligated by the company, that is NOT ok.

Leetcode is like crypto’s proof of work, “I will know you are legit if you prove to me you spent hours grinding”. Just like it would be amazing to get all the GPUs in bitcoin farms to work on something [directly] useful, imagine what could be achieved with the amount of brain-years that is being spent every day on grinding some coding puzzles that will be forgotten 2 days after signing the offer.