A brief guide to tech internships

Planning to be an Intern in the Bay Area during Summer 2012? Make sure to read an Intern's Guide to the Bay Area, and join the 2012 Facebook group.

 (via this guy, via this guy)

Joel Spolsky, from the Joel On Software blog and StackOverflow, wrote an article with Advice for Computer Science College Students back in '05. According to Joel, 

No matter what you do, get a good summer internship.

As such: here’s everything you ever wanted to know about tech internships, plus some bloviating about my experience. The TL;DR is, try to have at least two internships: one at a small start-up and one at a tech company.

Wait, who are you?

I'm a CS senior at the University of Pennsylvania. I have interned at Facebook (Summer 2010), where I worked on application privacy, and as a generalist at 2bkco (Summer 2011), a new startup from serial enterpreneur Caterina Fake (Flickr, Hunch).  Both internships were great and invaluable. They were also very, very different, in terms of both the type of work I had to do and what I gained from the experience.

1) How do I get a good internship?

Luckily, a number of great posts have been written about this subject already.

• Andrew Munn has a great piece on interviewing and applying for tech internships, focusing primarily on what larger companies are looking for.
• Gayle Laakmann, author of Cracking the Coding Interview, has a post on the difference between what startups and tech companies are looking for.

To which I add my two cents:

• Start thinking about summer internships around Winter Break. Make a list of potential companies and start applying.  Don't be worried if the entire process takes until April or so, though.
• Get a referral rather than applying directly whenever possible.   Ask upperclassmen you know (think: TAs that like you) who could make a referral.  For earlier-stage companies, if they don't have an explicitly-listed referral program, don't worry about it: email the CEO. Hint: they are probably at firstname@startup.com.
  (via Hugh MacLeod) 
• Practice technical interviews. If you're nervous about writing code on the whiteboard, try some combination of being drilled by upperclassmen, buying (and practicing going through) Gayle's Cracking the Coding Interview. Others also recommend interviewing with the companies you aren't as interested in first, using them to train.
• Optimize for what you can get. Bigger companies are going to (generally) look for a high GPA and good performance on brain teasers.  Smaller companies are going to prioritize a history of initiative and automony, as shown by cool projects on your resume.  If you've got a high GPA (at least 3.7 at Penn, say) and are good at brain teasers, you should be OK with larger companies; if not, start with a start-up.
• Your timing is great! Literally everybody is looking for software engineers right now, and internships are one of the key ways to recruit for companies. The market could not be any better for us. If you feel like you're not getting anywhere, make sure to apply beyond whatever is immediately available on campus. Competing with the general populace may be easier than competing with others at your university.
• Consider a mass-application or 'summer program', which are often offered by venture capital firms and have gained popularity in recent years.  Make sure to check out (and potentially apply via): hackNY fellows, Andreesen Horowitz, First Round Capital, True Ventures, Kleiner Perkins Fellows, Bane's StartUp Academy, NYC Turing Fellows, InterviewStreet and InternMatch. None of these are a substitute for applying to companies individually (and I haven't tried them myself) but given the reasonably short time required to apply, they are probably worth doing.
• Location is a pretty big deal. Try to be in the Bay Area (Silicon Valley, San Francisco, Mountain View, Palo Alto, etc) if you can - it's awesome. and there are a ton of other interns around.  I hear New York is getting pretty fun as well, but don't have any personal experience. Other tech regions like Boston or Austin (and maybe LA and Philly) aren't bad, but make sure not to get stuck in the middle of nowhere, living in the suburbs as the only tech intern at a huge company.  That does not a fun summer make.

2) How do I pick where to apply/work?

Before applying, consider: "Am I excited about the products this company makes? Would I be excited to know that I work there?" It's much easier to get motivated (and show excitement) for a company you are excited about. I was Dropbox user #2001, which I did not neglect to mention when I applied. It helped. I think.

I strongly advice looking for internships with a big tech company or a startup, rather than a non-tech company (esp. financial) company that happens to have engineers. The explanation is a little long, so I'll just assume you nod along hummingly here. For the inquisitive: here's a longer argument.

Picking a startup
You want to work for (and learn from) the start-ups that are going to be successful, but as the Venture Capital industry knows full well, it's not always easy to pick winners.

There are, however, a few hints that you can pick up on and prioritize for when thinking about where to work:

