Despite their intelligence they've always required constant senior level supervision, and have generally been the ones most likely to create maintenance-heavy components due to inexperience.
I'm not sure why our experiences differ so substantially, but I'm happy to hire only senior engineers and let other companies pay to train the young ones. The senior engineers are more than worth the minimal financial premium.
Sounds like you have bad projects management and let people go cowboy and build bad things because you don't communicate with each other.
As for documentation, I'm not sure quite what to say. The best person to document code is the person that's writing it. The best person to document things that aren't code is a technical writer, not an engineer.
Getting good work out of junior engineers requires a management investment greater than the cost of simply hiring experienced engineers to begin with, and they still will not produce code to the same level of robustness and quality.
I can see from your company that you don't operate this way. I assume this choice expands the apparent pool of available applicants, but it also ensures that your company is likely completely uninteresting to senior, experienced, genuinely expert engineers.
In my experience, there are two kinds of engineering managers. The first is the kind that has figured out (or thinks they've figured out) how to get decent enough code out of inexperienced or just plain bad engineers. The second is the kind that realizes that they don't have to work nearly so hard or jump through so many procedural hoops if they just hire people that know what they're doing to begin with.
What's more, those experienced people tend to have extensive contacts and make it easy to hire their friends.
That said, I'm happy to let you spend the time, money, and energy training and managing junior engineers, while dealing with their subpar work output.
You certainly have an active imagination, so I'm sure the next things you make up would be just as interesting.
Flatline3, you're wrong in pretty much every particular about how I work and how my company works.
It's certainly possible to mentor younger developers well and at low organizational cost. It depends a lot on your process. In particular, I think pair programming, frequent commits, good unit tests, and collective code ownership together make it entirely safe to hire somebody younger, and you get substantial benefits.
I also think it's shortsighted to say, "Hey, let the shitty shops train junior developers." Great senior developers have to come from somewhere, and I think they'll never get great working at places that don't have their acts at least somewhat together. I benefited a lot from people taking a chance on me when I was younger, and I think I have a professional obligation to return the favor.
Your loss, really. I've interviewed and worked with several young engineers who were really top-notch, who worked out great, and were mature in their approach to work and life in general. They also tend to come with a lower price tag. Some have not worked out so well, but I don't have any reason to believe that the failure rate changes dramatically with age.
As I myself get older, I'm not so sure that the maturity level changes all that much either. People are just better at hiding their flaws as they grow older, then you find out too late when there's an issue.