First make sure the week before the person reports on board that everything is set up at their desk (And that they have a desk assigned). It gives a very negative impression to get to a new job and they haven't thought about where you will be sitting or what equipment you will use. Make sure it has a chair - amazing how often chairs seem to dissapear from empty spaces. Have the PC loaded with the software the person will need. Nobody really wants to spend their first day loading software.
Make sure that the person is given the rights they need to databases, source control, etc. Make sure they have been given an email_address. Make sure they understand IT policies such as what can be loaded on their PC, what cannot be loaded, what Internet access they have and what they should not do with the Internet (we don't allow streaming video for instance), who is responsible for fixing PC problems, the contact for the help desk if you have one, etc. Talk about how you use source control, how you do the build, how you deploy etc. Talk about testing, unit testing, QA, etc. Make sure they know how you expect them to test. Talk about code review.
Introduce the person to everyone on their team and any people they will be expected to work with regularly. Make sure they know where all key things are - boss's cubicle, coffee,restrooms, copy machine, server room (if need be) etc. Make the person feel welcome and that you are happy to have him.
If your application is data intensive, give them a couple hour presentation on the database structure. Use diagrams that show relationships. This is a good opportunity to also talk about the business domain and why you need certain things.
Show them where the code is and do an overview of the code structure. Open the application and show them how it works. Go through several of the main tasks including, if possible, the area you want them to start working in. Again spend some of this time talking about the business domain, the experience of the people who use the application, etc.
Give them at least a little time to poke around through the code base and database on their own with no particular task assigned. This might make your previous explanations clearer and help them understand the whole faster than giving a small task to do the first day.
If possible, assign a mentor - someone who will be the source for questions. Try to make it someone who will actually answer questions. Have the mentor and the new person pair program for a period of time. For an experienced guy this might even be a very short time - just long enough to give him some familiarity with how your team works. But for entry level, you might want to do this for longer.
Assign a relatively straightforward first task to all but the most experienced. Check progress daily. Make sure they are not only doing the work in the way you need it done but committing their code to the source control system according to your policies. It seems intrusive, but the least successful new hires I've ever seen are the ones that nobody watched the first couple of weeks to make sure they knew what they were doing. Everyone's work should be coded reviewed, but even if you don't normally do so, code review all new people's work for at least three months. It is very possible that the person interviews well but doesn't work well. Make sure you take the time to know that he is working well. It's a lot easier to correct the person who forgets to save to source control the first week, than three months down the line. And for someone who doesn't learn or won't do things they way you need them done, the sooner you get them out of your team the better for everyone else.
One big mistake I've seen is assigning new people to the complex new task that will require a good understanding of the system, while leaving the old people (who understand the system as it is currently built) doing maintenance. I have never in practice seen this work out well.
First, the old employees resent the new person because they got the interesting task. They will often be passively unhelpful. Second, the new guy is out of his depth because he doesn't understand the systems yet. Third, because he is working on his own (or only with other new people), the work is often not checked until it is too late.
Now you can assign to those tasks if you also have some experienced people working on them as well, but all new people, all new task, that requires you understand the current system (such as a redesign), bad bad choice. Even if you hired him specifically to do the new task, give him a couple of weeks of maintenance of the old system first, just to give him the understanding he needs.
After the person has been working on his own for a couple of weeks, sit down with him and ask him what he thinks the organization could do better. Listen carefully - you don't have to implement everything he says, but new people often see problems that the old people are so used to working around that they no longer notice them. The perspective of the new person to an organization is critically valuable - don't forget to get it. If you are the type who will catgorically dismiss everything he says, then this step is of course counterproductive. But new people are often eager to make changes and to show how valuable they can be. This is useful energy and can help the organization move to be better.
