> if an engineer can't do a simple 20-30 line coding problem or reason over the constraints/design space - then there is a good chance that they will need help with core coding in the day to day.
This isn't my experience, I've found that the number one reason for not doing well on leetcode problems is simply because the candidate hasn't practiced doing leetcode problems. I've known plenty good engineers who, when interviewing with LC style interviews for the first time, fail utterly. Then they realize they just need to practice and did better.
I've been in the industry for around 15 years now, my anecdotal observation is that the average quality of engineers is negatively correlated with the rise of leetcode. 10 years ago the strongest signal was a solid github profile with lots of relevant projects.
That's not to say leetcode is the cause of this decline. The cause is the flood of SWE being rushed into the career as fast as possible (this is why github is no longer a good signal, bootcamps started training their students to create meaningless GH projects just to attempt to create signal).
However I've also seen no indication that leetcode type challenges have any relationship to being a good engineer. I've worked at plenty of places that required pretty tricky leetcode style problems filled with very, very mediocre engineers. Leetcode has become a game that has little to nothing to do with real world programming, in the same way that speed-cubing (solving Rubik's cubes in record time) has absolutely nothing to do with the player's underlying understanding of group theory and combinatorics.
The old fashioned walk through and reason about non-trivial code someone has written is still an excellent method to see how a programmer thinks and if they can code.