6 Tips for Starting a Software Engineering Internship

On Monday I’ll be starting my third internship with Microsoft, and my fifth internship in total. Reflecting on my previous internships and preparing for the coming one I came up with six tips that have helped me in my internships¹.

1. Ask lots of questions

This very well might be the cardinal rule for interns. It can be scary to ask questions because you don’t want to show that you don’t know something. Bad. Fight that impulse. Everyone understands that interns don’t know a lot of things. If they wanted someone who already knew everything they would not have hired you. What they’re looking for is someone who can learn quickly and level up. Questions are an essential step in that process.

Ask questions about everything. Why am I getting this error when I run the app? How do I test this code I just wrote? Why are we using Python instead of Go? What should my pull request look like? What part of the codebase is Sheila responsible for?

There is no such thing as a bad question. However, there are better questions. Make sure you’ve tried to answer the question yourself with a quick search on google or the company wiki. And be respectful of people’s time, make sure that you’re not interrupting people so often that they can’t focus².

2. Talk to everyone

Typically in an internship you’ll spend lots of time talking with your manager and mentor. But, I suggest you make an effort to talk with a lot of other people too. A conversation with your skip level manager can give you a better idea of the big picture. Talking to other engineers or product managers on your team will give you more context. And I even recommend you reach out to people outside your team as a great networking opportunity.

As an intern you can pretty much ask anyone to talk and they’re likely to say yes. Make sure you come prepared with questions you want to ask. If it doesn’t go well then don’t sweat it. Not every conversation you have will be perfect.

3. Understand the big picture

I think that understanding the big picture is drastically underrated on internships. Doing this can set you apart from being a good intern to a great intern. By understanding the big picture I mean that you should make an effort to understand the why, not just the what or how. Why is the software I’m working on relevant to the business. Why are customers buying our product? Why do we need to solve this problem with software? And so on — you get the point.

You will be able to make much better decisions by taking the time to look up and understand the world around the software you’re working on. For example maybe it’s really important that spend that extra time to polish the styling because you learned that a key reason why customers switch to the product is a more intuitive UX. I also find that understanding the context around why I’m building something motivates me even more.

4. Focus on the details

The big picture is important, but so is the minutia. Make an effort to really understand the small area of the code that you’ll be working on. Try to become an expert on it. This will pay dividends as you work on your project.

Don’t worry about the details of anything adjacent to what you work on; understand how the pieces fit together but save learning the details of those systems for later. Internships are so short that you only will have time to go deep on a small part of the whole.

5. Write stuff down

You’re going to have a lot of information thrown at you as you start your internship. Take the time to write the important bits down. Stuff like that obscure command you need to run to startup the database, or the list of important domain objects you should learn. These notes will help you from constantly needing to nag your teammates to ask them the same thing over and over.

6. Ship code as quick as you can

Shipping code is the strongest signal that you are meaningfully contributing to the team and going to be a good fit. You want to do this as quickly as possible. At a startup that might mean you’re pushing a small PR on the very first day — something like a bug fix or documentation. At larger companies a more reasonable goal is in the first week or two.

A good leading indicator for how quickly you can ship code is how quickly you can clone and run the codebase. Ideally you’ve got it running in the first few hours at a startup or in the first few days at a large company. You’ll probably run into lots of issues while trying to run the code; this is a perfect opportunity for a quick PR updating the README.