I've led internship programs at Mpath and Google, and each time I've defied conventional wisdom. Mike Danylchuk, Alex Murkes and Carolynne Surfleet all interned for me at Mpath, and they did tremendous amounts of work. Both Alex and Mike converted to become full time employees, and were immensely productive.
At Google, Stephen Chen, Phil Sung, Matei Zaharia, and Nikola Postolov all interned for me at Google. All 4 were immensely productive, and Stephen and Phil eventually became Google employees. All these engineers made huge contributions to their projects, and more than paid for their training time.
I attribute my past successes at hiring interns and managing them to two factors:
- I don't lower my standards when hiring interns. I interview and apply the same metrics to interns as I do to full time employees. You can do this if you focus on fundamental computer science and coding problems during your interviews.
- I don't give interns "make work" or insignificant work. I put them on high risk projects with complete ownership of a project from end-to-end. They do the design, they code, they test, and they deploy. The sense of ownership and satisfaction with the end result gives them a hugely positive experience. This doesn't mean I just let them do their thing --- I provide design reviews and code reviews, and I provide suggestions as to which projects would be good uses of their time and talents, but providing autonomy is the key to engineering happiness.
- Putting interns on demoware, code that effectively would have to be thrown away if the data input ever had to change.
- Having interns pair program with each other, relieving the mentor of the need to code review or provide feedback to the interns. Unfortunately, this also meant the intern supervisor had no clue how his interns were doing, and whether they would be a worthy hire.
- Writing glowing reviews for an intern who did very little or next to no work (had no checkins into the source control system).