Software engineering intern candidates often ask how team placement works and how much input incoming interns have over their teams and projects. We know team placement is an important factor for many students when deciding which internship to accept. We’ve spent considerable time and thought on this process in recent years and hope to demystify the experience with this post. ¹

How are projects selected? — The process is decentralized: each would-be intern mentor comes up with a set of project ideas based on the needs of their team. These proposals are then reviewed by software developers that run the internship program.

Teams select projects that meet the following criteria:

1. The project is useful and interesting: The team must actually want the project completed: we don’t give interns throwaway projects or busywork.

2. It is designed so that the intern produces code early: We want interns to get feedback on their work as early as possible.

3. It contains multiple milestones where the code is releasable: We want interns to see some of their work in production before the end of the internship even if they don’t finish the entire project.

How is team placement determined?

A week or two before the internship starts, we set up a Zoom call between each intern and a software engineer involved in running the internship where we talk in depth about the intern’s preferences.

We’ll ask if the incoming intern has preferences about:

• The area of the firm their team works in
• The type of technical work involved in the project
• Team dynamics and working styles
• Things they don’t want to work on

As we talk through each of these questions and others, we’ll share more context about the kinds of work being done on various teams. This gives the interns an opportunity to express less concrete and more open-ended preferences. We also ask how much every preference matters to the intern. While we hope to match every preference an intern has, there are times when we have to compromise, so we use the strength of preferences to make sure we get the interns to the best possible fit for them.

Not having strong preferences about any of these things is perfectly fine. We think all of our mentors and projects are great, but giving folks the opportunity to express preferences when they have them has been a major win for us and the interns.

After the first project, we do the whole process again for the second project! By this time, the interns have a better idea about what matters most to them and what kinds of things they might be interested in working on next at Jane Street. We encourage interns to change areas for the second half to get a diverse experience even if the first team/area was a great fit.

Why don’t we just provide a list of projects and let interns pick?

Fairness: Resolving situations where many interns want the same project would be hard to do equitably.

Lack of context: Without a good understanding of our tech stack and what teams do, it might be hard to know from a short project description how well a project actually aligns with your preferences.

Team fit considerations: For many people, group dynamic and working style are much more important than the content of a project.

Logistics: We ask for projects that are relevant to the needs of the team and are something the mentors actually care about and want to get into production. This means that projects aren’t known months before the internship. If the project was something they could write down and wait six months on, it probably isn’t something they care much about getting done. In many cases, we are receiving project descriptions up until the weeks before the internship.

What have interns worked on in the past?

At the end of each summer, we share some highlights in our “What the interns have wrought” post. You can find years’ worth of past posts on our tech blog.