Lessons Learned from Our Engineering Internships Program: Part 2
By
Adam Anthony /
Use Cases, Developer, Company
Nov 07, 2019
Navigate to:
In 2019, InfluxData hired its largest-ever class of interns in the engineering department, with a total of 5 hires into our storage and query language teams. This series of blog posts discusses our experience gained from building this program. (You’ll find Part 1 of this series here.)
In Part 2 of this blog series, we share some tips on how to succeed with remote interns.
Succeeding with remote interns
A common trend in hiring remote engineers is that they must have some seniority. After all, the ability to work independently and with non-constant guidance can be challenging to junior-level engineers. InfluxData has a remote-first culture for engineering where there is little difference in the contribution one can make regardless of whether they work in our San Francisco headquarters, or in any number of cities around the world. When we decided to add an internship program to enhance our remote team, we knew that we would have to plan ahead to make sure that we were prepared to properly support a team of remote interns.
How we view interns
The first way we view interns is as open source community contributors. With limited experience and a clear mind, a skilled intern gives us an excellent insight into the structuring of our open source projects, from code structure to tooling to build processes, to quality assurance. We also get daily feedback from them about whether a particular library or tool is hard to work with. Oftentimes, in working through a difficult process, we find that there are better ways to explain it. Other times, interns’ work can validate our assumptions about how community members will work with our code base.
The second way that we view interns is as internal team members. Within reasonable expectations about their experience level, we do expect interns to be picking up issues off of our backlog and submitting pull requests to merge solutions into our production process. Now, this all occurs with some safeguards, due to their limited and temporary status with the company. First, they are granted fewer git privileges to prevent accidental damage to our repository history. Second, interns do not do any on-call or operational work to support our products. Finally, interns must always have their code reviewed by a full-time engineer.
We also view our interns as students. We value the opportunity to teach them the elements of style and craft that go into high-quality software engineering. We provide extra meetings and support to ensure that they have the guidance needed to act with confidence. And if they act confidently and fail that’s OK. According to our core values we embrace failure. Successful interns should not be placed in a situation where success is defined on whether or not code gets merged. Instead, we aim to provide work items that are a benefit if they are finished, but not a blocker or loss to the team if they are not. Even the best students may have times when they struggle with a task and it must be abandoned. It’s important for team culture, and the well-being of the intern, to understand that learning from the experience is valuable in and of itself.
Tips for a successful remote internship program
At the completion of our 2019 summer internship program, we conducted a series of exit interviews and retrospectives to find out what worked and what didn’t. Here we will discuss our findings and offer some techniques that we believe can be reproduced to help other remote teams successfully integrate interns.
Above all else: Prevent isolation
Isolation causes a number of problems for any remote employee. It’s in our most isolated moments that a small voice inside can be heard: you can’t do this; everyone else knows what they are doing; if they wanted to know what you thought they would ask. Experienced remote employees know how to avoid these feelings, and we all have techniques that work for us personally. Interns, in their inexperience can lose weeks of productive work to feelings of deep isolation. Therefore, most of the advice in this section involves a single principle: prevent isolation.
Team organization principles
- Hire interns in cohorts of at least two. Providing them a peer group to relate with will reap dividends in terms of confidence and motivation.
- Assign each intern an individual mentor. This is a person who the intern understands will be available for all questions. They should feel permitted to interrupt this person at will and trust that proper feedback will be provided if the questioning is too much.
- Clarify that the whole team is responsible for helping all the interns. Mentors take vacations, get sick etc.
- Develop new managers. If one of your engineers has expressed or shown an aptitude for a leadership role, assign them to manage the whole group of interns. This is in addition to individual mentors. The intern manager will lead a separate planning/scrum meeting every day to supplement the full-time engineers' meetings where decisions may go by too quickly for the interns to fully grasp what's going on. The extra meeting gives them a chance to ask clarifying questions that may have been disruptive to the flow of the regular meeting. It also gives the manager a chance to be sure that each intern has formed a work plan for the day/week.
Team work principles
- Don't waste too much time in training. They need to know what they are doing well enough to keep them from doing harm to your repositories, but otherwise, let them learn on the job. They are eager to write code that's meaningful. You'll see such a huge difference in an intern's productivity after they merge their first pull request. Get them to that point as quickly as possible!
- For their second or third week together, assign a large epic filled with small tasks to the group. This helps them in a few ways. First, they have a fast way to find appropriate work items. Second, they are, if you choose good issues, working on productive contributions. Finally, as they see the long list of issues whittle down and finally close the epic, they will form a bond as a team around the sense of collective accomplishment. Good sets of work include writing tests, low-priority features, tech debt that isn't too complex to fix, or even just a collection of unrelated "intern-friendly" tagged issues.
- Mentors should do a daily check-in. Yes, we tell interns "you can ask me questions any time," but sometimes, they don't. Particularly with remote interns, we don't have cues like body language or laptops being thrown in a fit of rage to let us know someone is frustrated. The check-in does not have to take any time. Send a message on Slack: "How's it going? Any questions?" Sometimes they don't have anything, and that's great. Sometimes they do. After a few weeks, they will feel like their working relationship requires frequent, open questions and you'll find that an intentional check-in becomes less necessary.
- Code reviews must have two reviewers. These are a full-time engineer and an intern.
- Occasionally, do a live review. This is where the full-time engineer will do the code review as they normally would but will think out loud during a video conference so that the interns get a first-hand experience of the team's expectations for coding quality and standards.
- Have a mid-season gathering at a central location. If your company has a headquarters, set up a week to bring everyone in for a physical meetup. There are several choices we made in planning our meetup that ended up being highly successful:
- Plan for the majority of time to be a hackathon event where interns will form larger groups across teams and work on significant challenges.
- Don't schedule it too early: give them a few weeks to learn the platform of code so that they can feel competent to generate new, useful ideas.
- Don't schedule it too late: we observed that the experience was a great team-building and friendship-building event. Make sure they can enjoy the benefits of the week for some time afterward.
- Give interns time towards the end to explore new things. Within 2 weeks of their end date, stop assigning issues and encourage them to just go try whatever they want. They've worked hard for you, and they've earned some time to pursue an interest.
