This is a funny topic to me. A decade ago, before Leetcode, Hackerrank, and Cracking The Coding Interview, it was common for developers to complain that software developers were losing touch with algorithmic knowledge. HN-type websites were full of discussions about clueless software engineers doing damage to companies by implementing O(n^2) algorithms that worked fine on small datasets but failed in production. It was popular to complain that modern libraries, frameworks, and programming languages were making developers too soft to write good code.
The industry responded by re-emphasizing the value of CS fundamentals and algorithmic knowledge. The training industry responded with easy tools to teach and learn these algorithms. The internet is full of easily accessible materials to teach these principles to anyone motivated enough to Google it.
Now, the popular narrative has flipped. Internet comment sections want to hate algorithms and suggest that programmers don't need to understand the basics. Just rely on the frameworks and libraries to do the right thing. Just Google the solution and weave the libraries together to do what you want.
> Whereas a young programmer in the past may have spent their extra days writing games in Basic or static web pages, hackers these days seem to do Leetcode until the wheels come off.
Young programmers don't wake up in the morning and choose between writing static web pages or grinding leetcode. There are more opportunities than ever before to learn whatever you want.
Have you actually worked with students lately? Leetcode style systems are a lot of fun for people. It's a straight to the point system that teaches algorithms and other fundamentals in self-contained brain teasers that are straight to the point. And it's trivially easy to Google for supporting training material. In my experience, the same people who are self-motivated enough to build web pages and games are frequently also interested in Leetcode style brain teasers.
People aren't choosing between one or the other. That's a false dichotomy. All of the highly driven students I've worked with have a range of experience from toy projects to Leetcode style learning challenges.
That’s not true for everyone, especially in such high stress situations as an interview. I like crosswords, but I wouldn’t want to do them in front of someone judging me for a job in 45 min while thinking aloud.
Heck I was too young when I started learning lisp (clojure). Took a long time to get used to non-functional constructs.
Things definitely changed once I got to university though. Competition for internships meant I had to get good at interviewing. The CS program I am in encourages the career focused so grinding leetcode is popular. One of my interviewers asked me a number, and used that to retrieve the n'th leetcode question from memory.
There does exist a small cadre of people, myself included, who find leetcode and similar interview grinds unethical. I'd rather spend my time having a life or learning/building interesting tech. Interviews are then less of a performance art and instead a genuine 1-1 to work through a problem.
Ultimately, though, you're right. The problem is that software engineering interviews aren't actually about software engineering. And, that's what really needs to change.
What's your reason for thinking there are more "software engineers" than "programmers"?
The part of recent grads getting job is more related to market conditions, back in 99 recruiter would be happy to hire anyone who have attended the programming 101 while in 2001-2002 no one even wanted to talk to 5 -8 yr experience candidates right after the market crash
We are failing to bring certain softwares into existence by effectively requiring programmers to their effort into the World Wide Nether, finding the Kth smallest element in an unsorted BST for the millionth time, for seemingly no purpose except for it is "how things must unfortunately be done."