A year?!
You're either scraping the bottom of the barrel for new hires, have a terrible on-boarding process, over-estimating the difference between the code someone fresh out of college writes or have absolutely terrible documentation or some combination thereof.
I'm leaning toward on-boarding and/or documentation. Junior devs are the ones who most need documentation because they're not gonna be able to infer the existence of policy and best practices from existing code and procedures as well as a senior dev will.
Either you and your HR is doing a terrible job giving new hires a lead on what to be asking and where to find information or that information just doesn't exist outside of the heads of existing employees.
I work at a CDN. We have plenty of issues with legacy code, cumbersome interactions between business units, outdated policies/docs, lack of documentation on stuff and all the other BigCo problems.
A huge chunk of new hires at any time are fresh out of school. It takes ~3-4mo before they're dealing with stuff on their own with perfectly fine results.
People aren't idiots but they don't know what they don't know. People with more experience are better at knowing when there's something that they don't know. Fix your process and you'll be able to get good value for junior devs.
If you don't fix your process don't whine when someone who has business practices that let them deliver the same results at lower cost by utilizing cheaper labor comes along and undercuts you.
Isn't that the definition of entry-level or junior?
FWIW, the four recent graduates I hired this summer are all capable of completing well-defined programming tasks with minimal assistance. Does that mean I spend more time with my PO ensuring those tasks are well-defined and consumable by the new developers? Yeah (but that's our job). Do the senior team members spend part of their day mentoring? Yeah (but that's their job).
As for some of them not hacking it. Yeah that's true. But, I've also interviewed plenty of "senior devs" who were terrible. I've even hired one or two who didn't work out. I just do my best to avoid hiring them.
I'm not an accountant but I did do a business minor and I don't see this being much different for new accountant hires vs. new developer hires.
Then I got on a new project as a dev. Within months I was down to 3-4 hours for similar assignments. My last class at school was the first time we had a shortage of hardware (good school). I would sit at home and remote into one of the machines, get my code to compile and show up to the lab the afternoon before it was due to debug. And everybody looked at me like I looked at my old coworkers.
It’s been a while since I’ve talked to undergrads but I always tell them to beg borrow or steal an internship or a job on campus. You have no idea how far a little concrete experience takes you.
Finish with the boring programming, and you get to do fun programming.
Can you define "real work"?
Something built for a need--whether profitable business, or personal need--tends to provide more meaningful experience than a "write this contrived program to learn how [specific programming functionality] works" project.
No, they're really not, for at least a year. It takes at least that long for most new graduates to get over the hump and learn enough of the practical skills and industry practices that their university left them woefully ignorant of, so that they can start being marginally useful. Once in a while you find somebody who has been doing real work on the side for years during or before college, and thus has a clue how things work, but that's a diamond in the rough, usually.
And unfortunately, many of them just can't hack being a professional programmer, and they never get to the point where they become a net positive, in which case you just hope they leave of their own volition or you can silo them off in some area of little importance that won't cause you problems down the road.