This may be the most important proposition revealed by history: "At the time, no one knew what was coming."
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.).
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.
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.
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...
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!
The third installment of the OpenMusicMedia’s New York gathering met a week ago with two guests of honor: The Hype Machine’s Anthony Volodkin and The Echo Nest’s Brian Whitman. Billed as a debate about human versus machine-driven recommendation engines, it quickly devolved into a friendly conversation about all the ways that each speaker’s platform complemented the other’s.
There were a wide variety of questions and stories to come out of the audience and presenters that night, but one of the most memorable was Whitman’s anecdote about Lady Gaga’s connection to The Beatles in EchoNest’s data store. (I should reiterate Whitman’s statement that Echo Nest does not provide actual recommendations but simply aggregates data and provides it to partners for them to act on it as they please.)
According to Whitman, the Echo Nest received an inquiry one morning from one of its partners because their Lady Gaga page was starting to show an extremely strong relationship with The Beatles. Then they started receiving even more calls as all of their partners started waking up and noticing the same changes in the relationship data. The Beatles are already an extremely hard problem for music recommendations so the connection isn’t unbelievable, but the overnight nature of its appearance?
A brief investigation revealed that Lady Gaga had been interviewed the previous day and made a comparison between herself and John Lennon – although Whitman didn’t specify I’m assuming it was her comment about fearing a “John Lennon-style death.” The web’s unnaturally healthy gossip blog ecosystem went into overdrive and the comments were recycled ad infinitum. Relational mappings were strengthened, and music consumers around the web found themselves presented with the unlikely pairing of Paparazzi and Hello Goodbye.
What if the machine was just a step ahead of its builders though? Watching these videos, I think both Gaga and The Beatles look pretty into their costumes. Maybe if The Echo Nest starts taking into account visual analysis of live performances they can find a few more such data points that will tie these two back together again?
Last week the Action Arts League, in conjunction with some friends of mine, organized the second annual FIGMENT arts festival. With the exception of some late-day rain on Saturday, which I managed to avoid by leaving early, it was a beautiful day and the whole event seemed to go off amazingly well.
Groovehoops provided hoola hoops for the dance "floor", Kostume Kult gave out costumes to kids, and there were sculptures and active installations all over the island. My only real regret? I failed to hit the mini-golf course. Maybe next year.
Full set of pictures here.
Came across this excellent piece on Elizabeth Street by Nick Walker a few weeks ago.
There's also another piece by him (I'm pretty sure) in Williamsburg on the outside of Roebling Tea Room. And in case you're wondering what his process is...