We need to band together and stop rewarding companies who pull this shit in interviews. Leetcode problems are not applicable to 99% of the actual work in most software engineering roles. There are other, gentler ways to find out if someone knows what binary trees, dynamic programming, sorting, and big O notation are.
Not being directly relevant to the role also has its benefits. It means that you can interview for a job without necessarily having experience in the company's exact problem domain or with the framework that they happen to be using this quarter.
True, but the algorithms challenges are not very representative of the actual work we do in our industry. They are a nice way to filter people who are not willing to spend a lot of time studying challenges to have job interviews though.
> They are a nice way to filter people who are not willing to spend a lot of time studying challenges to have job interviews though.
They filter for general problem solving skills. Whether you acquired those skills through a degree, self-study, a week of leetcode or 3 months of leetcode will be up to your individual background and aptitude. It's a hiring process - filtering for something is the whole point. Personally, I prefer being tested on more general stuff (like algorithm problems) over most of the alternatives.
They filter for memorization. Most leetcode problems you will not be able to solve in the allotted time without first being familiar with the problem or one very similar to it. Because most of those problems (and many CS algorithms) hinge on a certain "trick" to solving them.
The way to pass a leetcode interview is to know exactly what the interviewer is asking and then pretend like you've never seen this problem before. Then you amaze them by pulling a rabbit out of a hat. We are all a bit dumber for putting up with this charade.
Or they are just seeing how well your pattern recognition and subsequent application of an efficient solution. The problem is our industry is full of people who put their whole self worth on intelligence and then pick learned skills to judge anyone too harshly that hasn't worked through algo and data structures. You miss alot of smart and great engineers who don't have that skill set. But for hiring, its about reducing false positives. So you might as well ignore those who dont atleast have that algo/ds toolkit.
I think that you're misrepresenting the process of solving these problems. Recognising that you need to use a certain data structure or that a problem falls in a larger class of similar problems is a skill that you can develop. Just because you get better at it with practice, doesn't mean that it's the same as memorization or that there is some special trick to solving each problem.
Not necessarily saying you're wrong, at least not when it comes to general trends, but nonetheless this definitely needs a citation. Is there really that much of a correlation between 1) general intelligence and 2) happening to find the "trick" corresponding to a typical tech interview problem?
Speak for yourself. I love Leetcode. It's a standardized process that I can study for and basically be guaranteed to get a job in a sunset of companies that pay extremely highly.
