If I were to do a week long training class (and I wish I could), I would approach it something like this:
Day 1 – this is the day when we show them where everything is located, train them on how we do things, this is how we do source code, this is how we do a the build, this is how we do code review, this is how we deploy, etc. This day will also include any personal policies they need to know (how to fill out a timesheet, how to request leave, etc.) It may also involve time to fill out any HR related forms, introduce them to key people etc.
Day 2– introduction to the application. Start with discussing what the application does and the business rules. Discuss the design and make sure to explain why things were done that way if known. Developers can do a better job of maintaining and adding new functionality if they understand the whys as well as the hows. Do some exercises in a training version of the application to get them familiar with techniques commonly used in the system. Do a code review after each exercise and make sure you hit them for not doing TDD if you do that. Make sure you look at how they added their code to the source control system and documented their time properly if you change time by project. Give them some purposely bad requirements to encourage them to question the requirements or push them back if they don’t make sense.
Day 3 – introduction to the database - show them where the database is and go through the structure including foreign keys and other constraints. Show them how you want database code written, is it dynamically generated (discuss SQL injection and avoiding it if so), do you require the use of stored procs or ORMS? Show how you commit changes to the data structure to your source control. Go over database naming standards and formatting standards if you have them. Go through a basic tutorial on joins, where clauses, aggregate functions. Have them create some simple to complex SQL code (using the tool of choice – ORM, stored proc, dynamic SQL) and then code review it. Again check to make sure that they properly committed the code to your source control and that they used the appropriate tool and most especially that they got the correct expected results. Then give them a requirements change and have them change the existing SQL code to meet the new requirement.
Day 4 back to the application for a more advanced look at things now that they are familiar with the basics of the database. Do exercises all day to debug bad code, to make changes based on requirements. Make sure to show them how to refactor. Make the exercises progressively harder. If you have multiple applications hitting the same db, do some exercises where changes to one will break the code for the other.
Day 5 morning– cover more advanced database concepts in the morning – talk about performance tuning and debugging. Have them run the profiler that you use and examine the execution plain (or Explain in Mysql I think).
Day 5 afternoon – cover teamwork concepts – who are the go to people for different things, what is the expectation when refactoring someone else’s code, how and when to discuss your ideas for changes to the system (and when not to), how to write a spec if need be, how to ask users questions about the spec, etc.
As you go along through the week, if some people are clearly much more advanced, have some very advanced stuff to give them as exercises instead of the easy stuff so they won’t be bored. If you identify some people who seem out of their depth, note that as well and schedule them for more personalized study the next week. If at all possible have every one pair program the first week at least, the least strong may need more intervention to get up to speed. If you have some who clearly are not getting it, give them a list of exactly what you expect them to be able to do before they can work on code and then have them prove to you they can do those things (and I mean do them in front of you not give you a completed exercise that possibly someone else did) before you let them loose on your code base. If they aren’t up-to-speed fairly quickly (and I’m talking basic skills here not advanced ones), then get rid of them quickly as well.
By moving the course back and forth between basic skills and how we do business here and why we have made the choices we have, I think even the more advanced programmers will appreciate the intro. Especially if they get to strut their stuff on some hard exercises when the standard ones are too easy. Also consider getting some to help the less proficient learn. Just monitor to make sure they are helping the other person, not doing the exercise for them.