Intern Training - Best Approach?

We have an intern starting next week. He has a Computer Science degree but no real development exp开发者_如何学Cerience in .NET or SQL Server. We'd like to get him to the point where he is at least semi-productive in C# and SQL Server. What suggestions might any of you have, who have gone through this, regarding how best to starting training him in C# and SQL Server? I want to make this a good experience for him and for us.

Some of the best experience I've had with this (from both perspectives) is a 2-fold approach.

First - Product Training. Show the new developer what the product that he'll be working on is and what it does from an end user perspective. It helps to build context to the code that is under the hood. This is one thing that is usually overlooked a lot; however, helps immensely since it also helps the new dev be more confident on testing the code he or she is working on instead of just stumbling through the code.

Second - Pair programming / Shadowing / Mentoring. Having the developer work with a more veteran person in a pair programming situation with a slight mentoring aspect. This will help gauge the developer's true skillset and provide corrective action to the team's habits early. It also provides a way for them to learn and not worry about interrupting veterans with questions and what not that way.

Once that's done, start feeding the new person smaller tasks or easier bugs and build up from there.

Speaking as someone who's interned for two different companies, one of the best ways to get him up to speed is to give him a small pet project with a mentor to oversee his progress. This will allow him to start becoming familiar with the technologies that he's going to be working with, while the mentor can guide him in a manner that will teach him your company's practices and procedures.

After he's gotten sufficiently familiar with C# and SQL Server, you can start having him do real development work. Start him off small with mild bug fixes, and then ramp up the difficulty until you can call him a full-fledged developer. With any luck, you won't even be calling him an intern within a month or two.

• Small projects to help him bed in.
• Get him to review other developers code in projects
• Point him to internal wiki (if used)
• On-line training or 2-5 day Microsoft training course (budget pending)
• Outside of the IT department, makes sure he builds up his knowledge of how the business works/functions
• Make sure he has access to some good books, as well as internet resources
• Make him feel comfortable in the working environment so that if he gets stuck he will ask someone for help. (IT Devs can be very subborn asking for help sometimes)

If you have any 'pet' type projects (projects that your company couldn't ever really justify spending time on, but would be helpful and fairly simple), I would give that to them.

It'd be a good way to start learning the material, since it's actual work (it's always tougher to learn something, and remember the material, if it's just an example program and not something actually useful). It'll be a good start to learning how to use google for questions/tutorials, and build a relationship with your team by asking questions. From there, they should have a decent enough background to start working on actual applications.

If the pet project is small enough, you might want to have them re-visit the application towards the end of the internship to re-write/improve the application. They'll probably be surprised on what they've picked up over the course of the internship

Start by identifying some areas of easy to medium complexity and clearly identify what the goal for each task is. Give them a sense of the business/domain so they understand how things fit together. Once a task is completed, have him review it with a fulltime developer to ensure it meets the requirements and to identify any weak areas where better practices can be used (this provides a mentoring / education opportunity).

What you don't want is to send them off coding a bunch of things then discover that the code isn't upto par. As for the database, be careful. Limit the permissions (ie. woops, I didn't mean to DELETE/DROP that!) or hopefully you have a dedicated developer environment where things going badly aren't devastating to recover from. Perhaps a side project with a sample database to test with before incorporating the work back into the actual environment.

Some good suggestions already, but I'm going to add, have him sit in on code reviews for other developers. He can learn alot from listening to people go through their code for each other.

Do not give him rights to do anything except select from your production database. Have him do all sql coding and changes in scripts and have him add them to your source control. Make sure to code review everything he does.

Probably the most important thing though is to give him one or more real tasks to accomplish (While making sure to spend a lot of time monitoring what he is doing, to keep him from going too far down the wrong path). You just don't learn as much when you know you've been given a task that is busywork that no one intends to actually ever implement.

IF you have been wanting to move to an evironment where you have more automated tests but haven't been able to find the time to write the tests for existing code, you could set him up to do some of those. It's something useful to do that is relatively low risk and when the real code dies on one of his tests and he finds a bug no one else knew about, there will bea real sense of accompllishmnet. This will also require him to start getting to undersatnd business requirements and how to read the existing code and testing and a lot of other concepts.

For an intern, learning to use source control and do tests and work with others are the critical skills to learn.

With junior developers, I like to get them into the mix as soon as possible. I turned my junior developer into our team's master of configuration and server set up. He's the go-to guy for getting our apps up and running.

One of the best things we did with him was get him to document exactly how to get the dev environment up and running. He had to learn all about it to document it and now we use his document when new people come on to the team.

Maybe we're just lucky, but I've had great success just getting him into the code. We don't really coddle him at all. Practice makes perfect. That and frequent code reviews, etc. :)

We have an intern in our team about 6 month. I Hire him and it is a really good experience. When I interviewed him Hi answer on completely all CS questions, but when he start working with us it was horrible all worst practices - committing broken code, locking svn files, copypasting every where and everything, namespaces with names like Classes, long very long methods with HUGE arrow head antipattern inside. and finally best c# code I ever seen:

bool b = DoSomeThing();
switch(b)
{
case true:
  Do();
  break;
case false:
  DonotDo(); 
  break;
default: //!!!
} 

My only suggestion is control him.

Have him create a UML static structure diagram for the codebase of one of your existing moderately sized projects. This will (1) force him to have a high-level structural understanding of at least one project and (2) make him read someone else's code, something an intern may have never done before.