Another one that started from Quora:
I agree about LeetCode and such things. They are often things that hinge on knowing some obscure trick, plus they tend to care nothing about the quality of the solution — it either solves the problem or not. This is also often the case when given a work assignment, but the business will suffer long-term problems if the software is of poor quality, they just probably won’t connect the dots. (Don’t get me started.)
You can get similar practice with much simpler problems, such as Exercism (where the exercises are aimed at teaching you specific aspects of each language) and Codewars. Both of these also have various levels of mentor feedback you can ask for. You can also find many lists of “katas” (a term taken from martial arts, for simple standard exercises).
As for original projects, scratch your own itch: think of what software you wish exists in the world. For instance, I was using someone else’s SaaS to do something, then that SaaS crashed, didn’t come back for over a month, and still (almost a year later) isn’t operating at proper capacity. It also is lacking several features I would very much like to have. So now I’m writing my own version, and finding out a lot about the subject matter and the tech stack I’ve chosen to use.
You can also join someone else’s project, primarily open source ones. Trawl the Issues tab of Github projects using languages you know (or would like to). Or if there’s some open source project you’d love to work on, like whatever’s the open source “killer app” of your favorite language, find out where the maintainers hang out (like if there’s a mailing list they use for that purpose, that’s open for the public to join), and volunteer your services for whatever they may need.
Other than actually writing software, you can also solidify your understanding the way Richard Feynmann suggests: teach. It doesn’t have to be a formal classroom thing or even a presentation (whether to a work group or an international conference or whatever). You can do it via blogging, making videos, live-streaming your coding sessions and explaining stuff to the audience, and many other ways. Take some concept you think is rather hairy, and try to explain it. Not only will it solidify your understanding, especially once you start trying to anticipate questions and have an answer ready, it will also showcase it to your audience, and to anyone else who even hears that you’re doing this at all. You can also combine this with the simple-exercise practice, by publishing your solutions (such as blogging them or doing videos about them), especially if you also delve into the tradeoffs of that solution versus others.
Lastly, engage in the community, real-time, ideally face to face, like user groups, conferences (if you can afford them — check into having your employer send you, or giving a talk), and so on. Teaching is part of this, but even just joining groups, engaging in conversations, asking questions when you don’t understand something (never be afraid of that!), and so on, will help enormously. Seeing things mentioned on some language’s mailing list or whatever, will bring things to your attention that you might not otherwise even know existed. Then you can decide whether to investigate that further or not — you don’t have to know everything, but you should know about as much as practical.