Auto Ads by Adsense

Booking.com

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.

2 comments:

Unknown said...

It's really great to see someone speaking so positively about interns. As an intern, I always do the best work I can do and I receive high praise from it. After reading a blog that rejected the idea of the intern, your blog definitely lifted my spirits on the matter. Thanks and great post!

Arturo said...

Interns are great. I've hosted many great interns at Google. Their contribution far outweigh their cost and many of them are now Google employees. If it were for me, I'd hire as many qualified interns as I can find.

In addition to everything Piaw said, I'd add:

- Don't lower your hiring standards, but remember the level of the intern. For an undergrad, I'm not expecting knowledge of databases. But I would expect the intern to be able to code.

- Ideally, pick a project that it's not on the critical path. You don't want to take the project from the intern hands if the intern is a bit slow, if the priority increases, or if the intern is a dud (it happens). This still means given the intern a challenging and significant task!

- Tell the intern from Day 1 that an internship is a "n" week-long interview and that you are expecting the best from them. But also tell them to use part of their time to explore the company and the area. All interns in California should visit San Francisco, Yosemite, Los Angeles. Give your intern the support and the time to travel around and to go to tech talks.

- Be brutal on their first code review and make that code review happen as early as possible. This will set a high standard for their future code.

- Be available. Seat the intern near you and make clear to them that they can come and interrupt at any time.