What does it mean to be an intern manager? Carefully select a project from your team’s roadmap, create concrete plans of the project for a three-month internship, help the intern grow indenpendently and finish the project.
I have been intern managers in the past three summers. Along the way, I’ve learned a thing or two about how to make better intern projects and how to keep projects on track. I want to share a few notes with you about them in this post.
Before we start, It’s important to point out two things.
First, the intern manager role is not just a usual management role; the role is more or less a mix of people manager and the tech lead of the project. As a manager, you need to trust and support the intern’s independent decisions, show empathy during the intern’s hard time, identify the intern’s talent, and help clear the execution path. As a project lead, you need to be an expert on details to be part of the project design and code review process, and to lead the direction, estimate milestones, make sure the code quality, and keep projects on track on the technical side.
Second, you should hold the same standard for interns as for colleges who just join your team. From the company’s point of view, hosting an intern is an economic way of not getting false positive in hiring, and you’re at the front line to observe how the intern work. Jot down often why you think the intern would succeed or fail if they join the company after the internship, and give feedback to help the intern grow.
Making an Intern Project
In this section, let’s take a look at how to make a project for an intern.
You may ask, are intern projects special projects? Not really, but we do need to consider the two facts:
- The internship is short. A rule of thumb for project time: use the first week for onboarding, last week for handoff, and one week for buffering in every four weeks. So you should design only 8-week fulltime work for a 12-week internship.
- After the internship, the team needs to continue working on the project. And most likely you‘ll be the one that continues to drive it.
Making a project for interns is thus slightly different than, say, for your team members. To maximize the interests of both the intern and your team, build code-heavy projects. The following three steps help build project plans:
- Picking a project: pick a project from the team’s roadmap.
- Scoping the project: brainstorm the end product, write down core features that make it MVP (minimal viable product) and features that enrich the MVP, list goals, stretch goals, and non-goals of the project.
- Setting milestones: break down the project into smaller tasks and set milestones for the project.
Picking a Project
Someone will need to continue the project after the internship. Even if the intern has done a perfect job to drive the project to the point where it is continuously rolled out, the team still needs to maintain it. The project tend to have a shorter life if the project is created from nowhere, especially just created for the sake of internship.
I recommend to pick the project from the team’s roadmap. One concern of using roadmap projects is potential delays as the intern might have a hard time keeping up with the schedule. I believe a proper “project scope” (see next section) can help reduce the risk.
The last thing to note in picking a project is that a code-heavy project can usually give more signals about the intern as an engineer.
Scoping the Project
Like any software projects, you’ll need to decide the project scope before anyone can work on it (you don’t say!). How to decide the scope of the project?
Scoping a project is the process of making goals, stretch goals and non-goals. Take a data migration tool as an example. The project is to build a service to migrate data from service A to service B. One likely goal of the project can be as simple as being able to migrate data. But this goal is just too vague to be useful. Let’s follow the following steps.
First, let’s brainstorm all the features you might want from the project:
What about the basic functions?
- Can list all migrations, can start/stop a migration.
- Come with a command line tool for the above interactions.
- Come with a web interface for the above interactions.
- Store the migration history for at most 30 days.
- Can verify the permission before launching a migration.
What about its fault tolerance?
- Can resume a migration if the service is crashed.
- Can pause and resume automatically when service A or service B is down.
- Can throttle the migration if service B throttles the migration traffic.
What about performance?
- Migrate 100TB data from service A to service B within 10 hours (the data should be copied at 3GB/s sustainably).
What about the quality of the service?
- Can verify no data loss in migration.
- Is unit tested. The migration process and failure cases are integration tested.
- Is continuously deployed
And lastly what about the monitoring?
- Can upload service statistics as time series to log time series event
As you see, the more concrete we are, the easier it is to define the project.
Then, let’s aggressively cut down features to make it a MVP. The remaining features are the core features, and the removed ones are enrichment. One example is:
After aggressively remove features, the service should be able to:
- start/stop a migration, list all migrations.
- verify the migration has no data loss.
- resume a migration if the service is crashed.
- pause and resume when service A or service B is down.
- report migration statistics (progress in percentage).
- Then, to make this a MVP, we’ll need to build a command line tool to interact with the service.
The rest of the functions are all enrichment:
- Clean up migration history from database in 30 days.
- Verify the permission before launching a migration.
- Verify no data loss.
- Is unit tested
- Is continuously deployed
- Can upload service statistics to as time-series event
- Increase the migration throughput to migrate 100TB data in 10 hours.
- Throttle the migration when destination service throttles the traffic.
- Add web interface.
If the migration involves distributed crawlers and orchestration of distributed workers copying the data, we can further move the error handling functions from the MVP into enrichment to give focus to the basic core feature itself.
The last thing to do here is to write down goals, stretch goals, and non-goals. Listing non-goals is as important as listing goals. For instance, you can list throttling as a non-goal, which implies that
- The initial design allows submitting one million migration jobs. It’s acknowledged to be a problem, but the intern shouldn’t bother to handle this case.
- If service B throttles the traffic and throws exception in RPC, let it throw; the intern shouldn’t bother to handle throttling exception.
The more non-goals are listed, the more focus the intern will get.
Setting Milestones
The last thing to do as an intern manager is to break down goals into high level milestones, and space out these milestones in 8 weeks. Now we can call this project a well scoped project.
It sounds like “waterfall model?” Yes. The internship is so short, the project is relatively small, and the importantly the requirement doesn’t change so often that the simple waterfall model works just fine.
The intern can follow the project plan easily now, also the project stretch goals can give the intern enough room to show their initiatives. In the coding phase, the code reviewers and the intern should feel safe to ignore some error handlings because these errors are supposed to be ignored in MVP. Now we’re ready to host an intern.
Planning a project is hard. If the project is customer facing, it’s likely to have product manager or program managers in your team involved to help out the initial planning stage, but you still need to properly estimate how much work an entry level programmer can do. It is hard. It takes time to be a good at it.
Variables
Giving leeway during time estimation is important here. During planning I usually give more thought to the following:
- The programming language. Not a surprise! When the project was using golang, my intern easily picked up the language in 3 days, whereas in C++, the language semantics still hunted the intern in the last week of the internship. Interns saying they know C++ might just mean they know C++89, and have never used any modern C++ features, not even smart pointers. Let alone some complicated constructs such as future/promise or coroutine. You should watch closely on the project milestones in this case, and prepare to drop one or more features in favor of code quality.
- Personality. If the intern is not vocal and the project requires a lot of initiatives to interact with cross functional teams, you need extra buffer to lead the intern in the first a couple of weeks for all sorts of discussion and meetings.
Managing the Project
We’ve had a project set up. How to keep the project on track? The Mythical Man-Month has a perfect summary on how projects get delayed:
How does a project get to be a year late?... One day at a time.
The intern manager should put a lot of efforts into planning. Make onboarding tasks high quality, set up concrete milestones, collect second or third opinions on your project time estimation, etc. Here are a few notes that might help your planning.
- Make onboarding tasks tutorial-like, and make them high quality. Onboarding tasks are equally important as the project tasks as its quality decides how fast the intern can be productive. Onboarding tasks should be covering project background, ways to collaborate and communicate with the team. What I usually do is to create two “tutorial tasks” for the first week: one task to help them familiarize code review process and the company’s code base, and one task to prepare the intern for working on multiple changesets at the same time.
- Leave one week buffer for every one month’s work. This not only reduces stress for you and the intern, but also allows the intern fulfill their curiosity of other technical stacks used in the company. Remember the purpose why we host internship at the first place? This is a great opportunity to see the intern’s initiatives, and also give the intern some time to fulfill their curiosity about the job. A lot of interns join the company’s summer Hackathon, and they are really excited to see other ongoing projects in the company.
- Set up at least four milestones, and prepare to change milestones. Each milestone serves a checkpoint on the project progress. The checkpoints are for both you and the intern. You should space out the milestone every two or three weeks so that you can identify blockers in a timely manner. You should change the milestones when necessary to reduce stress for the intern. For example, I usually set the first milestone on the second week after the intern has learned the project background on the first week. It sounds too soon for getting any useful work done but it has helped me identify whether the intern needs more tasks for onboarding them to the project. When I learned the intern didn’t write modern C++ in the first week, I added more smaller tasks to help the intern ease into C++ code base.
In terms of the day-to-day execution as an intern manager, I have observed a few useful managing behaviors:
- Align expectation early. We all know the importance of aligning expectation when we join a new working environment, but interns are usually unaware of the importance. Share your expectation with your intern early and proactively, and hear out what their expectation is for this internship.
- Continuously give constructive feedback. Talk to the intern in 1:1 about what they can improve on their productivity, quality of work, and communication.
Set up weekly 1:1 and schedule the 1:1 on Monday morning instead of Friday afternoon. I have seen good improvement on project progress when managers switch the 1:1 from Friday to Monday. I am guessing the reasons are:
- When a meeting is on Monday, it’s more likely to go through next steps than reviewing what has been done. The Monday meeting helps set fresh goals for the week.
- When interns are blocked, they may decide to wait for a couple of days on the problem before reaching out to others. The Friday meeting tends working on blockers, and because the half-an-hour 1:1 meeting is followed by two-day weekend, those blockers are not addressed immediately, which leads to weak momentum on the project.
If the internship is a fully remote program, hold an office hour at least once a week for the intern to ask questions.
It requires a lot of hard work to act as an intern manager, but it’s a great opportunity to exercise your skills for project management and to get a taste of the management role. Good luck!