1) Work - we're young right now and don't have too many commitments so why not put in some extra time to excel at your main project and even take up some side projects. It's okay to stay in the office later than most other older engineers.

2) Networking/Side projects - talk to other people in the firms, see what they're working on and offer help if needed. These might be the same people/team that may hire you for full-time one day

3) Learn - Pick at people's brains, I know at my firm most people are willing to take some time to help me. Anything that can be found on stackoverflow or a book just use that but it may help to go over some design/implementation stuff with other more experienced engineers.

4) Software - Learn from the design and testing flows of the company. Try to separate yourself from the way you write software in class or for yourself and understand the way software is developed at a production level, from test-driven development to properly deploying your software.

The worst intern-specific train wrecks I've seen involve the intern's keeper(s) not having an accurate view of the interns abilities.

The worst young-person-specific train wrecks I've seen involve young office employees having an incorrectly high assessment of their office culture knowledge. Nothing I've seen on TV and movies about office culture is useful or enlightening. Culture, as in local traditions for interpersonal relations and local shared group priorities.

"This is bullshit" in the source code comments makes your TA laugh and is appropriate at school, but at work the execs and customers who get source access don't think its funny especially if you make fun of the customer. Some of the most trivial basic management skills that often aren't applied in school at all, but are applied at work, like compliment in public and blame in private. At school in algo class culturally all that matters is getting the best O(n) behavior because thats kind of the point of the class, possibly work culture is not so interested especially if there is a basic physics reason or financial regulation reason n can never exceed 3. (edited to emphasize its not that these specific examples were right or wrong, but that it wasn't "gotten" that they were wrong at that work team, but the new guy genuinely, incorrectly, thought it was a cultural fit)

Its not so much being right or wrong in an absolute sense the problem is thinking they know the culture better than they do leading to innocent inaccurate behavior decisions.

Keep an open mind and be humble when viewing the work of your more experienced colleagues. You will see things that will seem downright silly to you, but you have to consider that there was probably a very good reason for why something was done the way it was.

Every internship I have had, I was with a team that tried to give me the best experience I could, and never gave me boring or menial tasks just because I was the intern. In fact they actively avoided doing so and did these things themselves.

On my first internship there was a task that came in. As part of a security audit, we had to verify that all ssh keys that had access to sensitive infrastructure. That had to be done by hand, by running around and finding these people and checking their keys manually, which was nearly a days work. I volunteered to do it, as really that's the sort of stuff that I should be doing as it would be wasteful for the others to be spending their time on it.

Things like that got me a lot of respect. As an intern, you need to make the lives of those you work with easier. If this means occasionally taking some menial work or writing scripts to automate their tasks.

My strategy is to ask informed questions. Do your best to understand the problem, the motivations, the context, and the available solutions before you start asking questions. Group all of your questions together as best you can and ask them at the same time. Asking questions randomly and repeatedly will probably annoy someone who is trying to concentrate on a task. You might even find that you think of the answers while waiting for the right time to ask.

If it is clear that you are giving it your all, and not wasting their time, then people will be much more inclined to help you.

Some examples:

Bad question: How do I do {X}?

Good question: I've learned how to do {X}, but should I instead do {Y}?

Bad question: Have you seen {X feature, code, etc}? Why would someone do something so dumb?

Good question: I understand what {X} is doing, but it's not clear to me why we did it that way. Is there a requirement that I am missing?

Study their workflow and design process well. Learn DVCS (git, hg) very well and the best practices that come with it (especially branching).

Once you have branching down, you can create your own branches without affecting their work.

Never use --force.

That makes is basically impossible for you to be a headache.

Use local databases only for testing/dev. Make sure you have a development server ready that's ok to wipe at will (so other devs don't cry about it).