All posts by Lillie Chilen

How to run an internship program

In a previous post, I explored how running an internship program can benefit the team (and the company) more dramatically than you might expect. Now that you’re totally bought into why interns are awesome, you’re probably wondering how you can run an effective internship program at your company.

How our internships work

Whether the internship is three, four, or six months long, an Omada engineering internship follows the same general format: join the team and pair with everyone, do a solo project for a spell, and then rejoin the team. We’ve had 13 engineering interns so far, and each came to Omada with a different amount of experience with our stack. Having them start with the team gives us a chance to share our practices with them, and dump a heap of knowledge on their heads while they learn their way around the codebase. The solo project then gives them a chance to integrate some of that knowledge, and code review helps us and them see what they are still struggling with. When the intern’s solo is over and they triumphantly return to the team, their growth is evident.


Since interns are short-term employees, they go through an abbreviated application process — first, they complete a coding challenge that has some failing tests, then a general-purpose phone screen with questions about their technical interests and what recent code they’ve written that they are excited about, followed by a remote or in-person pairing session working on a small technical problem.

You clearly aren’t hiring an intern for their experience, so you should have a clear idea about what you are hiring them for. At Omada, we look for interns that ask a lot of good questions, display curiosity about how we ship software, and who seem to be able to pick up new concepts fairly quickly. Algorithms and white boarding sessions wouldn’t give us nearly as much insight into how the candidates actually write software, so we happily avoid them. (As we do with our full-time candidates, as well. Whiteboarding interviews are terrible and people should stop doing them.)


The biggest part of why we’re able to have an intern join the team and write production code immediately is that we do pair programming by default. Depending on the team, this can range from 40% to 90% pairing. Practicing our pairing skills with a junior developer makes us better pairs when we work with all of our teammates.

(Pair programming is where you have two keyboards, two mice, and one computer, and you take turns typing, and you work through the whole problem together. Pairing is not where you look over someone else’s shoulder when they get stuck, or whiteboarding architecture with a group of people, or working on similar code next to someone on separate computers.)

If your company does not currently have a pair programming practice, I wouldn’t recommend starting with pairing with your interns. Pairing across experience level is is a substantially different experience than pairing with an engineer more senior than you or at your level. It’s a skill not to hog the keyboard or go too fast when you’re on a roll, and properly get your pair’s buy-in for your idea when they know a lot less about the codebase than you. Sarah Mei has a great piece on precisely this problem, and you should read it!

(I do recommend you start pairing! Just with people at the same skill level, then later try to expert-mode that is junior/senior pairing.)

If you do pair, some of these things have helped us let our juniors drive more:
* Really doing TDD and ping-pong pairing it (avoiding spikes, where the junior can get lost)
* Having toys and other things for the senior to do with their hands to avoid typing
* Unplugging the senior’s keyboard!

It’s really hard not to grab the keyboard when you don’t know why the test is failing. As much as you can, resist the urge, and work through the mystery with the intern driving. You can do it!

Onboarding & Mentorship

Having regular interns keeps our onboarding processes in tip-top shape. We also make sure that the intern’s laptop is used for coding as soon as possible — usually on the first day, but definitely by the second day of their internship. When you’re pairing, it’s easy to use the machine that’s already set up, but that’s a trap! It’s important for the new person’s environment to be set up ASAP.

Interns are paired with more senior developers who act as a mentor during the internship, answering technical and non-technical questions. The intern’s mentor isn’t the only person who reviews their pull requests, but especially during the solo project, the mentor checks in regularly with the intern to make sure they’re on a reasonable path with their project. Regularly, in our case, has often meant a daily, scheduled check-in, otherwise it doesn’t happen often enough. Having time every day during the solo has helped us prevent our interns from going totally off the rails on their projects. (Of course, if they have questions during the day, they’re welcome to ask any member of the team. We haven’t yet had an issue with an intern asking too many questions.)

Solo Project

Omada engineering interns have a lot of say in what they build during their solo project. We’ve had some interns make tools that never got used (and they still learned things, which is valuable!), but we are especially excited when an intern can learn a lot while working on a project that is useful to the company. We’ve had especially good luck with having interns work directly with a product manager for their solo project, and letting them figure out what to build together.

If you’ve got an intern that really wants to work with a cool new technology that is completely unrelated to your current stack, I’d suggest gently reminding them that the value of their internship is not just in the code they write, but the process of working with your team. Trying out new tech is a great thing to do in your free time, when you don’t have the wealth of resources of a team and customers to build things for!

Code Review

Since we pair program, we don’t normally do code review via pull request. The exception to this is when any engineer is soloing, and so interns on solo projects submit pull requests that are reviewed by their mentor or another person on the team. Since the intern has already had at least a month of pairing with the team, they are usually moderately aware of our practices and style, so the feedback on each pull request isn’t starting-from-scratch education about how we write code at Omada.

If your company doesn’t pair program, you’ll probably want to start with a project that is somewhat less than business critical. It is important, though, that the intern is collaborating with other people at the company as much as any other engineer would. You’ll only reap the benefits of having interns around if they are fully integrated into your typical engineering processes and working on your actual codebase.

Hire them!

At the end of someone’s internship, if they’ve been awesome and we have an opening, we offer them a full-time position. This is an excellent way to further leverage the time investment we’ve made, but we still get a lot out of mentoring the interns that don’t end up in full-time positions.

At Omada, our interns have been fantastic teammates and many have stayed around in full-time positions. Having interns around regularly has helped us improve our communication skills, our codebases, and has really helped us increase the gender diversity on our teams.

(For more on why running an internship is incredibly valuable to the whole team, take a gander at this post.)

Internships: Good for the intern, great for the team

Hiring an intern is obviously beneficial to the intern: they get paid to learn to write better code, they get exposed to working with a team, and they get another line on their resume working toward being a supes profesh software engineer.

Less immediately obvious, though, is how great an intern can be for your team and your company. A good internship program provides an opportunity to look critically at your culture and your codebase to see where the weaknesses of both are.

(It's unfortunately easy to run an internship program without learning from it, but if you set things up properly and ask the right questions, having an intern on your team will pay dividends beyond their comparatively cheap salary.)

I've talked to a lot of people about more and less successful internships they've had or witnessed. For the less succesful ones, the saddest part is when the company didn't look at their process or their code to see what could have contributed to an unproductive internship. It's easy to say "Oh, we just hired a bad intern", but rarely is just the intern the problem.

An internship might feel like a test of a junior engineer's abilities, but it's moreso an audit of your team: how well do you communicate? How complex is your codebase? You will certainly teaching your intern things about programming, but they will show you the things that your team is totally rocking, and the things that you need to work on, both in code and in process.

Benefit #1: Code

We all have parts of our codebase that we know are a mess, that have weird old names due to quirks of history, that are fragile and no one wants to change a thing for fear of subtle bugs. But we get used to them. We have Stockholm syndrome with our codebases, and we've forgotten how silly (or terrible) things are.

We need to feel the pain of explaining to an intern why that model is named the way it is. Or asking them to hold the context of seven classes in their head to understand how this process works. (Having interns come through regularly is helpful here, because any intern will also become numb to the more painful parts of the codebase.)

Having an intern around who will look around the codebase and find patterns to follow will highlight for you which patterns you don't love any more, and remind you to fix them up at the next opportunity.

Benefit #2: Culture

Like explaining a complex bit of code, explaining how your team works and why you do the things you do will help you find gaps in your process. A team that can effectively onboard an intern is set up well to onboard any engineer, so that they can contribute meaningfully as quickly as possible. You'll also learn how good your team is at teaching (or knowledge transfer, for those who like corporate lingo better). Good teaching leads to fewer silos, which leads to higher bus numbers. Yay!

Having an intern-ready culture means your team will have an easier time retaining people who are collaborative and empathetic. At Omada, we use an internship-like program to rotate engineers through other teams. Especially when someone is learning a totally new technology, having a structured format to get started is incredibly helpful. This has the excellent benefit of allowing our teams more opportunities to learn from each other—rotating team members cross-pollinate ideas and practices from their "home" team.


Still not sure that your team is ready, or that you can spare the time?

The most common refrains I've heard from engineers that don't think they should hire an intern yet include:

  • We don’t have the time or resources to train them
  • Interns will write bad code that we’ll then have to maintain forever
  • Everyone on the team is so key to the codebase that we can’t have someone less than senior or else things would fall apart

These are reasonable concerns, but point to larger issues in your engineering organization (beyond the very-real problem that hiring an all-senior engineering team is very expensive and very hard).


If you have fewer than three mid- to senior-level engineers, maybe you should wait on hiring an intern. A team of all interns probably isn't an effective way to build a robust codebase, but a team of all seniors can tend to write more complex, clever code. Create a balanced team.

Running an internship program is absolutely an investment. You do need to take time to train people, but the ROI on your codebase and culture is worth it if you do it right. An internship program that doesn't teach you about the existing team and its code is not worth running.

Code Quality

Your company should already have structures in place that prevent crappy code from getting onto production — probably something like code review or pair programming. If you don't do either of those things, you should probably start! With your full-time engineers, not your interns.

So, when you hire an intern, put those structures to work. Give the intern actual production work, and see how good your team is at giving helpful, thoughtful feedback about the intern's code.

Not enough experience

If your team believes only senior engineers can be beneficial to your codebase, then you are going to have a hard time hiring, and probably have a myriad of other issues. People leave companies, and they take their knowledge of the code with them. Good luck!

Start with one

Being good at teaching means being good at helping all of your engineers level up, which will help them want to stick around. Teaching reinforces what you know, and highlights things you thought you knew but don’t. Being good at information sharing means that you will have fewer silos and higher bus numbers.

I hear often that startups don’t think they have the resources to support interns, but the question is: where do senior engineers start? Not as senior engineers. Providing internships helps us have more balanced teams, and hiring mid- to senior-level engineers is pretty damn difficult in the current market.

It’s likely that your first intern ever will have a worse experience than later interns. You’re going to learn how good your mid-level and senior engineers are at teaching a junior, and which parts of the codebase are really hard to explain to someone just starting their career. But please don’t let that stop you from trying.


All of the reasons above should be enough to start hiring interns. But there’s another benefit that I should mention: you can more easily increase the gender diversity of your team!

  • 16% of software engineers are women (source)
  • 18% of computer science grads are women (source)
  • 38% of bootcamp grads are women (source)

The statistics for ethnic diversity of bootcamp grads is less exciting, but you can still work on the diversity of your teams by posting internship opening in places like the jobs board ofs historically black colleges and univserities, or working with organizations like CODE2040 to hire black and latin@ fellows.

How To

Ready to start an effective internship program? Read on for how to do it.

A brief guide to facilitating retros

One of the cornerstones of our engineering process at Omada is the retro (short for retrospective). A retro is a regularly scheduled time for the team to reflect on the past week and discuss what about our processes we should change to make the next week better. Most of our teams have retros at the same time each week, toward the end of the week.

Retros at Omada started with the engineering teams, and over the years we’ve introduced other parts of the organization to their magic. From the outside, retros can seem like post-mortems or complaining sessions. So it’s been important for us to emphasize that retros are regularly occurring and process-focused. (And that post-mortems and complaining sessions can also be very valuable — they just can't replace retros.)

As new teams started having retros, we realized that we needed a guide to the basics of an Omada retro. Since the facilitator has a major impact on the pace and tenor of the retro, we focused on training more facilitators. (In some teams, the manager or team lead runs the retro every week; other teams rotate facilitators.) I made this one-page cheat sheet outlining how to effectively moderate a retro. Take a look, and maybe even print it out and take it to your next retro!

hand-drawn retro facilitation guide

Here are a few translations and notes!

  • EANABS are Equally Attractive Non-Alcoholic Beverages. We usually have a mix of beer-drinkers, whiskey-drinkers, and non-drinkers at our retros. While alcohol is a fun way to demarcate that this isn’t just a regular meeting, it’s important to make everyone on your team feel included, so if you are serving alcohol, other fun drinks should be available.
  • Learn more about the Five Whys (and why you might ask them) on this wikipedia page.
  • The timeline is assuming a 60-minute long retro and a co-located team (thus the sticky notes and the pens). If your folks are remote, tools like and Retrospectus are useful for collecting people's thoughts and reflections.
  • This is just one style of retro — there are many, many ways to run a retro!

(Here's the guide as a PDF.)

Thank you to Vincent Coste, who gave an internal presentation on our retro practices that inspired me to create this guide!