• Has the founder had a successful start-up venture in the past? They must have done something right; past performance appears to be the best guarantor of success for tech enterpreneurs.
• Is the founder (or a large portion of the founding team) technical? Are they writing code? Do they come from a strong technical background, whether at a startup or from a top tech company?
• Does the company or its employees have a track record of being good mentors?  I wrote a Mentorship Checklist: questions worth asking to find out.
• Is the company pre or post "product-market fit?"  That is, are they figuring out what the heck it is that they are going to do that makes money, or have they figured it out and are trying to scale and make sure the servers don't melt with all the new traffic?  Both are exciting times in the life of a start-up; consider a pre-product market fit company if you're looking to get a big opportunity to contribute creatively and try new things, and a product-market fit company if you are interested in the technical challenge of quickly scaling a codebase.
• Is this a 'well known' startup? One of the downsides about working at a startup is that it doesn't usually yield the brand recognition of a 'Facebook' or a 'Google' on your resume. Working at a small company people have heard of (TechCrunch coverage/Twitter buzz being a reasonable proxy for 'heard of') helps negate that. Think (again) Quora, Path, Uber, Square, etc - small teams but well-known products.

Picking between larger companies

• The easiest way to figure out if a larger company is worth working for is by their reputation: ask upperclassmen, friends and professors.  
• Does the company have an official internship program? Does it sound awesome? Can you speak to somebody (ideally from your school, but from the company if not) who has been through the program as an intern? Talk about both intern housing and make sure to run through the Mentorship Checklist.
• Sites like glassdoor.com, which offer anonymous feedback from employees, a tremendously useful service as you try to figure out if this is one of those 'magical companies'. The sample size is not large enough to use for companies smaller than a few hundred employees, unfortunately.
• It's not always immediately clear whether a company is or is not a 'tech company' - Amazon and Barnes and Noble both sell books online and have e-readers available, but (from my intuition) Amazon is a tech company that happens to sell books on-line, whereas B&N is a book retailer that has been forced online and into e-readers by the prevailing winds of change. Which one sounds more fun to work at?
• One sign of an innovative company is a technical or product person in the CEO role - think of Larry Page's involvement with Google products compared to somebody like Lowell McAdam (who?) at Verizon.  It's more fun to work for a culture trying to build the future than one trying to maximize this quarter's revenues and 'maximize shareholder value.'
• In general, newer companies will have less middle-management cruft and set-in-their-wayedness than older ones.  There are some older companies with solid programs, like IBM's Extreme Blue, and some newer companies with terrible reputations I would advise against.

3) What you learn
(or at least what I learned)

In short, working with top technical people will teach you software engineering 'done right' (IE, no more turning in ugly code for your homework assignment that is going to be auto-graded once and then filed away forever). That means different things at earlier and later stage companies, though, and I can only relate my experience.

What I learned at Facebook
First and foremost, I learned to write 'good code'. My first non-trivial commit (15 lines or so) was rejected 6 or 7 times until I finally put the right amount of spacing in an "if (" and fixed my trailing whitespace. These were important, brilliant engineers politely telling an intern, time and time again, something that he should have found in the coding guidelines doc. I've been a little bit embarrased to show a lot of my pre-Facebook code, as a result - the improvement, at least for me, was significant. 

In general, the experience taught me that Code is Culture. The fact that top FB engineers were willing to spend so much of their time on code reviews was a fantastic way to show-not-tell Facebook's commitment to good code. I can't say that I've been able to pay the overhead of 100% code reviews on every project or team I've worked on since, but having the background of working in a 'code quality matters' team has infused the way I think about programming today.

I also learned that engineers are not immune to politics, even at great companies. I was playing around with a hackathon improvement to one of the sharing features, but the engineer who understood most of the code would not reply to my emails for weeks and claimed he was busy (which he was) when I walked over to his desk. My original pitch for the feature I wanted to work on was "You know what sucks about Facebook? X.  We should fix it." In retrospect, I did not do nearly a good enough job of trying to get the person on board or show respect for the work that had already been done.

What I learned at 2bkco
I joined the team several weeks after the engineering work had begun. It was very humbling to see the ease with which Eric would put together a component and then decide, several days later, that there was a better way to do something and throw it all away. When you know your code has a good chance of being thrown away, the priority becomes writing quickly in a way that can be cleaned up later (which is different than writing sloppily or writing 'homework' code).

I also got a lot of training in breadth: 2bkco required me to be close-enough to fluent in Javascript (Coffeescript), Ruby on Rails and HTML/CSS. It was too early in the life of the company for me to specialize, which meant a lot of time on Google and StackOverflow, learning how to do a ton of things as I went. I became much more comfortable forking Github projects of things that did sort of what I wanted.

