Internships @ MongoDB
This summer MongoDB, Inc., then awkwardly known as “10gen, The MongoDB Company,” played host to twenty-one engineering interns across the New York and Palo Alto offices.
As with most software companies, the summer internship program is critical for us. If the program is successful, the team gets an annual infusion of solid - albeit inexperienced - engineers to work on the core database and its ecosystem of related projects (drivers, MMS, etc.).
The Purpose
It is my understanding that college internships in the non-Computer Science (CS) section of the job market have two primary objectives:
- Give interns an opportunity to pitch themselves as future employees
- Give companies a rich source of free labor and ego boosts
In the CS job market, however, the supply of/demand for talented engineers require that these programs:
- Give interns an opportunity to pitch themselves as future employees
- Give companies an opportunity to pitch themselves as future employers
- Get real work done
To that end, the projects that MongoDB’s engineering interns work on are the opposite of rote or unglamorous.
The Structure
While doing the rounds at campus recruiting events, I typically explain our match process as a triangle. We analyze each student/project pairing on the following three axes, with the goal of finding some optimal maximum of all three:
What they want to do
Somewhat obvious. Happy engineers are good engineers, and there’s not much point in having an aspiring PhD in Distributed Systems spend a summer doing front-end web development.
What they can do
But just barely. Although we don’t want anyone to finish the summer frustrated, we do want to challenge each of them so every student returns to class having learned at least a few new things.
What we need them to do
We place a premium on working code and aim for every intern’s code to be used somewhere - whether that’s as an internal tool, integrated into one of our existing software projects, or open-sourcing the source code as a stand-alone repo.
The Match
Given this ideal scenario, rather than deciding intern projects early on, we’ve found it easiest to wait until the interview/offer/acceptance stages of the program have been completed, and we know the full roster of incoming students. At that point we match interns with projects in a process I consistently (and probably inaccurately) compare to the medical school match process.
Over the next few weeks, we get current engineers who are interested in mentoring to submit ideas. This past year, we ended up with 31 mentors across 18 projects. Given the travel-heavy nature of the drivers/evangelist team, having two or more mentors frequently makes sense.
We simultaneously collect the resumes and interview feedback for each student. Once both sets of information are organized, we exchange. The interns are sent the list of projects and mentors, while the mentors are sent a list of interns and their background material. Everyone then returns a stack ranking of their interest in each other, at which time these preferences are fed into six-ton supercomputer that applies a stable marriage algorithm and returns…
The Result
Actually that last part is a lie. Although I’d like to get fancy with this process, the truth is that our results haven’t needed any computational intervention. In 2013 we took less than 90 minutes to apply a match that gave every student a project from their top 4 (out of 18) and every mentor an intern from their top 2 (out of 21).
Might there be a more optimal solution? Sure. Matching interns with projects and mentors by hand, however, allows for some fudging based on the “fuzzier” data points like personality, broader interests, and company priorities.
So what did our 2013 interns actually produce? I don’t think that info has been collected into a single, public location yet, so I’m compiling it now for another post to be put up next week. Stay tuned!