Interns typically get given the mundane jobs - bit of filing, some simple bugfixes, a 'no use' project or CD\DVD duplication for example.
If you were (or are) an Intern, what would you want from your internship? If you're responsible for an Intern, what measures have you taken to make the internship a really valuable one - both for the company and the Intern?
I would say something they don't teach you in school. So source control management, build management, deployment management and in the end wrapping it all up nicely in to a continuous integration system.
As an intern my self, if you gave me mundane tasks like that, I would quit. I can understand not letting an intern handle mission-critical software (at least without extra checks before anything goes live), but I expect meaningful work and mentoring from an experienced coworker when I get stuck.
Perhaps you need some in-house tools, so finding and integrating off-the-shelf products and creating new utilities would be a good task. Things like NotMyself suggested would also be good.
However, it all depends on their level of experience and level of education. Give them something that will help them back at school (skills they can't or don't learn in the classroom) but still in their field of study.
Just as an aside, if an internship is required by a university, it often HAS to be mostly or all work in the field of study. My university, the Rochester Institute of Technology, requires that CS and SE majors do 1 year of internships in the field of study and we are expected to perform the same tasks that would be given to a graduate of the program. They offer two documents (both PDF) that help employers with their interns - Co-Op Tips and Excellence Expected.
I really liked Joel's idea from Project Aardvark to give them a complete project that they can complete. It gives the interns something they can actually put on their resume and be proud of.
I'm sure you can find some small project that you can give them that actually produces something that is shippable. Even if it's some in house tool, that may be able to open sourced that does something useful.
I believe testing is a good task for an intern as well. I believe that all too often it is overlooked.
Good interns deserve good projects. As someone who has both been (many times) an intern and hosted one (so far), I've seen that independence and respect for the intern can make a huge difference in productivity and original results.
More concretely: I suggest to keep a list of projects you'd like to do if you suddenly had a little extra time - the stuff you might daydream about, that is a cool combination of fun, productive, and interesting. Exactly the kind of thing you wish your boss would let you do :) When these are meaningful contributions to your work, they can be the best intern projects.
It's also a good idea to discuss with your intern about possible projects. They have weaknesses and strengths, and if well-chosen, a lot of their own creative vision. Maybe your daydreamed project list is just a catalyst for what they'll really do. If you give them some freedom, it's more likely their project will align with their strengths, and that they'll be very well motivated to follow through.
mentoring is important imho, i can still remember how horrible my internship was as I was completely on my own and there was almost like no one to guide me... then you would probably want to expose your interns to source code management and team collaboration.
Definitely avoid giving interns mundane jobs. That's a great way to make sure that they never come back to your company.
I've interned with the same company for the last two summers, and have had a great time. I plan to apply for full-time work as soon as I finish grad school. The reason was that they treated me like part of the team. I worked on the same projects that the other engineers worked on. I gave status reports at meetings like everyone else. Perhaps they didn't expect as much out of me as someone who had been in industry for years, but they let me experience what it was really like to work there. Just be prepared to spend a little extra time in code reviews and explaining how things are set up.
My company threw me in at the deep end. I'm still there, I've learned so much in 2 years and I'm so glad they put pressure on me. I was sent to work on site alone for 6 weeks as a consultant to insert 1x1 pixel advertising dynamically on a commercial ASP.NET website. I had 8 months experience at this point and was fairly clueless, it was horrible at the time. However, I now have a good idea of how to deal with office politics and my communication skills and confidence are vastly improved. Throughout the year I made a few mistakes (like debugging a procedure on production :-D) but I haven't made the same ones since.
So I guess the way to get the most out of your intern is to get them working on something important fairly soon - they'll respect you for it. I think you'll be suprised how quickly they'll come along.
Saying that though you will still have to mentor them heavily and get practices like source control, unit testing and code review straight into their mindset. They're unlikely to have learned this.
Give an intern a chance to impress you, if people know they're doing bs work then they're not going to put the effort in...
unit testing and writing code comments is always nice for interns. they see lots of foreign code and learn how to test and comment code as well
From an intern's perspective, try to rotate the interns through different positions.(kind of like Joel's management training program) When I was a intern for 16 months, I went through several different positions, such as developer, QA, system/network admin and system/business analyst, which involves lots of documentation and meeting the clients.
I was working as a developer mainly, but I benefited a lot from the system admin role and system/business analyst role.
From the system/network admin, I learned a lot of troubleshooting and problem solving techniques that you couldn't learn in a developer's role. On the other hand, the system/business analyst role taught me the skills of communicating effectively and how to negotiate with clients on budget and time line.
Therefore, I would definitely recommend giving the interns more than one role during the internship.
If the intern was particularly strong I would give them some easy support tasks, and that they have some high visibility with the end users so they feel like the problems are worthwhile and not busywork. This would give them an idea of how the business world really works where the bulk of work is supporting existing code rather than college-type greenfield work. By tracking down problems they will get experience with version control, database (probably), and release procedures. To do all these they will have to have interactions with employees to get the job done, and the questions will be constrained so their heads won't blow up from a multi-day seminar on some open-ended question.
I started at my current job as an intern, but never would've made it if not allowed to show my strengths by my then superiors. It took them coming up with creative and safe ways for me to demonstrate my skills, and eventually, allowing me the freedom to come up with my own projects and responsibilities. I had to do a lot of the dirty work, sure, but that's also a great way to get acquainted with the business, and everyone working in it.
Now, I am sure to try and challenge the current interns, to ensure that they are up to task. If they fail, then obviously I adjust my expectations. And truthfully, I often underestimate them. It's hard to remember what you were capable of before you started yourself. But I think that the instances where putting too much faith in someone ends up being a bad thing. Unless it's a mission critical scenario, you either end up with a great result and a shining new asset, or you end up with a bad result and a positive identification of someone to not include in the future.
Put me in the variety of experience camp, at least at first.
In college (too many years ago), I was a Co-Op student. We returned to the same company each school break, so the company had more time with us than the typical summer intern. The early part of the program had us rotating fairly quickly through various departments.
Later in the program both the company and the intern have a better idea what would be a good fit. So a more meaningful assignment be created.
I'd say, treat them like the in-training programmers that they are, and not like secretaries.
I worked on internal tools as an intern. The tools ranged from project management to speeding up daily tasks. I worked a lot to maintain existing tools and also wrote some new ones. I learned a lot from others' code and more importantly, how to effectively understand and modify existing code. It was an excellent way to see things in real action (loads of servers, deployment, databases, continuous build, version control, tracker system etc.). Only me and another permanent coworker worked on the tools which made it both a good responsibility and a way for me to learn from him. I was also able to see how important the tools were to project managers/QAs/Devs which made the work all the more meaningful.
I would have appreciated a bit more interaction with QAs, but they just didn't have the resource to test internal tools. I did learn some testing techniques, though.
I have a question,how much does an internship typically last ? What goals does the internship aim at ?
When I did an internship (which lasted 6 months), I spent the first while (depends on how quick you get it, I guess, I spent two weeks, others more or less) in "training" where the company guided me through their standards and code and whatnot and then after that I worked on their actual products for the remainder of the time. To start off, I was pair programming with people who had already been working on the projects, which helped me familiarise myself with the code, but later I was working on modules on my own.
I'm working in this company full time now and when I started back, I skipped the training period completely and dived straight in with some simple tasks (fix code where unit tests were failing, etc) to refamiliarise myself with the code. Within the first week, I was working on proper tasks. My point is that you need some sort of simple, non critical tasks to get the person started. How many depend on the persons skills. For a completely new person, pair programming is useful too. Once they are able to find their way around the code, they're good to go.
Note that, in my experience, most students (certainly the ones who dont code in their spare time as a hobby anyway) are pretty bad programmers, so you may want to restrict the overall impact they can have on a project.
This was good for me, as an intern, since I got actual experience working in a real team on a real product. The company liked it because they get to offload some of the required, but not critical work from their main developers. Since I came back, I can appreciate this as it lets me focus more on my area and not worry about having to write things like utility code, test frontends or whatever.
There are two main motivations for hiring interns: cheap labor and recruitment. Because there are so many good alternatives for most students with programming abilities, the cheap labor approach is often going to turn off the best prospective employees.
I'm finishing up my PhD soon and I've done internships nearly every year since the middle of high school. I'm deciding on a few offers right now and I'm biased towards a couple of places where I interned, especially to those where I had good experiences. Most places where I've been, they've seen interns as potential recruits that they get to interview for 3 months and from whom they actually get a little bit of useful work.
If you're doing it for recruitment purposes, I'd suggest picking projects with the following characteristics:
Planned: it really helps to be able to know what you want the intern to do on day 1 (or before) so they can hit the ground running. Some of my friends have spent weeks trying to look busy while they figured out what they were actually supposed to be doing.
Completable: giving a sense of closure and accomplishment is really helpful.
Real work: I appreciate working on tasks that mirror what full time people do so that I can get an idea of what it's really like to work in a place. If the project will actually be used, that's much better.
Non-critical: for most interns, you don't want to put them in the critical path of your group because they may not turn out well and you'll have to make sure you spend more time training them up on the particular processes you use rather than letting them get started working on their project faster. Here are some of the types of projects I or other interns I've seen have done: