Here's my minority opinion: Leetcode-style problems can be valuable for finding talent. I know this will get me a lot of hate in programming circles.
Trust me that I know it feels horrible when you're bad at them. It does not mean you're a bad engineer by any means. It just means you're bad at Leetcode problems! Clearly, you still have strengths that have allowed you to accomplish what you have in your career. Those are strengths that should not be discounted by potential employers and certainly not by you.
But that doesn't discount the value of those problems either. You're right that you have to memorize the basic data structures and there is a certain pattern to these problems once you're good at them. But if there wasn't any art to these problems, then after 400+ problems wouldn't you have figured out the robotic algorithm to solve them? I argue that there is more to those problems than bullshit.
People who are good at these problems exist. I would not dismiss the strengths of these engineers either. These engineers may not even possess the same strengths you do! But just like you, there is a certain skill or talent that allows them to solve those problems. Those skills are valued by companies who want to run smart engineering teams.
It is not the only skill out there, it's just the easiest skill to empirically measure. You cannot run a large organization without a data-driven method. If you trust the human intuition of your hiring team, you will have a lot (more) variance in your hiring quality. Not to mention that your hiring will be biased against women and anyone of a different race than of your hiring team. This is true even if everybody is aware of their own internal biases. This is why large orgs give these problems.
Even if you do not share those skills, you might still be valuable as a good engineer. You just have to look for teams that are looking for asymmetric advantages: that is, those who can't afford to compete directly against the richer teams.
There are tons of repos on github that consist of nothing but solutions to leetcode problems. This is basically running the copilot model on it's training data -- of course it's going to do well.
Copilot cannot "solve" these problems, it just knows the answer.
And for that exact reason, using LC as a hiring tool runs into the same problem as using standardized tests in colleges: Once people figure out that the tested metric isn't actually "understanding of the subject matter" but "test knowledge", and learning for the test is easier than understanding the subject, people start learning for the test.
Showing one way to get to the solution doesn't mean that it's the only way to get to the solution. It's still possible to solve these problems without the training examples that Copilot has memorized.
Trust me that I know it feels horrible when you're bad at them. It does not mean you're a bad engineer by any means. It just means you're bad at Leetcode problems! Clearly, you still have strengths that have allowed you to accomplish what you have in your career. Those are strengths that should not be discounted by potential employers and certainly not by you.
But that doesn't discount the value of those problems either. You're right that you have to memorize the basic data structures and there is a certain pattern to these problems once you're good at them. But if there wasn't any art to these problems, then after 400+ problems wouldn't you have figured out the robotic algorithm to solve them? I argue that there is more to those problems than bullshit.
People who are good at these problems exist. I would not dismiss the strengths of these engineers either. These engineers may not even possess the same strengths you do! But just like you, there is a certain skill or talent that allows them to solve those problems. Those skills are valued by companies who want to run smart engineering teams.
It is not the only skill out there, it's just the easiest skill to empirically measure. You cannot run a large organization without a data-driven method. If you trust the human intuition of your hiring team, you will have a lot (more) variance in your hiring quality. Not to mention that your hiring will be biased against women and anyone of a different race than of your hiring team. This is true even if everybody is aware of their own internal biases. This is why large orgs give these problems.
Even if you do not share those skills, you might still be valuable as a good engineer. You just have to look for teams that are looking for asymmetric advantages: that is, those who can't afford to compete directly against the richer teams.