Here's what we're reading at MongoDB:
Intern Spotlight: Jason Hu
This year, MongoDB welcomed 33 university students to our intern program in Engineering, Marketing, and Education. In this series, we'll introduce you to the talented students who are helping us transform development and operations for how we run applications today. I had the chance to sit down with Jason Hu who spent the summer in our Palo Alto office working with the CAP team! Where do you go to school, what is your major, and what year are you in? I'm a rising senior at Brown University, where I study computer science. What is your role at MongoDB? I’m a software engineering intern on the CAP team. How did you find out about the internship program at MongoDB? Why did you choose to come to MongoDB? I actually started computer science a year late, so I didn’t really know about tech companies, let alone MongoDB until late in college. As I did more CS I learned from upperclassmen and recent graduates about the company, and it seemed like a cool mix of technical challenges that thought big. What’s your hometown? I actually grew up in the Silicon Valley—I’m from Los Altos, California. My friends and I would walk by Facebook when it was still a small startup in Palo Alto. Did you have previous experience using MongoDB before you arrived? If so, how are things different now that you work at MongoDB? If not, how did you learn MongoDB and how was the education process? I had no experience whatsoever. To be honest, databases had been a huge, intimidating block of computer science and software engineering that I haven’t really touched before. I figured throwing myself in the deep end would be the best way to learn, and after one week of orientation I definitely learned more than an entire semester. All the on-boarding staff and mentors were terrific—they should consider becoming professors, after they retire. Working on actual projects has also taught me loads about databases—not just how to use them, but how to think about them in the larger picture of an enterprise or business. Bike or public transportation to work? I drive, actually. One of the perks of being at home, I suppose, is having my old car. What’s a typical day (or week) for you? Well, it’s really hard to say since every week I’ve had has been so different. Some days will be very focused, where I can put on some ear-buds and crank out code. Other days will be back-to-back meetings or presentations, where I’ll be learning about MongoDB’s history or theoretical concepts about databases or road mapping my project for the next week. And I can’t forget the fun! A typical week always has a bunch of great events, from smaller game nights to larger company outings, such as to indoor skydiving, Giants games, or go-karting. The intern coordinators really out-do themselves. What do you love most about MongoDB? Definitely how much I’ve learned. I can say without exaggeration that I learned more about databases during onboarding than an entire semester of the class. But it’s more than just coding chops: Watching the ins-and-outs of a startup has been fascinating. For me, it’s easy at school to be stuck in a narrow path of problem solving—improving runtimes, cleaning code, etc.—but the challenges outside of code are usually not so neat and controlled. Hearing about the problems of marketing, finance, design, and HR has been incredibly illuminating for so much work we take for granted. What’s the most challenging aspect of your job? Adapting and learning on the fly is definitely something I need to work on more. In school, we have a general sense that a right answer exists, and what it should look like. In engineering in the real world, however, there aren’t necessarily the right answers in the back of the book. Now as an engineering intern, my main challenge isn’t finding the right answer, but rather figuring out whether a problem is feasible, what the solution looks like, and whether it’s worth my time. And this isn’t an easy process. During the course of the summer, as I learned and tested different languages and programs, my project had to change and sometimes backtrack as I adapted. What’s do you hope to accomplish while you’re here? The cool thing about Cluster Bingo was that I got the start it from scratch—decisions for structuring the code, as well as library and language decisions, were all mine. So my goal wasn’t necessarily to rush out a fully functional version. Instead I wanted to think about what are its long-term goals, and how to design it in such away that enabled the growth and continuation of the project after I leave. What’s your favorite Seamless lunch order? Definitely any sandwich from the Ace of Sandwiches. Name one secret skill you have, unrelated to work. I’m a really mean baker. Literally. Apparently I get really bossy, but my cakes also are fantastic. Where do you want to be in five years? I picked this question because, well, as a rising college senior it’s kind of on my mind a lot. The honest answer is “I don’t know,” but I can say that one way or another I know I’ll be programming. Which isn’t necessarily to say I’ll be a software engineer: The past few months, I’ve realized that I can use code within any of my interests—advocating social and economic justice, product design and user interfaces, and even my original major of biology and bioengineering. Given how much my interests and skills have changed in the past five years, it’s impossible for me to really know where I’ll be in the upcoming five. All I hope is to somehow find a way to combine some or all of my interests through coding, whether that’s through a software company, start-up, or NGO. Kindle or book? What’s your favorite book? I haven’t read anything on Kindle yet, so I’m going to have to say books. However, the moment Amazon figures out how to give Kindles that old-book smell, I might have to give it a shot. It’s really hard for me to pick a favorite book, but the one that I always find myself rereading is the graphic novel Blankets by Craig Thompson. His illustrations and paneling are gorgeously done, and he has a great ability of capturing little, human interactions in his characters. Every time I read it I find something new. Describe your perfect weekend. Wake up Saturday morning and start off with hiking or the gym. Then I like going up to a museum in San Francisco: The Academy of Sciences in Golden Gate Park never gets old. Afterward, catching up with friends over dinner, before going out for the night or hanging out at their apartments. The next morning usually entails people watching in the park, and finally settling into a book on the train ride home.
4 Common Misperceptions about MongoDB
One year ago, in the middle of the pandemic, Dev Ittycheria, the CEO of MongoDB, brought me on as Chief Technology Officer. Frankly, I thought I knew everything about databases and MongoDB. After all, I’d been in the database business for 32 years already. I’d been on MongoDB’s Board of Directors and used the products extensively. And of course I’d done my due diligence, met the leadership team, and analyzed earnings reports and product roadmaps. Even with all that knowledge, this past year as MongoDB’s CTO has taught me that many of my preconceived notions were just plain wrong. This made me wonder how many other people might also have the wrong impression about this company. And this blog is my attempt to set those perceptions straight by sharing my four major revelations of the last year. My first revelation is that MongoDB is not trying to become this generation’s relational database. For years I assumed that MongoDB basically wanted to be a better, more modern version of Oracle when it grew up. In other words, compete with the huge footprint of Oracle and other commercial RDBMSs that have been the industry archetype for so long. I was way off. The whole point of MongoDB is to leave all those forms of archaic, legacy database technology in the historical dust. This was never supposed to be an evolution, but instead a revolution. Our founders not only envisioned the world's fastest and most scalable persistent store, but also one that would be programmed and operated differently. The combination of embedded documents and structures combined with automatic high availability and almost-infinite distribution capability all add up to a fundamentally different way of working with data, building applications, and running those applications in production. Oracle and (SQL*Server, etc) still hang their hats on E.F. Codd’s 51-year old vision of rows and columns. To obtain high availability and distribution of data, you need add ons, options packages, bailing wire and duct tape. And you need a lot of database administrators. Not cheap. Even after all that, you’re still trailing the technological edge. This is how wrong I was. Our durable competitive advantages over these legacy data stores make competing with those products almost irrelevant. We instead focus on the modern needs of modern developers building modern applications. These developers need to create their own competitive advantage through language-native development, reliable deployments to production, and lightning fast iteration. And the world is noticing; just check out the falling slope of Oracle and SQL*Server and the rising slope of MongoDB on the db-engines website. Which brings me to my second revelation: MongoDB was built for developers, by developers. I always knew that MongoDB was exceedingly fast and easy to program against. One time while I was bored in a meeting (yes, it happens here as well!), I built an Atlas database, loaded it with 350MB of data, downloaded and learned our Compass data discovery tool, built-in analytics aggregation pipelines, and our Charts package, and embedded live charts in a web page. This took me all of 19 minutes, end to end. To build something like that for engineers , it just has to be built by engineers , ones that are free to focus on all the rough edges that creep into products as features are added. I was first exposed to software planning and management over 40 years ago, and my LinkedIn profile shows a pretty diverse tour around the industry. Now, one year in, I can emphatically state that engineering and product at MongoDB are both different and better than any company I’ve ever had the privilege to work at. Our executive leadership gives engineering and product broad brushstokes of goals and desired outcomes, and then we work together to come up with detailed roadmaps, updated quarterly, that meet those goals in the way we think best, with no micromanagement. And we’re not afraid of 3-5 year projects, either. For example, multi-cloud was more than three years in the making. Also unlike any other company I’ve been at, we embrace the creation and re-payment of tech debt, rather than sweeping it under the rug. We do this through giving our product and engineering teams huge amounts of context, delivered with candor and openness. And one more essential thing; we have an empowered program management team that improves processes (including killing them) as fast as we create them. In short, we paint the targets for our teams and let them decide how and when to shoot. They even design the arrows and bows. It’s true bottoms-up engineering. Our engineers feel valued and understood. And that, in turn, empowers them to develop features that make our customers feel valued and understood, like a unified query language, or real-time analytics and charting directly in the console, or multi-region/multi-cloud clusters where all the networking cruft is taken care of for you. And this brings me to my third revelation: MongoDB is built for even the most demanding mission critical applications. Fast? Yes. Easy? Of course. But mission-critical? That’s not how I saw MongoDB when I used Version 2 for a massive student data project 10 years ago. While it was the only possible datastore we could have chosen for the amount of data and the speed of ingestion and processing needed, it was pretty hard to set up and use in a 24 x 365 environment. MongoDB had gotten ahead of itself in the early 2010’s. There was a gap between our capabilities and the expectations of the market. And it was painful. Other databases had had more than 30 years to solidify their systems and operations. We’d had five. But with Version 3 we added a new storage engine, full ACID transactions, and search. We built on it with Version 4. And then again with Version 5, released this week at our .Live conference. I knew about all this progress intellectually of course when I joined, but not viscerally. I came to realize that the security, durability, availability, scalability, and operability our platform offers (of course in addition to all the features that developers love too) was ideal for architecting fast-moving enterprise applications. And I found the proof in our customer list. It reads like a Who’s Who of major global banks, retailers, and telecommunications companies, running core systems like payments, IoT applications, content management, and real-time analytics. They use our database, data lake, analytics, search, and mobile products across their entire businesses, in every major cloud, on-premises, and on their laptops. And that leads me to my fourth and final revelation. MongoDB is no longer just a database. Of course, the database is still the core. But MongoDB now provides an enterprise-class, mission-critical application data platform. A cohesive, integrated suite of offerings capable of managing modern data requirements across even the most sprawling digital estates, and scaling to meet the level of any company’s ambition, without sacrificing speed or security. Since the day I was first introduced to MongoDB’s products, I’ve had tremendous respect and admiration for the teams and their work. After all, I’m a developer, first and foremost. And it always felt like they “got” me. But had I known then what I know now, I would have jumped on this train a long time ago. In fact, I might have camped out on their doorstep with my resume in hand. And who knows? Maybe a bunch of people reading this will do just that, and have their own revelations about how fulfilling and exciting it can be to be at a great company, with a great culture, producing great products. I’ll write another letter a year from now, and let you know how it’s going then. In the meantime, please reach out to me here, or at @MarkLovesTech .