[filoleg]

>I don't get why so many developers hate Leetcode.

Because they think that the employer should recognize their greatness by just looking at their resume and having a simple conversation with them, instead of assessing them on some skill that they have to brush up on.

After being on the interviewer side myself recently, I think those people just don't realize how hiring actually works. I've seen some people with impressive resumes and who could bullshit their way around a conversation greatly, to the point where they make you believe they are one of those magic 10x-ers. And when you get to algorithmic problems, they struggle to figure out when or how to use a hashmap and cannot even do some super basic bruteforce parsing of binary trees or even know what they are used for.

Of course there are some edge cases where a great developer would fail a leetcode-style interview, but those exceptions are very rare and only seem to affirm the rule. I know that leetcode style interviewing is far from perfect, but I struggle to think of anything that would work better. A take-home coding project sounds like a great option, until you realize that each one of them takes about a week of working on it a couple of hours a day, which is an unacceptable time sink for any adult with responsibilities and who interviews at more than one place at a time.

[JoeAltmaier]

There are more cases that get under your radar: good developers that won't suffer a coding interview. Folks that don't do well with someone looking over their shoulder and talking to them while they're trying to work. Folks interviewing for a job that isn't simple algorithms.

To be honest, most data structure wonks are great at scaling cloud services or massive middleware business logic. But not all programming is like that.

It's easy to fall into "If they won't do a coding interview, they have something to hide!" But it doesn't (only) work like that.

[filoleg]

> Folks that don't do well with someone looking over their shoulder and talking to them while they're trying to work

I am one of those people myself, absolutely cannot do it. But interviewing isn't like that and shouldn't be. It is more like, cooperatively working on a problem with a colleague and then presenting and explaining it to your teammates. That's a pretty valuable skill at work, even necessary, I would say.

The whole "loner dev in his cave" stereotype, most of the time, just materializes in the form of a dude writing code that no one can understand or maintain, with a cherry on top being that dude not being able to effectively explain it to other people either.

[JoeAltmaier]

Sure that's exactly the same thing. At least what I was talking about. Talk to me while I'm trying to get into the code, is like trying to talk to someone trying to write a book or balance a checkbook or really concentrate on anything at all. Re-casting it as simple cooperation is disengenuous. Sure you want to explain things to a teammate; that's entirely missing the point.

If I'm talking, if I'm listening to you, then I'm not coding. They are orthogonal activities, at least for me. Want me to 'talk you through' my design thoughts? Thanks for your time, goodbye.

[wvenable]

> After being on the interviewer side myself recently, I think those people just don't realize how hiring actually works.

As an interviewer I've never had to give a coding test and I'm not about to start now. I've had people try and bullshit -- not really on purpose -- but asking specific questions weeds them out easily. Often times they don't even know they're failing the questions.

I have a less-technical manager come in on my meetings and by the end he could spot those people who failed without any knowledge of programming at all.

> Of course there are some edge cases where a great developer would fail a leetcode-style interview, but those exceptions are very rare and only seem to affirm the rule.

I did all this binary tree stuff in University decades ago -- I only have so much brain space and studying all this again is going to push out the interesting stuff I'm working on right now.

[ex_amazon_sde]

Leetcode focused on tricks and memorizing algorithms.

I've rejected a good bunch of candidates that can pass coding tests while not having any good understanding of theory, hardware, OS, networking, security

[filoleg]

>I've rejected a good bunch of candidates that can pass coding tests while not having any good understanding of theory, hardware, OS, networking, security

Those are valid points, fully agreed. I think the discussion of those topics must be included in an interview process and discussed in-depth too, leetcode-style problems are not sufficient enough on their own.

>Leetcode focused on tricks and memorizing algorithms.

Strong disagree on "memorizing" and only partially agreed on "tricks". Those "tricks" (like knowing that you should use a hashmap when you need a key-value datastructure, or memoizing [aka caching] repeated operations) are very useful in real life problem-solving situations at work. I can tell you for a fact, I don't remember almost any particular problem from leetcode, and I ended up solving certain problems multiple times on leetcode, because I couldn't recognize them at all. However, thanks to leetcode, I obtained a pretty solid intuition on which approach to use in a particular situation, and it helped me out in the workplace immensely (even if I don't directly implement those approaches or remember the specifics 99% of the time).

[bunfunton]

So why not give a simple coding test? Talk through peoples thought processes. Giving leetcodes only reward people who have grinded leetcode. Grinding leetcode gets you better at solving leetcode and takes tons of time

[filoleg]

> So why not give a simple coding test? Talk through peoples thought processes

What do you mean? That's pretty much what leetcode-style problems are during interviews. You get a problem with some theme, like "here is a list of airplane flights in an array composed of tuples, with the first member being origin, and the second being destination. Write code that would create full-blown routes out of those flight entries."

You ask questions, clarify constraints, come up with a few approaches, discuss with the interviewer pros and cons of each, decide to go with one, implement it while walking the interviewer through your thought process. And then you discuss limitations and edge cases, scalability concerns, how you would test it if it was a problem you were solving at an actual workplace, etc.

Leetcode-style interviewing doesn't typically refer to "we just pulled a random problem from leetcode, go ahead and solve it while I am standing over your shoulder, and we will check how correct the solution is afterwards." In fact, interviewers care way more about the thought process and your approach, as opposed to caring about your solution matching theirs. In fact, there were many cases where people ended up not solving the problem and passed the interview anyway, as well as cases where people solved the problem and ended up not passing. Because the process of arriving at the solution and the reasoning you took to get there matters way more when hiring (even if you didn't get there all the way to the correct solution), as opposed to just getting the correct answer. The fastest way to fail a leetcode-style interview is to sit down and write down the correct solution as fast as possible, without explaining your reasoning process or even anything at all.