There are three types of inexperienced software engineers. There are the ones who want to learn and grow, and that is split into the ones who are also willing and able to put the time into it (let's call them A s), and the ones who aren't (let's call them A' s). Then there are the ones who do not want to learn and grow (let's call them Bs).
An A or A' can be coached and mentored. Even some Bs can be motivated into becoming As or A's. The Bs that can't should be cut loose.
Realize that these individuals are like a tiny seed. They require lots of water and attention to grow. When they do grow though, they can grow into a tall oak that provides shelter for others to grow (ok, forestry majors please don't rain on my metaphor, I know about crowding). In my experience having mentored more than a handful of people (maybe more than two), the experience is very worth it. There will be some bad apples that sour the experience for a bit, but most people are either As or A's that want to be As).
A common mistake is to tell them what to do and how to do it. This is sometimes needed, but stunts their growth. As you do things, show them how you did it, explain your decisions. Then give them tasks (smaller at first). The growth from entry level code, to developer and sr dev, to software engineer and sr sw eng, to system engineer and beyond is in many ways and expansion of the complexity that the individual can handle thinking and reasoning about. So start with a function or set of functions, graduate to a class, a module, a package/namespace, a service, and then an app. Or whatever similar ladder makes sense for your domain, language, and product.
Do design and code reviews. Be gentle - these reviews may be looked on as the storm a tiny sapling has to weather. Don't say this is wrong on designs. Instead ask them why they decided to do it this way. Ask them 'what would happen if X', etc., and lead them to come to their own conclusions. Do enforce a coding style and good habits (such as PRs, code reviews, unit testing).
Realize that experience or inexperience is relative. To the 52 year old that's been coding since he was 11, in the domains he's coded in many people are inexperienced.
Also realize that experience is not just relative but scoped. The same 52 year old walking into a FPGA shop is a rank noob, and should know it (if they think they aren't then that's another problem, and often worse than inexperience).