Story from: http://alexeymk.com/a-brief-guide-to-tech-internships/

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.
• 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.