Well let's suppose I had a group of new hires just out of school for a couple of weeks of intro training (which I really really wish we would do, people would get up to speed so much faster).
First source control, how we use it why we use it and where the files are located for various projects and how to get it running. Emphasis on comments on check in. Emphasis on how often to check in and when to check into the trunk and when not to. Emphasis on not leaving source control out until you are finished. With new emplyees, it is better to review their code before they get too far down the wrong path, so they should be checking in frequently. I notice with some of our new employees we often have to get tough to get them to check in their first stuff at all.
Next coding standards. What are standards are and why you have to follow them and not just do the things you want to on your own.
Then an intro to the tools we use including bug tracking, timesheets, project management software as well as programming tools. This would include how to use the debugger.
Then a day going through the highlights of the code base. Let them get an understanding of how the current thing works.
Then a long day on getting familiar with the complicated database structure. People just out of school have often never encountered a truly complex system.
Then a day on testing - TDD, Unit tests, QA testing etc.
Then a day on requirements, those just out of college may have never dealt with complex requirements either. Important is a discussion of how to push back if the requirement has holes or conflicts with some other requirement. It is important for them to know they are expected to push back when necessary to get the information they need. Many young people always accept the requirements at face value.
Some time on deploying. Deploying to prod is not a familar task either. Doing it poorly will cause problems. Even if they don't deploy, they need to understand what the people who do deploy need.
Finally, and most critical, have them work as a group to create a change to the current system. Make sure they do things right in terms of standards, source control testing etc. If they get pinged from the first on things, they will understand you really mean it when you tell them to use Source Control. I would create a change requirement that had holes and make them need to do complex queries and have something that has lots of edge cases to test, etc. Doesn't have to be something you deploy, just something that you can do against a database and application code that is reserved just for learning. That way they aren't interfering with the real work and you can put the whole project back to baseline for the next group.