Creating an internship program for software engineers is every bit as difficult as it is important.
You have to think it through very carefully before you even start.
Why are you looking for interns?
What are they going to do once you get them into the company?
These may seem obvious at first, but as you start pondering them, you find they're anything but.
We bring you help in creating an internship program for software engineers with Tom Sommer, Director of Engineering at Redbubble. He shared what he’s learned over the past years while setting up and iterating the intern program at Redbubble. Interview by Karolina Toth on episode 47 of the Level-up Engineering podcast.
This blog post covers:
First, the obvious way: we put our internship program on the internet with an open call to join it and to see what Redbubble is about.
We reach out to specific companies and institutions we may partner up with.
We’ve been at universities, where we jumped into a lecture and introduced our internship program to see if there’s interest. We’ve partnered with local organizations, like bootcamps or women in tech groups. We reached out to them saying, “We created this internship program; it’s about to start. Are you interested in connecting us with your members?”
Depending on what kind of people you want to find, you may focus on building partnerships with different organizations. For example, when we had diverse recruiting programs trying to get more women into the company, we talked to women in tech programs.
Our goal is to start a new round annually.
We line it up with the big holiday break for Australian universities in November–December. We take on interns every year around the same time, and we work with them until January–February of the following year. We had to skip last year because of the pandemic, but we’ve been on a five- to six-year run before the break.
Many intern programs put the interns in one group, give them a side project, and periodically check on how they’re doing. We don’t do this anymore.
We aim to embed the interns into existing teams instead.
They work like any other software engineer and get the full spectrum of experience of working on a product, pair programming, and planning. This way, they’re not just sitting in the corner pretending to be part of the company.
Our interns have been loving this.
Communicate clearly and openly with everybody from the start, both with the interns and with the people at your company about what you’re trying to achieve with the internship program. This has helped us avoid frustration on every front.
We tell them from the start what we want to achieve and what we expect from full-time engineers. We are just as honest if we need to tell an intern that it didn’t work out and we couldn’t get them to the level we expect from a junior engineer.
This attitude sets the expectation for everyone involved.
This depends on the purpose of the internship program. Our programs range from simply providing work experience to scouting talent.
When it comes to providing work experience in the industry, we hold a light evaluation. We don’t expect them to have specific skills. It’s more like an open call to show the applicants what the software industry is like and giving them a leg up.
When we’re looking for engineers, we may hire by the end of the program; the evaluation goes further. In this case, we use a lightweight version of the interviews we do with full-time software engineers. Instead of going through all four to five rounds of regular interviews, we make it less taxing, but we still focus on the same topics on a smaller scale.
For example, we don’t go as deep on architecture sessions, but we assess them overall across different areas.
For example, we asked interns to walk us through how a URL shortener works. This may seem trivial for someone who’s been in the industry for years, but it’s telling about how much a new joiner understands basic concepts like databases. This helps us figure out whether an intern is at a level with which we can support or we might have to turn down the candidate.
We’re paying attention to soft skills as well. We don’t have a dedicated culture interview for our interns, but we assess them throughout the interviews and explain our expectations in terms of communication.
Communication skills and a growth mindset are important for interns. We’re looking for willingness and the ability to grow during the interview.
An internship at Redbubble lasts for about 12 weeks.
We bring interns in as a group, because we believe the community part is important, so they go through the experience together and don’t feel like they’re singled out.
We encourage them to keep in touch during this period; we’ve found this is helpful for the group. Catching up weekly and sitting down for 30–45 minutes to discuss their experiences over the past week does the trick. They provide a different type of support to each other compared to what they receive from employees who have been in the company for years.
We embed interns into our established engineering teams. They become a part of a team for 12 weeks, and they work like any other software engineer in the company. The only difference is that we provide them with extra support.
They have a manager who they can take up anything with. They also have weekly or bi-weekly one-on-one meetings depending on the team and the manager.
The support network within the team is covered as our engineers mostly work in pairs. If they want to talk to another engineer within the team, normally they can just turn to them, but the pandemic made it less trivial.
Interns also have dedicated mentors outside their teams. They can talk to their mentor about topics beyond the daily work, whether it’s technology, planning, or different parts of the business.
We tie this back to our software engineer career ladder.
We take interns with only 6–12 months of industry experience, but also with zero. This is why it’s difficult to compare people.
Some of them arrive from a bootcamp, others from university, while others may have had a six-month gig at another tech company. One intern may start on level one, another may start on level four, but the main criteria is their growth during their time at Redbubble.
The biggest difference between interns and junior engineers is that interns come in for a limited time, 12 weeks in most cases. Interns aren’t hired as full-time engineers; they transition into that position, so they can come in at any level.
For instance, if they come in at level one on our growth framework, it’s great to see during the assessment that they’ve reached level three or four by the end of the program. That means they can fix small bugs independently or contribute to planning. We’re trying to be objective and not just hire people because I say they’re awesome.
For example, if one intern comes in on level one and goes up to level three, while another comes in at level four and stays there, we don’t just compare their level at the end but their development as well. We believe growth is the most important metric when hiring software engineers. We use growth as the most important metric in the junior program as well.
The internship program runs for about three months, then we assess their growth and hire the best candidates as full-time engineers. However, this doesn’t mean we just say good luck and let them find their own way.
We provide extra structure and support for junior engineers to start them down the path from junior to senior engineer. We rotate them through different teams, expose them to different technologies and domains of the business to get them familiar with the broader context over having them go deep into one area.
We’ve had mixed results with this approach so far.
The junior support system functions as an extension to our internship program.
This part has taken us a few iterations to improve, and it still isn’t perfect.
The most important factor is growth. We’re looking for interns to demonstrate in the 12 weeks that they can absorb information, grow and make themselves an integral part of their teams. It’s not about delivering big pieces of work by themselves, but about becoming a better engineer overall.
We evaluate interns by repeating the same interview we did when they joined the company. We don’t tell them this beforehand.
After 12 weeks of working at the company, we do the original interview again. For example, we ask how the URL shortener works. It’s been magnificent to see people come in with a basic understanding and, by the end of the internship, they can easily draw up the process.
This is a good comparison to check how much they’ve picked up along the way. This gives us a sense of their progress and confidence in whether we believe that person can grow and become a great software engineer.
We aim to be consistent and make sure to have the same person interview the same intern both at the beginning and at the end of the program. We have a group of two-three senior engineers doing the interviews. I include myself as Director of Engineering as well, because I’m running the program.
This continuity has been helpful in understanding the growth of our interns.
We try to treat interns the same way as we treat full-time software engineers.
We’ve put together a list of team goals about what an intern should do, for example, run a retro meeting or a planning session.
We also set goals for them about their personal growth. For example, by the end of the program they should be able to write a small feature or peer-lead building it.
We sit down with the interns at the start and set goals for them based on the interview, their previous experience, and their ambition.
We use this as a guideline to actively support them during the day-to-day work, and we make sure they’re working towards it. It also helps when we review their performance and give them feedback based on it.
At the time we emphasized providing work experience in tech, we didn’t set a target for hiring. In the next year, we set a target to hire 30–50% of interns at the end of the program.
To give you context, Redbubble’s engineering has about 60 engineers, and we usually take on about five interns at a time. This means, we set the goal to hire 2-3 interns each round.
In some years, this worked well; in other years, we didn’t hit the goal for various reasons. The main reason was not being able to grow our interns as much as we wanted to.
We may set a target, but we don't have to hit it at any cost. If we hire people just to fill the quota, we’re cheating ourselves and the interns. It’s unfair to them and it rarely works out.
We choose which team will take an intern by looking at what they’re working on, and which team has the capacity to support an intern during that time. About half or more of our teams take interns from each batch.
When a team only has two to three engineers, adding an intern may not be a good fit.
The team’s domain is also important. For example, we learned the hard way not to put interns in our infrastructure team, because they don’t learn about that field in a bootcamp or a university. This would split their focus between learning how to work in our company and learning a new field, making the internship harder than it should be.
Getting this right has been a challenge for us.
We choose mentors on a voluntary basis. Many of our engineers sign up to mentor new developers so we had to turn many of them down with the current batch of interns. Our senior engineers have been eager to take on supporting interns.
Many of these mentor-mentee relationships last in the long run. Former interns keep catching up with their mentors on a regular basis to chat, and they keep providing support. This has been great for everyone.
Early on, we put the new interns into their own team, gave them a task to rewrite a system or a project for us, and checked in on them periodically. The point wasn’t to test whether they could do it, but we thought it was a good way to gain experience.
It didn’t work out well.
This is why we transitioned to embedding interns into teams to give them the full experience of working on a product engineering team.
We try to only hire interns who we can support and potentially take on as a full-time engineer. We’re still working on getting this right.
We often have people in the intern program who have coding experience, but they have never held an official job in the tech industry. Most companies can support interns on this level.
However, many companies can’t support people who have never seen code before. Bringing up people from that level requires a certain structure.
When you’re building an internship program that you want to use to scout talent, you want to avoid bringing in people who you can’t support. It may be for a number of reasons, like lacking the structure or the processes. It’s disappointing for your interns because you don’t hire them, and it’s disappointing for the company, because the program fails to do what you set out to do.
Tom is from Germany, but he moved to Australia 15 years ago. He started working at Redbubble nine years ago, and worked his way up from software engineer to Director of Engineering.
He found his passion in engineering leadership working with people, building structure and culture. He took part in starting Redbubble’s internship and junior programs, creating growth frameworks and establishing an engineering culture, and he’s been blogging about it too.
🚀 Need developers for your team or project? Hire our experienced Angular, React or Node.js developers! Click here for a FREE consultation.
About the author:
Gabor Zold is a content marketer and tech writer, focusing on software development technologies and engineering management. He has extensive knowledge about engineering management-related topics and has been doing interviews with accomplished tech leaders for years. He is the audio wizard of the Level-up Engineering podcast.