Ensuring interns get the most out of a summer with the team
For two consecutive summers, I interned at Microsoft and remember fondly my excitement working at a large company. Everyone I worked with was smart, kind and eager to help. I had a great time but didn’t learn what life would really be like as a professional software developer.
Internships are an extended two-way interview. The company evaluates the intern as a potential future employee, and the intern evaluates their fit with the company… or possibly determines whether they even want to go into the software industry at all! A good program enables the intern to leave the summer with a greater clarity (as much as you can have in your early 20’s) about their future.
Ensuring interns get that clarity was my mission when I eventually became an intern manager. I set out to structure their summers with following goals:
- Be part of the team
- Work in the team’s codebase
- Ship!
Be part of the team
During my internships, I worked by myself on stand-alone tasks. While I worked hard and completed both projects, I was disconnected from the team and missed out on an important mission of the summer internship program: learning what it means to ship production software and what it is like to work together with a team of developers.
To know what it’s like to be a part of a software development team you must be included and valued the same as any other developer. On my team, interns attend the daily stand-up with the rest of the team and discuss status. They are part of our weekly grooming meeting where we breakdown specs for future work. This grooming meeting can be intimidating since it is fast paced with a lot of people throwing out opinions, so I encourage the interns to speak up and ask questions. If they don’t like a design, tell us. If they think the color pattern is gaudy, tell us. If they don’t understand what we are talking about, ask us. As the summer progresses they tend to open up and begin taking part.
The team also benefits from a fresh perspective. When you work on a product long enough you get used to the bad parts and start to ignore them. An intern can provide a different view point and help challenge the assumptions that have grown in the team.
Interns sit in the team room and are encouraged to ask anyone for help when needed. They are immersed in our culture, where engineers frequently pair on issues and ask each other for help. Because it can be overwhelming at first, I make sure interns have a single mentor to start off the summer. This way they can build a rapport one-on-one as they get over any initial apprehension. Over time, they will get to know the rest of the team and realize everyone has their back.
By working in this environment, interns learn what a healthy team environment is like. They see what it’s like to have other engineers supporting them and helping them succeed. They can see what healthy debate and disagreement looks like. They can see how a real software team works.
Work in the team’s codebase
I have seen many interns given projects that are interesting but aren’t related to the work the team is doing. These may be side projects or one off tools that they build from scratch but are not connected directly to the code the team members are writing.
By working in a silo’d project like this the intern misses out on the chance to learn what it’s like to work inside of an existing large codebase. This is hard and daunting at first. They will go from working on school projects with thousands of lines of code to a code base that has hundreds of thousands of lines. However, this teaches them how to navigate a real production code base, how to write code that other engineers approve of and the process of peer review (in the form of pull requests). The other team members will take the interns code changes very seriously since they know they will need to live with this change and review it thoroughly.
When my interns send their first pull request they are often surprised by the amount of feedback they get. They will question if they did something wrong but over time they learn this is how the entire team shows they care and want what’s best for the product.
By working in the same codebase they feel part of the team (my first goal). They learn to speak the language of the team.. They begin to recognize the difficulty of working with the crufty legacy code and the beauty of touching the clean and well tested code.
I felt this experience was sorely missing in my internships. Both my projects were things I wrote from scratch and there was no pressure on me to write good software. I was just trying to get it “done”. Getting the interns in the codebase ensures that the code they write is production ready and unit tested code.
Ship!
Shipping software is one of the best feelings for an engineer. That moment when you see your change live in production is a thrill. When interns start I set a goal with them: within the first week they will commit a change which will roll out in our next deployment. Typically within the interns’ first 3 weeks, they see their change in production. This starts with a small change that teaches them the codebase and the pull request process but is still something that adds customer value.
Once that change ships and they learn the cycle of putting code into production, I have them work on a slightly larger change and ship that. I break the internship into a few cycles like this. Each time, the work is larger and more complex. Over the course of the summer they will ship multiple times to production and even get to ship updates or fixes to their previous changes when they get customer feedback.
Closing time
By the end of the internship the interns have achieved a lot. They understand what it is like to work in a large code base. They know how to write high quality code. They have experienced what it’s like to be on a real software development team. They have the information they need to decide if this is what they are passionate about or if they want to explore something else.
While these three goals go far to help the intern gain clarity for themselves, they also give the manager plenty of insight into the interns fit with the company. After I have seen them work in my team’s code base, write new features and handle feedback, I have a good idea about whether I will offer them another internship or full time employment the next year.
Mission accomplished!