Not only that, but I'm getting the feeling a developer's best option these days for maximizing pay increases is to spend their free time on Leetcode. Which in my opinion is a problem from an industry perspective.
> Which in my opinion is a problem from an industry perspective.
Why? If a person can learn bunch of algorithms and apply them to custom problems they probably can do quite a bit with computers. And it shows that they probably can learn new stuff rapidly as well. I don't get why so many developers hate Leetcode. I love it personally, I think it's great. And also, I think people are just lazy and don't want to learn new stuff so they whine instead. I don't think whining will help them.
We're looking at a target audience of people who already can "do quite bit with computers", know all the algorithms they need for the job they are going to do, and don't really want to spend time on leetcode because they would rather be doing or learning something else, or perhaps they have done leetcode or stuff like that a lot ten or twenty years ago and they wouldn't learn anything new, just re-adapt to do useless things quickly once again.
I'm not trying to denigrate it by labeling it useless - competitive problem solving/"sport programming" is a fun activity and can be a rewarding hobby, but it's important to recognize it as such, as a hobby that's only tangentially related to most actual development work once you move above a certain base competency level ( I'll grant it that it is useful for people without much practice in actual programming to do a bit of it.)
It's a problem from the industry perspective if we as industry have many people spend a lot of time doing things that don't benefit the employer (since grinding leetcode doesn't make a non-junior person better at their development job, it's an orthogonal skill) and that doesn't benefit themselves personally (we're talking about people who don't want to do leetcode just because they enjoy it) but only through the zero-sum game of competing for jobs effectively by "peacock signaling" of who invested/wasted the most effort in leetcode. This is effectively a lose-lose competition, spending a lot of everyone's time without a net benefit.
Because LC problems has no applications in day-to-day work. You're just doing it for interview practice. It only seems "useful" because it's programming problems, but it's as ridiculous as studying chemistry or calculus as interview prep.
Because learning a bunch of algorithms doesn’t translate well into day to day programming capability. This is exactly why those dumb whiteboard problems aren’t good for interviews; you’re not measuring what makes someone successful on a day to day basis.
> This is exactly why those dumb whiteboard problems aren’t good for interviews; you’re not measuring what makes someone successful on a day to day basis.
If that was the case, you think all of the biggest tech companies that have billions of dollars would continue using it? Did you ever consider that you might be wrong?
I mean, for a while there Google thought that asking how many basketballs could fit into a school bus was a good way to find good coders. Just because Google does it doesn’t mean it’s smart.
And when is the last time you had to balance a binary tree or write Djikstra’s algorithm from memory anyways?
Curiously, in my non coding management role, I busted out Djikstra’s algorithm last year to the amazement of most of the developers, who thought the problem in front of them was insoluble. It turned out that yes, it is in the general case, but it was totally possible to brute force the results required for the constrained task at hand on a laptop in Python and store the ~60k optimal solutions in a lightning fast key/value store.
I didn’t reproduce it from memory though (but I did choose to port a Java version in preference to any of the existing Python versions I found, because it’s code was structured in a way that I grokked much easier. Possibly due to my not totally expert idiomatic Python skills, I’m really a Perl coder deep down.)
(And I never had to do any whiteboard performative coding to land this gig either.)
Interesting anecdote non-withstanding, a white board interview would have not been a good way to predict your ability to have done that. The limiting factor was not your ability to remember the algorithm from memory, which you didn’t do, but the ability to make complex decisions based on real world constraints and data. In a whiteboard situation, chances are the “correct” answer would be “it’s not possible”, since without knowing the actual data set that’s true.
Cynical response: Because thats what the people already at the big company had to put up with during hiring, and damned if they’re gonna let any prospective newbies off with an easier recruiting process, no matter how broken and pointless it is...
> at least not one that’s possible to administer cheaply.
Ah, yes. AFAIK, Behavioural interviewing works, but it does require training and thoughtfulness. You have to know what you're looking for, and ask questions specifically targeting that. You definitely cannot just throw a random employee into an interview with a list of questions and expect it to work.
The toughest parts of my software career have been managing relationships with my peers & working on my own attitude. For too long time I thought I could code my way out of any problem and/or win any argument with the technically more correct solution. I was super wrong. No amount of knowledge about how to write a weight balanced binary tree prepares one for the day to day grind of working with actual people.
And even when it's "computer stuff" you find out that there aren't that many n^2 problems to solve, and you'll recall every n^3 problem you fix because they almost never happen.
Mostly what you deal with is architectural problems. And when it comes time to fix slow code, the problem won't be O(n^2) code but a mountain of code where the constant factor C is somewhere between log(n) and sqrt(n).
To be fair, I would probably give the candidate with the most party tricks extra points. It demonstrates an interest in the subject matter as well as an ability to demonstrate it in an exciting way. Also, how fun would that interview process be? Just sayin...
I did ACM programming competitions at both high school and collegiate level. So I'd like to think I have a pretty favorable opinion the types of things leetcode tests -- algorithms, data structures, big-O and big-theta, etc. They are incredibly important.
But these topics are very, very far from being everything important. I would put them under soft skills, especially in cross-collaboration and working with non-engineering groups. And I would put them under having the type of knowledge and experience in approach that, especially combined with the above soft skills, allow us to push the direction of the company forward.
As a dumb example off the top of my head: It's great if you know how to average a batch of numbers efficiently. It's better if you know how to do such in a streaming fashion, and recognize that we can use that within our architecture to materialize savings. And, it's best if you can convince the business that there's no need to calculate the average because we can do streaming estimates for any quartile.
Does leetcode really do much in terms of algorithms though? In my experience, a lot of problems can be solved with sheer brute force, or by merely using the language built-in data structures and memoization tricks.
I think algorithms per se don't necessarily give you much of an advantage. For example, LIS[0] is fairly frequently-run algorithm if you work with web stuff, but nearly no one in that specialization knows how to write it from memory (and knowing about it doesn't translate to being able to write other algorithms)
Where I think leetcode helps is in giving you an opportunity to practice the skill of putting together various building blocks in a semi-realistic fashion (e.g. having to use a memoization trick to get under the run time threshold is something that is similar to real life performance work, despite the exercise itself being completely unrealistic).
I think people who think software development is about 'do[ing] quite a bit with computers' have blinded themselves to the fact that you mostly need to do quite a bit with people. They didn't know that was going to be the case when they signed up for college classes and now they rationalize as hard as they can that they can actually treat the profession that way.
I think people are just lazy and don't want to learn new stuff so they whine instead.
Leetcode, Project Euler, etc. may not feel like a programmer's daily tasks, but they may yet be a good proxy for many behaviors that large employers desire.
For example, a large employer may want a willingness to do arbitrary, difficult tasks that appear meaningless. These same employers may have a variety of software maintenance tasks that require recognizing a pattern of problem, knowing the appropriate algorithm from Ye Olde Textbook, and quickly applying it.
> These same employers may have a variety of software maintenance tasks that require recognizing a pattern of problem, knowing the appropriate algorithm from Ye Olde Textbook, and quickly applying it.
These edge cases might exist, although I argue the more likely problem is that hiring is hard, expectations can be unrealistic, and so it’s easier to fall back on puzzles and call them an objective measure of technical competency and soft skills. Project Euler is fun, but Stack Overflow is likely more relevant for your day to day for solving business problems with software.
I also measure my candidates' ability to fix bugs by learning the details of a language feature they're not familiar with, by finding examples and documentation.
I find that many junior-level candidates scrape by with Stack Overflow, but sadly have little competence when it comes to reading documentation. Candidates for more senior roles have a similar problem regarding systems design. They can find and parrot little statements they've seen on forums, but when you ask them to explain, their understanding turns out to be shallow.
I don't use programming exercises as a sufficient measure, but they are a necessary one.
Now I feel obligated to add that footer: We're hiring! ;-)
Why? If a person can learn bunch of algorithms and apply them to custom problems they probably can do quite a bit with computers. And it shows that they probably can learn new stuff rapidly as well. I don't get why so many developers hate Leetcode. I love it personally, I think it's great. And also, I think people are just lazy and don't want to learn new stuff so they whine instead. I don't think whining will help them.