Fin.

That's it. That's all I've got. Mostly. Comment with questions, or just tweet me, yo.

Some valid points brought up via this post's discussion on Hacker News.

Planning to be in the Bay Area during Summer 2012? Make sure to read an Intern's Guide to the Bay Area, and join the 2012 Facebook group.

...I see you're still here. Alright.

PS. What about other types of internships/summer activities?

I spent the summer after my freshmen year doing all sorts of odd things, from playing a lot of Settler of Catan online to working in recruiting for my father, to travelling around in France. It was a mixed bag, unstructured in a way that (in retrospect) I found less than ideal.

There's nothing to say that working all three summers is strictly necessary, or that the two internship types I recommend are your best options (though I happen to think so).  Here are some other options for either a third internship or an alternative to the first two, in something resembling-but-not-quite a ranked order.

• Intern as a Product/Project Manager - A lot of larger companies offer these; though they require a technical background, day-to-day involves more management and product work than coding itself.  Harder to get (as far as I know) than a software position, but worth trying if you are interested in that sort of thing. Google has a particularly prestigious APM position that appears to be a blast from what I've heard.
• Research - find a professor you like that is working on something cool and spend a summer in their lab. This doesn't pay quite as well as an internship but is worthwhile doing if you are considering getting a PhD and want to experience the research process first hand.  This is also worth doing earlier in your undergraduate career, since the positions seems generally easier to get and the work you do will help with internships later on.
• Open Source - consider applying for Google Summer of Code or contributing to one of Apache's projects. Again, the pay (if you are in a structured program) isn't as great, but you still get to learn a ton from talented developers and get the feeling that you are contributing to something that a lot of people depend on.  Again, having a substantial open source contribution is a great resume builder. 
• Freelance/own projects - If you've got the self-motivation and enough HTML/CSS/simple back-end skills, everybody and their mother seems to want a simple website built for a few hundred bucks.  Spending a summer working on a lot of simpler projects is helpful if you're interested in learning the business side as well as pick up pretty good design skills - just make sure to be in an area with a designer/developer community, so you have more than the internet to rely on for finding clients and getting advice.
• Work for a small dev shop - A lot of higher-end freelance and consulting in the US is done by small freelance shops like ThoughtBot and (originally) 37Signals. A lot of innovation in software development (Ruby on Rails, for example) has come from shops like these.  Plus, working on a lot of projects means a lot of breadth. The caveat is that the pay isn't as good, the deadlines are set in part by the client's needs, and there is less creativity on the product end.
• Non-technical internship (or travelling, or non-profit work) - These can be fun, but if you're looking for a career in tech, make sure that your non-technical internship is not done at the expense of getting enough coding experience by the time you graduate.  Companies looking to hire you as an engineer will be far more interested in what coding work you've done than in anything not directly related.
• Tech internship at a non-tech company, especially in finance: Most of these will not pay as well and not (typically) have first-class engineers. Finance is an interesting case here: the pay can often be several times larger, if you are working on algorithmic or high-frequency trading (largely at smaller firms run by technical people). Still, in most finance firms, the traders are first-class; I've had some friends who have enjoyed their finance internships, but a lot have not. Buyer beware: the difference between a $5k and a $7k a month internship doesn't buy happiness.

PPS. Notes for International Students

In general, the situation is a bit of a mess. But: if you're studying in the US on an F-1 visa like I am, here's what I've learned:

• After you graduate, you are allowed up to ~18 months of OPT to work in the US without needing an H1-B or similar visa, which is great because H1-Bs are non-trivial to get.  You also get 12 months on top of that, via the STEM extension (ask your International Programs office).  
• There are two ways you can stay for an internship in the US in the summer: OPT (Optional Practical Training) and CPT (Curricular Practical Training).
• Applying for OPT means you need to apply by February or March at the latest, and (eventually) have an offer letter from your company.  Unfortunately, the time you take eats away from your post-graduation OPT allowance.  Larger companies will be better suited than smaller ones for dealing with the paperwork that OPT entails.
• Applying for CPT is much faster (the University, rather than the State Department, approves these), but CPT means that you're taking an independent study with a professor as part of your internship (for me, this meant writing weekly reports). It also means you're paying for your summer class, which cuts into your profit from the internship.  It does not, however, cut into post-graduation OPT time. Speak to your department about precedents of CPT being done - generally, somebody will be familiar with the process.
• Alternately, if you work on campus, there is some sort of interesting exception where the work doesn't need to be under either OPT or CPT.