Tl;dr: stick them in Ops or frontline support for a while. I can’t imagine an Ops team that would turn down an extra head, especially if it’s coming out of your teams’ budget.
I have a BS from a great school, and don’t think it’s helped me very much in my career. I’ll offer what has, though I’m going to fudge some of the details:
I began in Ops/Support, not Dev. This put me in a position to immediately contribute, while learning all the intangibles: how the company works, who does what, what breaks where, etc. (A couple months covering weekends alone and you learn to spot stuff during the week before it breaks). I also became familiar with the products we produce, and how the customers use them.
Later, having developed a good grasp of the business, I began dabbling in scripting to help make Ops tasks easier.
At this point I’d learned the company, the people, the product, the perspectives of both customers and Ops, and am developing coding skills that have a real impact on the company. Not bad for a few months’/year’s work of onboarding.
Finally, having shown an aptitude for problem-solving, comfort with coding, and an ability to deliver, I transitioned into a more pure Development role. Small stuff, then bigger stuff, but even if I couldn’t code whole apps immediately, I was still a valuable junior Dev team because I was a Subject Matter Expert on some things they weren’t as familiar with — namely, their customers (both Ops and end-users).
What specific things can I do to get the most value from this employee, recognizing they aren't capable of solving the coding tasks originally intended?
Looking back, had I been hiring me as a developer I would have compressed the timeline, but I think a stint with Support or Ops is invaluable training. As our team has grown we’ve hired several excellent coders, but even after a few years together I’m in the best position to design the projects because I’m most familiar with how we fit in the company as a whole.