Does this solve the other problem, that job hopping is the best way to get a raise?
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.
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?
And when is the last time you had to balance a binary tree or write Djikstra’s algorithm from memory anyways?
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.)
Totally wouldn't work for Google Maps doing shortest path routing globally, but for an event with only a couple of hundred POIs and intersections, it's a cheat that seems almost magical to people who have some concept of the algorithmic problem, but haven't worked out the "trick".
If I were asked to whiteboard this, I would 100% be asking that constraints of the dataset up front. (I'm not too sure I'd have been smart enough to do that a couple of decades back, when I last had a "perform for us code-monkey!" type of job interview...)
No...
> 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.
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.
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.
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).
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).
[0] https://en.wikipedia.org/wiki/Longest_increasing_subsequence
I think people are just lazy and don't want to learn new stuff so they whine instead.
Now imagine your dance skills accounted for 99% of your score during the courtship (hazing) ritual.
Leetcode is even less relevant. I can google algorithms. Dancing's an actual skill.
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 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 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! ;-)
Side note: you should put some contact info in your profile so people know who you are hiring for anf how to contact you. :)
Exactly! Thank you for formulating what I always knew subconsciously.
That's not to say they're a bad option, but it still seems like you've gotta jump to a different company to maximize earnings.
Some companies will flat-out refuse to negotiate in this way as a matter of policy, and some will really appreciate you giving them the opportunity to bid to keep you; it really depends on the company and their comp strategy. I think as long as you're earnest about the conversation and don't try to run a bidding war, most companies won't burn bridges with you over a round of negotiations in this fashion.
The biggest issue we encountered was arbitrary requirements in the paper documentation of the role we were aiming to move me into, including a ‘hard’ requirement for an engineering degree with honours, which suddenly became less of an issue when the argument was ‘im going to accept another role but you can match it with x salary and title’ in a polite discussion with department head.
This will only apply to very large companies though, ymmv.