Thursday, February 21, 2013

Internships

The conventional wisdom on interns is that you cannot expect to get significant work done by interns: they take time to train, and by the time they leave your company, you can't possibly have trained them to the point where they're productive and pay for themselves in terms of work done.

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:

  1. 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.
  2. 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.
I used to think that this modus operandi was par for the course in the tech industry, but one day I sat on a hiring committee for interns who wanted to convert into full-time employees. My jaw dropped constantly in horror at what some of my colleagues were doing to their interns:

  • 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).
Well, here at Quark Games, we're kicking off our summer internship program next week with visits to both the Berkeley and Stanford Career fairs (we'll also consider full time applicants). I guarantee we won't' do any of the crazy things described above, and my aim is to have fully productive interns all summer. While we're only visiting these two schools because they're easily within driving distance, we'll accept applicants from any school. Feel free to send me e-mail or apply through Quark Game's site if you're interested.
Post a Comment