My problem is that I'm really struggling getting job interviews, and then landing a job when I do get an interview. Last year I interviewed for a Django development job, something I'm perfectly qualified and capable of doing, but I didn't get the job because the questions were all about the internal data structures of SQL, esoteric questions about Python internals, etc.
I'm at a loss for what my plan should be. Get a CS degree? Grind leetcode? I need to define a good path forward. I know I can't control the future but I'd like to still be employable 10 years from now.
That said. You have 4 choices IMHO -
1) go into management. Although most techies enjoy hands on and would hate this option. Personally I like team lead, as it was techie enough and I became the buffer between the non tech management and the people doing work
2) settle into a secure job. i.e. big company / government. They typically do not lay off as you get older. Although government and universities respect a degree.
3) keep chasing the new tech. This requires a lot of time self learning. You will find some tech will run dry on you. I find this path the hardest, but the most satisfying. But it is not the tact I took as I have a family to feed.
4) become an expert in A tech. Expert to the level that you have a blog on it, you present at conferences etc. This sounds like it would be real cool, but the risk is the tech dies. Yeah Java is still strong, but Pascal is not.
As much as you don't like leetcode, doing those exercises is effective and meaningful. I understand where you're coming from - I also lack the classical CS background that a company would find in a CS graduate. Leetcode questions might seem like they're very theoretical and unpleasant but a lot of those questions focus on the standard algorithms and data structures (stack, queue, hash map, linked lists, trees) - some of which has opened my eyes to solving some problems efficiently that I face at my job. Heck, some of those I've already been using but never knew/used the right term for it! For a long time I hated the idea of Leetcode too and I avoided doing it because I would have to conform to a broken interview process where I felt like I had the experience to make up for that missing CS knowledge. This was arrogant of me and wasn't working so I tried to adapt.
Like another commenter said, you can't control the BS interview, BUT here are some things that I did which helped me, and I hope you find some of them useful:
1) Learning the standard data structures and algorithms, and doing 2-3 leetcode type problems a day at varying difficulties helped me gain confidence in answering those types of questions and at least being able to get through the more basic technical interviews. Pair program with a friend to try and solve the harder ones together so you can get used to the live remote coding interview style and keep each other motivated.
2) Studying up on system design helped me to prepare for the harder technical interviews where they ask you "how would you build Instagram" on a whiteboard.
3) I went the engineering management track. This also varies wildly between companies but ideally this type of role gives you 50/50 hands on/management type work. I had to study up on the behavioral questions, prep responses to those "was there/tell me a time where..." type questions and put my management style into words.
4) I always ask the initial phone screen person about the interview process in detail just to know for myself what to expect and how I can study appropriately. If they're not clear about it or they're vague about it, I lose confidence in that company because I will likely fail somewhere along the way. I've been to an interview where the company uses Python, which I didn't know at the time and they told me not to worry because they only want to see that I know the basics - when I got to the interview, they asked me to build Minesweeper and asked me to build Blackjack on the whiteboard. I was unprepared and so I failed that.
5) Even after landing a job, keeping up with the Leetcode exercises to keep that stuff fresh. Never forget how long it takes to ramp up again after not doing it for a while.
6) Practicing to think quickly on your feet. Basically if you don't know an answer to a question or you can't answer it for whatever reason, highlight something good to balance it out and recover from the stumble.
A big one is that you can do more than just code. You've planned and delivered projects that solve business problems. Even if you don't consider yourself a project manager, the ability to take business requirements and translate them into applications that solve business problems is valuable.
Also, consider the possibility that 'aging out' might be a lot smaller in some subsets of the development community than in others. In my experience, companies using .NET are likely to see age and experience and even a few gray hairs as a good thing. Probably because .NET tends to be used by older, more established companies. So you might consider looking more in that direction. Just be careful not to end up in a job where your sole duty is the maintenance of an ancient VB.NET Web Forms app. You can have a lot of fun with C# and .NET Core, though.
I've also noticed that .NET interviews are a lot less likely to use Leetcode-style problems. I've always prepared for those kinds of questions, and was even looking forward to them! But I've never encountered one in an interview for a .NET related role. They've always been more interested in getting to know me and talking about the problems I've solved. There have definitely been take-home coding tests, but they've always been the kind of test where they ask you to create an application using ASP.NET MVC or ASP.NET Core, and they've always given a set of specs telling you what the app needs to do. I've never had one of these take me more than a couple of hours.
There are no guarantees, of course. Someone else who replied mentioned they had a crappy .NET interview where all of the questions were about SQL. On that note, if you like .NET then learning some of the more advanced bits of SQL Server and T-SQL wouldn't hurt - and might actually be fun, and will even carry over to other databases. For example, if know how to use PIVOT in T-SQL to flatten several tables into a single report, you'll find it pretty easy to do the same thing with crosstab in Postgres.
Finally, consider looking at programming jobs in non-tech companies. I know this goes against advice I see often on HN. But I've talked to many developers who seemed super happy working for banking, insurance, and manufacturing companies. I've seen a lot of age diversity among devs working for these companies, too. Without a doubt, there are some non-tech companies that are terrible work environments for developers.
But there are also plenty of them that understand the importance of technology, and actually treat their tech people with respect. If you ask the right questions in the interview, you can usually get a good sense of how developers fit in with the rest of the organization.
The downside is that you're more likely to end up working on boring projects at non-tech companies. Lots of CRUD apps, lots of wrestling the data you need out of massive, not-so-well designed databases. These companies will probably pay less than tech companies, too. But you'll probably work less, and deadline pressure won't be as severe. There are certainly non-tech hellholes where you'd end up with long hours and low pay. That's why you ask lots of questions during the interview to try to weed these companies out. If you do that successfully, you may just fine a company where you'd want to stay for a decade or two. You might also have the opportunity to make a big impact in ways that you wouldn't at a tech company. You'll probably find lots of low hanging fruit in the form of problems where you can apply very basic AI/ML to help the company save money.
Anyway, that's just one possible path. sloaken's reply mentions 4 choices, and I agree that they're your best options. I suppose all of my advice above falls into option 2 on sloaken's list - settle into a secure job at a non-tech company that's likely to be around for a long time. You could even combine 1 and 2, and aim for dev management/team lead at a non-tech company. In those roles, you'd be able to get to know people throughout the org - and learn about all sorts of painful business problems you can help solve.