Integrating with Integrations and MongoDB
Almost exactly one year ago, I was deciding whether to work at MongoDB. As many senior Computer-Science students do, I applied to several companies and was faced with a difficult decision that would ultimately influence the rest of my career. One of the most salient factors in my choice was: what would I actually be working on at each company? I knew that at most companies I would be placed on a team from the start and hope that it worked out well. At MongoDB, however, I was promised the opportunity to test out any three teams I wanted and choose whichever fit best. MongoDB’s New Grad Rotation Program is a unique opportunity that, among others, swayed me to join MongoDB.
Then came the big question. Now that I’m here, which teams should I rotate through? I thought I had some ideas, and then each of the twelve teams presented, and I realized those ideas were wrong. I got new ideas and talked to my New Grad Buddy, Max. Some of those ideas were also wrong and I finally settled on a set of five teams that seemed pretty great. I ranked them, tossed them into the ether, and was handed back three names: Integrations, Server, and Server Tools. Off to integrations for me, to the land of npm and MongoDB Compass.
On Integrations I had the pleasure of working closely with Matt, Lucas, and Thomas. I say we worked closely, but geographically we were literally on opposite ends of the planet. At times we were in New York, Philadelphia, Munich, and Sydney, but somehow that didn’t stop us. Distance required carefully timed checkins and individuals waking up earlier than anyone would ever want to. But it worked. Don’t get me wrong, remote teams are difficult and sometimes things fall through the cracks. Working next to each other it’s easy to overhear conversations and provide your own insight or suggestions. Working remotely that doesn’t happen. If I didn’t ask a question or update Lucas and Thomas on my progress, I couldn’t make use of the treasure trove of knowledge in their brains. At times I did hours of work that ended up being unnecessary after I checked back in with one of them. It’s a struggle, but it will improve with time, practice, and diligence. It’s a worthwhile struggle because it’s the only way we can get the best talent in the business.
On joining the Integrations team, I was tasked with “testing Compass.” Since it was a brand new product desperate to simply reach feature-completeness, Compass at the time had about 20 tests in total. Writing tests for a brand new product is never as easy as it seems, and I quickly was developing the majority of what would become a testing framework. Authentication was the paramount feature to test. Users view authentication as a critical feature, and manual testing would never suffice to verify all the scores of configuration combinations.
In order to test authentication, I needed the ability to spin up MongoDB deployments with authentication enabled. It would be way too cumbersome for every test to include all of the code necessary to create three users with different roles using various authentication mechanisms, and why don’t we throw in SSL for fun too. So I started editing our minimalist node.js mongodb-runner module, which quickly led to pull requests to at least three other Node.JS dependencies that had their own bugs and inadequacies.
By the end of the rotation, I had written a handful of tests, a reporter for the node.js testing framework, mocha, that works with MongoDB’s Continuous Integration Platform Evergreen, the first draft of the code that actually authenticates Compass against the Node.JS driver, and I had extended the runner to work with MONGODB-CR and SCRAM-SHA-1 authentication and SSL.
The integrations team felt like a startup within a larger company. It was an incredible experience. I touched so many parts of Compass and learned an enormous amount about the entire process of shipping a product. It was stressful at times, and I know for a fact that Lucas, Thomas, and Matt each spent multiple nights up until 5AM working on various aspects of the product.
One of my biggest takeaways from the experience was that documenting your code is crucial. Code is useless without comments. Every software engineer is guilty of not commenting his or her code, especially when working on brand new products under tight deadlines. At times I had to pour over source code to understand what a single line comment would have told me. It’s important, especially when working on a team, to remember that a few minutes invested in documenting your code will save collaborators hours of confusion and frustration down the road.
I’ve enjoyed my first rotation, and I’m excited at the prospect of meeting more people across MongoDB and seeing how I enjoy working on a variety of projects.
Wondering what it’s like to work at MongoDB? Check out our careers page to learn more.
About the Author - Judah Schvimer
Judah Schvimer interned at MongoDB summer of 2014 and began full time in August 2015. He graduated from Brown University in 2015 with a degree in Math-Computer Science.