How Three College Friends Became MongoDB Coworkers
Siya Raj Purohit, Chaitanya Varanasi, and Sohail Shaikh first met while attending the University of Texas at Austin (UT Austin) as undergraduate students. Five years after graduating, they found themselves brought together again — this time by MongoDB. I recently sat down with Siya, Chai, and Sohail to talk about this friendship that has been sustained through divergent career paths and continues to grow alongside their roles at MongoDB. Jackie Denner: Tell us about your story leading up to MongoDB. How did the three of you meet and begin to grow your careers? Siya Raj Purohit: I studied electrical and computer engineering at UT Austin from 2010 to 2013. Although Chai, Sohail, and I weren’t in the same year, we became friends from hanging out and working through the rigorous engineering curriculum in the same study lounge. Outside of the engineering building, Austin’s tech scene was exploding; some of my favorite memories with Chai and Sohail are going to tech events together. We met Stephen Wolfram (from WolframAlpha), briefly hung out with Mark Cuban, and crashed many SXSW tech events. Since graduating from college, I’ve lived in four states and worked across startups and venture capital firms. At MongoDB, I help provide founders with the resources they need to push the tech industry forward. Chaitanya (Chai) Varanasi: I am an electrical and computer engineering major from UT Austin, class of 2015 (Hook ‘Em!). Electrical and computer engineering is a fairly small cohort of students who all share a building and sit in the same hall for introductory classes. It is always said that the hottest fires forge the strongest metal. In our situation, we all had to go through grueling labs and coding assignments that would keep us up all night and unite us toward a common goal of passing that class. What started as collaboration on class materials very quickly transitioned into late-night frozen yogurt hangouts, playing Catan, and discovering Austin together. Sohail and I used to travel across the country for various hackathons, which was how we started our careers in software engineering. One of my favorite memories is of Siya taking us to the meetup of a lifetime at the Capital Factory, a startup incubator in Austin; we even got a picture with Stephen Wolfram! After graduating, I joined a large financial institution in Dallas as a software engineer, and then I began my presales journey in the performance space. After realizing the potential of data and understanding the value companies gain from data insights, I joined MongoDB. Sohail Shaikh: My journey in tech began when I was 12 years old and built my first computer. Since then, I have always been fascinated with new technologies and learning more about them. I was a math major at UT Austin, class of 2015. I actually can’t remember the first time I met Siya or Chai, because it seems as if I have known them forever, and I felt an immediate bond with both of them from the start. I have vivid memories of our times at UT together: attending hackathons, collaborating on ideas, and spending a lot of time talking about the future and how we could bring change. In the five-and-a-half years since graduating, I have worked in Palo Alto and Dallas — at a startup, at AppDynamics, and now at MongoDB. I’m excited to be reunited with Chai and Siya; we are all very passionate about making a positive impact in this world, and we are all doing that today at MongoDB! JD: What is your role at MongoDB? SRP: I’m helping the next generation of developers to build great companies. There is so much great talent coming out of universities and startup accelerator programs, and MongoDB for Startups works with developers to ensure they have the right products and services to transform their ideas into innovative companies. More than 1,500 companies have #BuiltWithMongoDB so far — and we’re super excited to continue growing the ecosystem. CV: I am a Senior Solutions Architect. My day-to-day job consists of being a technical partner to our rock-star sales team and performing proof of concepts with our customers to continually grow our MongoDB presence. SS: I am a Solutions Architect at MongoDB for the South Central region. My day-to-day job is working with customers in the presales organization and showcasing why MongoDB is so amazing. JD: How did you maintain your friendship after college? SRP: After college, I lost touch with Chai and Sohail for a couple of years. I moved to Silicon Valley, and although we periodically caught up through mutual friends, we didn’t really reconnect until we all joined MongoDB. I joined a few weeks before Chai (mostly to be part of his welcoming crew) and was ecstatic when Sohail told us he was joining MongoDB too. Now, we have a private Slack channel (named after one of our favorite Bollywood films) where we talk about our jobs and lives and also share cute memes and gifs. CV: Sohail and I both lived in Dallas and worked on the same team at a previous company. We have done multiple trips together and spent way too many nights eating sushi and Whataburger! Siya and I lost touch for a little because of the distance, but we were able to make up for lost time after joining MongoDB. SS: I am horrible at maintaining relationships, but Chai and Siya keep me in check (it’s just the type of people they truly are). I would meet Chai once a year on a group trip, and one day I called him to learn more about his new role at AppDynamics; he didn’t hesitate to refer me in. Next thing I knew, I was working with him on his team. Two-and-a-half years later, Chai decided to move to MongoDB, and I couldn’t resist. After working with Chai, I am now convinced I talk to him more than his wife does. Siya and I reconnected during the pandemic through a socially distanced meetup at a park while I was visiting San Francisco. Now that we both work for MongoDB, our friendship has picked up right where we left off. JD: All three of you joined MongoDB during the COVID-19 pandemic. How was the remote onboarding experience? SRP: Honestly, I was sort of nervous about joining remotely. I had left a company where I had really strong relationships with my coworkers, and it was daunting to imagine building new connections while being entirely remote. During my interview process, I asked for advice on how to best onboard. I was recommended the book The First 90 Days , which provided a great framework and onboarding roadmap. The MongoDB onboarding week itself was awesome — I met many people across the company, joined a few employee affinity groups (MongoDB Women is my favorite!), and learned about the lives of my coworkers beyond work — I even virtually met some of their babies and pets! I’m really excited to spend time with coworkers in person once it’s safer to do so. CV: I had a phenomenal experience with onboarding. Everyone at MongoDB has been nothing short of helpful. This was the first time in my life that I got to meet an entire executive team in a small group setting within the first month of joining the company. Each MongoDB executive hosts a coffee chat once a quarter, which is a great way to get to know them more personally. That kind of exposure is unparalleled, and it truly showed me how a great culture was supported from both bottom up and top down. SS: Onboarding at MongoDB is the best I have ever seen! Training and role clarity have been phenomenal, even in a remote setting. The material is organized and easy to grasp, and I don’t feel as if I have been left to figure everything out on my own. The team is extremely helpful in answering all of my questions and helping me grow. In Sales, there is also boot camp, which is divided up into two parts for my role. Boot camp lasted for a month to avoid any Zoom fatigue (given that we are all virtual), which also gave us more time to work on our assignments and properly learn the lay of the land. JD: What are you most excited about? SRP: I am so excited about Chai moving to NYC so we can work out of the same office when it reopens. I’ve already mapped out the top 10 bubble tea shops in NYC for us to visit. CV: I am ready to explore New York with Siya and have future MongoDB lunches together. Sohail and I are ready to tackle our Sales Kickoff and have fun when we return to normal situations after the pandemic. We are all career-driven individuals, and I am excited to see how we can uplift each other as a family. SS: I am most excited to be learning about the database space and contributing to growing the business. I am also super excited to see where MongoDB goes in the future. As one of the world’s fastest-growing databases, it feels as if we are on a rocket ship. JD: What advice would you give to others who are looking for a new role? SRP: Recruiting is always hard. Find unique ways to showcase why you’re a fit for a certain role or company — passion is seen and rewarded. CV: Always keep your connections and networks alive. Keep interacting with the folks you care about. I am nothing without my work friends and my work family. MongoDB is on a rocket ship right now, and you will absolutely love working here. SS: Don’t be afraid to take a risk in your careers, and put in an application to MongoDB today! We love working with talented, hard-working folks, and the grass is truly green on this side! Interested in pursuing a career at MongoDB? We have several open roles on our teams across the globe and would love for you to build your career with us!
How Hackathons Inspire Innovation and Creativity at MongoDB
When our engineers aren’t creating the best products to help our customers bring their big ideas to life, they’re working to bring their own ideas to fruition. Launched in 2013, hackathons are a big part of MongoDB’s engineering culture, giving our teams the freedom to create, innovate, and learn. About Hackathons at MongoDB Once a year, members from our Engineering department (including Product Managers, Support Engineers, Developer Advocates, and more) spend a week working on a project of their choice. Whether it be with a team or solo, the sky’s the limit. For some, it’s about creating new features or product updates to serve our customers better. For others, it’s about building internal tools and processes to make their day-to-day easier. Some engineers even use the time to work on passion projects or focus on self-improvement via online courses and reading a backlog of technical papers. No matter the goal, the hackathon is a much-needed and appreciated week for sparking new ideas, working with different people, and building useful knowledge and skills. How It's Judged Our engineers battle it out to be named the winner in one of several categories. To be considered, participants create a project demo and submit it on the Thursday afternoon of hackathon week. From there, the demos are divided among four groups of judges consisting of three or four judges each. By Friday morning, the judges select demos (which are open to all employees for viewing) to move into the final round of judging. The Prizes For our hackathons, engineers aim to get the most votes in 10 selected categories. Some categories include: Most Likely to Be Adored by the Support Team Most Likely to Make the Company 10 Million Dollars in 2021 Most Likely to Be Deployed by Production Best (Ab)Use of Cloud/Ops Manager Best Eng/Non-Eng #BuildTogether Award The Projects Past winning projects that made their way into production include MongoDB Charts , custom JS expressions in the aggregation framework, and GraphSQL support in MongoDB Realm Sync . Out of more than 120 submitted projects, here are few that won our 2020 hackathon: Leafy Catchy Eileen Huang , a Product Designer based in MongoDB’s New York City headquarters, pulled together a team of designers and engineers to build a game users can play while waiting for their cluster to build. “We wanted to show that even when doing something technical such as managing databases, people could always benefit from having a delightful moment,” she says. “Although the game isn’t live, it was a super fun week of exploring various game design techniques and trying to create a fully fleshed-out game with a playable character, sound, game UI, and more.” Evergreen Project Visualizations David Bradford , a New York City-based Lead Engineer for the Developer Productivity team, built a tool to visualize the runtime and reliability of the test suites in MongoDB’s continuous integration system. The tool plots the averages for all the test suites against each other and allows users to click into a given test suite to see a more detailed view of a suite’s history. “The project was mostly to address a personal pain point,” David explains. “We see the effects of long-running or unreliable tests fairly frequently, but given the number of tests we run, it takes some investigation to know which improvements would have the most impact. Building a tool that can visualize the data makes it easy to find which test suites provide the most benefits from improvements. It also enables other teams and engineers to start the investigations themselves.” MongoDB Charts Social Sharing Matt Fairbrass , a Senior Software Engineer based on our Sydney team, originally wrote a proposal for MongoDB Charts Social Sharing as a Request for Comments. However, the hackathon gave him and Senior Software Engineer Hao Hu an opportunity to collaborate on a proof of concept. With the core focus on data sharing, their goal was to make it quick and easy to share individual charts with others — whether via email or by posting to one of the social networks. To do this, they added controls to the chart Embedding Dialog to make this task as simple as the single click of a button. “As the discourse of the modern world unfortunately has shown us, being able to distinguish between what is factual and what is fake is becoming increasingly more important,” Matt states. “A result, data is now more than ever the most important tool we can use to surface the unbiased and unvarnished truth in social debate. But this is only true if the data is accessible to everyone.” Charts are visual by their very nature, he continues, “so it’s somewhat ironic that the current experience of sharing a link to a publicly accessible chart on a social network is anything but visual. So, the second goal of our project was to generate rich preview images of the chart being shared dynamically, and automatically attach them to the social media post by using the Open Graph Protocol , all while respecting the security permissions of the chart as set by the author.” Matt and Hao successfully tested this by extending the existing infrastructure to run an instance of Puppeteer . The system worked so well that they were able to extend the same functionality to support dynamically generating screenshots of publicly linked shared dashboards as a stretch goal. “This project has also opened up other avenues for the MongoDB Charts team to explore for further enhancing the product, so this proof of concept has now been turned into a user story that will later be worked on by the broader team,” Matt says. Raspberry Pi Astronomical Database Bruce Lucas , a Staff Engineer based in New York City, created a project inspired by his personal hobby, which is to design and 3D-print an altazimuth telescope mount. “My goal was to leverage a queryable database of stars to write software that automatically captures images, points the scope, and tracks the moving sky by using a Raspberry Pi,” he says. “To do this, I wanted to test a theory to see if a MongoDB database with geoqueries could be used and would run on the Raspberry Pi.” Pinwheel Emily Cardner , a Campus Recruiting Manager based in New York, partnered with engineers on a project to help manage cohorts of employees. With MongoDB’s robust New Grad Program that allows interns to rotate on various teams before being permanently placed, managing the entire process had become overly tedious and complicated, and she wanted to use an app to make it easier. “Even before the hackathon, I did some research to see if a platform like this existed, but I couldn't find anything,” she explains. “I thought I could throw it out as an option to see if someone looking to join a project wanted to build an app. I knew it could be a cool project working with MongoDB’s Realm product and that there could be an appetite for UI folks, but there was one problem: I’m not technical at all! So, I recruited a few folks via Slack and generated a bit of interest from various teams. They came up with an awesome minimal viable product (MVP) after we had a few brainstorming sessions.” This project is important for a few reasons, she adds. “First, I’m now working with the Engineering Corps team that creates internal tools to turn the MVP into a real product. As it turns out, other folks at the company needed cohort management tools too, so now L&D, Education, and Sales Enablement teams are all working with us on it,” she says. “Second, I learned a lot about the engineering process through this project. It was really cool to create my own mockups and collaborate with the engineers to see how products are created. I think it will help me more when working with engineers in the future.” Emily adds that she may have influenced a new hackathon award category. “I may or may not have made up my own award and then lobbied the judges to include it,” she says. “I thought creating a #BuildTogether award would encourage more people like me who are not traditionally in Engineering to work with engineers and create cool products. The judges agreed, and we ended up winning!” Why This Matters Our engineers covet this time every year to explore, create, and tackle new problems. Hackathon week also offers an opportunity to connect and collaborate with others. Many projects have openings for additional members, allowing employees from various technical areas to partner with people they might not normally work with, establishing a stronger culture, and fostering cross-departmental relationships. Hackathons allow our engineers to work on projects that are dropped or pushed down on the priority list in favor of competing priorities. Even if the projects aren’t implemented, seeing demos and having thoughtful conversations about them helps to spin up new ideas for things to add to our product roadmap. By encouraging people to step out of the day-to-day, take a moment (or a week) to think differently, and work with other people who offer new perspectives, the hackathons not only add value to our product offerings but also help our engineers expand their skills and creativity. Interested in pursuing a career at MongoDB? We have several open roles on our teams across the globe , and would love for you to build your career with us!
Meet Kaitlin Mahar: How MongoDB’s Database Experience Team Makes It Easier for Developers to Innovate
MongoDB is committed to helping both our customers and the tech community innovate quickly. I recently sat down with Kaitlin Mahar, Lead Engineer, to learn more about the Database Experience team, how she grew her career at MongoDB, and what her team does to positively impact the open source community. Ashley Perez: What is the Database Experience team, and how does it help MongoDB customers? Kaitlin Mahar: The Database Experience team, or DBX for short, builds the programming language-specific client libraries — which we refer to as “drivers” — for MongoDB. Drivers are just as essential to using MongoDB as the database itself. Without a driver, you can't actually connect to the database from your application. Our team prioritizes building drivers that we call “idiomatic” for the programming language and ecosystem in which they’re used. A MongoDB driver should follow language best practices, “feel” like other libraries you’ve used in the same language, and integrate easily with popular frameworks in that language. This makes it easy for our customers and community to get started and ramped up on our drivers. Given that anyone using MongoDB has to use a driver too, our team works with just about every type of customer and use case. Our drivers are fully open source and completely free to use, so many of our users are language community members and not customers at all. In fact, my first introduction to MongoDB was using the community version along with the Node.js driver to build a web application for a college class. In addition to drivers, we also develop libraries to integrate MongoDB with popular frameworks and developer tools, and make contributions to the open source libraries our libraries depend upon. What’s interesting about this team is that we’re constantly innovating. We develop drivers for new and upcoming programming languages. For example, we just released new drivers for Swift and Rust last year. And we have to keep up to date on the latest trends, technologies, and best practices in our respective programming languages to incorporate into our work. We’re always learning. AP: What’s your role on the team? KM: I’m one of four Lead Engineers on the team. Each of us oversees two or three drivers; I manage the Node.js, Swift, and Rust drivers . My day-to-day is a mix of technical work and managerial work. On the technical side, I work on my own technical projects, which includes coding, writing designs, and so on. I also review the technical work of people I manage. On the management side, I work with our Product Manager and Director to decide which work our team should prioritize and decide which team member(s) should take on what work. Depending on the scope of work, I also coordinate with other departments if needed. However, I think my most important job as a manager is supporting my direct reports by enabling them to do their best work and providing them with opportunities to accomplish both short- and long-term goals so they can grow as engineers. AP: You joined MongoDB as an intern and participated in the rotation program. When selecting a full-time role, why did you choose the Database Experience team? KM: I started at MongoDB as a summer intern, and then came back as a new grad and went through the new grad rotation program, which is sort of like three more mini-internships for six weeks each. This program allowed me to learn about the range of technical problems people work on at MongoDB while trying out a variety of team cultures and work styles to see what I liked best. One of my rotations was on the DBX team. When I rotated, I worked on a major revamp of the Node.js driver’s BSON library. This was a high-impact, user-facing project that I was surprised to be entrusted with as a new grad, and I found I really enjoyed the experience. The chance to have a high level of ownership over what I worked on was motivating. Due to the structure of the department, where small teams of two to four engineers work on each language project, there is a lot of opportunity for ownership on the team, even as a new grad. At the time of the rotation program, I had discussed returning to the team with my mentor, Matt — who later became my manager — and learned there was an opportunity for me to work with him on a brand-new driver written in Swift. I was excited about the prospect of seeing how a new driver is built and learning a new language, so DBX seemed like a natural choice. The DBX team gets to think about a wide range of technical problems, ranging from API design to networking to distributed systems. The variety of areas I’d get to work in and learn about on the team was a huge factor in why I decided to pursue this. I also knew there was a lot of opportunity on the team to get involved with open source communities by attending and speaking at conferences, engaging with users, and contributing to open source libraries, all of which I was interested in doing. AP: It turns out you took the chance to work with the community and are doing interesting work. Can you share more about that? KM: I’m a member of the Swift Server Work Group (SSWG), a steering team that promotes the use of Swift for developing and deploying server applications. This is a committee composed of representatives from a few different companies, such as Amazon, Apple, and MongoDB, as well as representatives from a popular open source Swift web framework, Vapor. Our focus is guiding the development of a healthy and robust server-side Swift ecosystem. Since Swift is a fairly new language and the use of Swift on the server is even newer, it’s really exciting to be a part of. There are a lot of important foundational open source libraries being developed and conversations happening about what we want the ecosystem to look like. One set of those foundational server-side Swift libraries being developed is database drivers, such as our Swift driver for MongoDB. I originally got involved with the SSWG by pitching our driver to go through the SSWG’s incubation process. It’s an honor to be a part of the group, and so far it has been a great way to connect with people outside the company, contribute to open source, and keep up to date on the latest developments in the ecosystem. AP: That sounds like a great group that not only helps impact the community, but also allows you to grow as an engineer. How else have you grown professionally and personally at MongoDB? KM: Once I joined the DBX team full time, I started working on the Swift driver. Over the next few years, I got promoted and eventually became a Senior Engineer. My manager, Matt, gradually handed me more responsibility for the project, such as making big technical decisions, providing input on what we should work on next, presenting what work we plan to do to the CTO and VPs at quarterly planning meetings, and representing the company at Swift conferences. I also had a lot of opportunities to mentor new grads and interns, overseeing their work and developing management skills that are now very important to me as a Lead Engineer. Once I had gotten experience in both technical leadership and leading people, I was promoted to be a Lead Engineer, responsible for both the Swift and Rust drivers and the engineers who work on them. I recently took on managing the Node.js driver as well, which is one of our most popular drivers and is much older than the Rust and Swift Drivers, so it has been an interesting new challenge for me. In terms of personal growth, one of the biggest ways I’ve changed is in my willingness to admit what I don’t know and proactively ask questions, even if they seem simple. I’ve realized that being a good engineer is less about what you know exactly, and more about how you approach solving problems and finding the answers. AP: Well said. How does your team collaborate? KM: Our team was quite distributed even before the pandemic began. Whereas about half of us usually work out of the New York office, my manager is in the San Francisco Bay Area, and two of the other Lead Engineers are located in Boston and Munich. Our Product Manager is in North Carolina, and we have team members scattered around the United States and other countries as well. Effective digital collaboration is essential for getting things done, since we don’t physically sit in the same location or work the same hours. In our day-to-day, we use a number of tools to accomplish this, including Slack, GitHub, Zoom, and Google Docs. Because we’re all solving the same problems, just in different programming languages, it’s beneficial for us to share knowledge with each other, both within our individual language teams and also across the department as a whole. For language-specific projects, we use a collaborative design process, where one individual writes up a proposed design and the rest of the team reviews it and provides feedback to improve the design. In regards to cross-driver projects, the DBX team writes shared specifications for how MongoDB drivers in all languages should work. These cover everything from high-level driver APIs (e.g., CRUD) down to low-level behavior such as connection pooling. These are collaborations between individuals who work on different language teams so we can ensure the specifications will work for drivers written in any programming language. We also often need to work with the Server team. For example, if the server adds a new feature such as transactions, the drivers also need to add APIs to support using that feature. Therefore, we frequently review server scope and design documents, and vice versa. What’s cool is that many of the other MongoDB teams use our drivers. For instance, the Cloud team uses both the Go and Java drivers, Atlas Data Lake uses the Go driver, MongoDB Compass and the new MongoDB shell (mongosh) use the Node.js driver, and Realm uses the Node.js BSON library. We coordinate with those teams to add new features, make changes, and act as necessary support for their use cases. They often make contributions directly to our drivers too. AP: What skills are important for someone to be successful on this team? KM: We are highly collaborative and do a lot of technical writing for our design and specification process, so team members should be strong written and verbal communicators. Since our team’s first and foremost purpose is making it easy to use MongoDB from any programming language, it’s also important that our team members have the ability to empathize with our users. They should have the ability to make pragmatic technical decisions too. As library developers, we have to make a lot of difficult choices — such as what features to include in our APIs — and balance trade-offs such as usability and maintainability. I also mentioned ownership as being a key component of working on our team, and something that attracted me to it: engineers on our team need to be ready to own the driver and projects they work on and live out MongoDB’s core value “own what you do.” AP: After working at MongoDB for four years, why do you stay? And why would someone be excited to join the team? KM: The strong mentorship and the established new grad program was a great way to launch my career, and I’ve seen many others experience the same thing. About three-quarters of the people in my new grad class are still at the company! In general, there are so many growth opportunities here that there’s no shortage of places where you can take your career at MongoDB, and we have both individual-contributor and people-management tracks, depending on your interests. The company has a wide variety of technical topics to work on, ranging from UI design all the way down to low-level C code, so it’s hard to get bored here. Even for more seasoned technologists, the opportunity to engage with the open source community through your work allows you to become an expert or deepen your expertise in your primary language, while learning more about other programming languages. You get to understand how a distributed database and database driver operates by working on a range of problems involving API design, concurrency and parallelism, distributed systems, and performance. You’ll constantly be learning new things here. From a general perspective, I personally love the company size. It’s big enough to have a good amount of structure and rigorous technical processes, but it’s still small enough that you can make an impact and get recognized as an individual. The flexible working arrangements are great too. Even before the COVID-19 pandemic, we had flexible hours, work-from-home options, and flexible time off. The people here are great — very smart, but down to earth and open to collaboration. It makes working at MongoDB really enjoyable. Interested in pursuing a career at MongoDB? We have several open roles on our teams across the globe, and would love for you to build your career with us!
How Our Growing Curriculum Service Engineering Team Supports MongoDB University
As MongoDB’s India-based team grows, we’re looking to add new members to our Curriculum Service Engineering team in that location. Here, two former Curriculum Service Engineers (CSEs) who were recently promoted share insight into the day-to-day team operations, their experience working at MongoDB, their passion for supporting our users, and why someone would be excited to join the team. What is a Curriculum Service Engineer? CSEs manage the relationship between our MongoDB University courses and our learners. They answer all technical questions via the discussion forums and other channels. Their purpose is to interact, advocate, and act as the voice of our community. “We support our MongoDB University users (whom we call ‘learners’) as they complete the courses in the MongoDB University Learning path and take the certification exams,” says Associate Curriculum Engineer Sonali Mamgain . “We focus on the operational aspect, analyzing course health and metrics, updating the courses so users can see their feedback reflected, and creating mini-content for our users to improve their understanding of a particular concept. “CSEs are advocates for MongoDB University learners. We constantly evaluate the content from the learner’s perspective, working closely with the Curriculum Engineers that build our courses so we can best connect the dots between the course instructors and learners.” What Does a CSE’s Day-to-Day Job Look Like? CSEs support users in several ways, which requires different skills for tackling unique scenarios. The goal is to ensure learners’ success. Shubham Ranjan , Associate Product Manager, breaks down his typical day as an example. “I manage the course logistics and technical content to ensure learner-facing services are running smoothly,” he says. “This means I may need to identify, debug, and provide solutions for learners’ technical issues. I also test and call out any issues or improvements the course may require. “We work to create a better experience for our learners. This means I analyze, strategize, and implement their feedback; customize the tools they use, such as the discussion forums; develop or oversee the production of the course handouts and instructional materials; and work closely with our internal teams to develop and design course content.” What's the CSE Team Culture Like? Although our India-based team is far from our New York headquarters, MongoDB’s company culture extends to many locations around the globe. Distance doesn’t change the strong sense of community, passion, and opportunity. “The office culture at MongoDB is one of the many things I love about my job,” says Sonali. “I’m close to completing two years here, and throughout this journey, I have never felt a struggle between balancing my work and my personal life. My teammates have been very supportive, and I’m lucky to be part of a close-knit team. People here are very approachable and are always willing to help. This makes the day-to-day work easy. “There are opportunities to grow, too. The work I do at MongoDB has helped build my knowledge and skills exponentially. For example, I have learned Python and C# as part of my job. Our team has also created ‘Tech Tuesdays’ for team-level technical discussions to build our MongoDB product knowledge. This has now become a routine for our wider Curriculum team and has boosted my communication skills. “My manager has played a very important role in shaping my personal and professional skills. She’s been very open to any communications I might have and always gives us direction to stay focused and achieve success. “We also have a lot of fun! I’m part of the ‘Funky Monkey Team,’ which is a ‘fun team’ in our office that organizes festivities, parties, health workshops, nature-related activities, and more. The team consists of members from various other teams, which I enjoy because it allows me to work with diverse people and has opened me up to new perspectives and ideas.” What Are the Most Exciting Things About Being on the CSE Team? There’s no shortage of exciting opportunities for team members to make a great impact. If you’re passionate about having the freedom to jump right in and improve your work, this can be a good opportunity. “From understanding the basic courses to enabling users to take certifications, we’re constantly supporting our learners in each step of the process. In turn, we learn a lot, too,” Sonali says. “We collaborate with many individuals so we can keep improving our educational offerings. I’ve met with different subject matter experts throughout MongoDB, and every conversation has provided a valuable lesson. It gives me immense pleasure to work with my coworkers. Even working to solve technical issues for our users and customers enables me to learn through the process.” Shubham agrees. “We’re a globally distributed team, so it gives me opportunities to learn from the most talented people in the industry,” he says. “It also lets me learn a lot of new things about different cultures. Other things I like about MongoDB are the open work culture, the incredible amount of support from our managers and leadership, and a great work-life balance.” Interested in Joining the Team? Here's How to Succeed For interested candidates, Sonali and Shubham both stress that being an independent problem solver, a team player, empathetic, and a good communicator are all things that can make someone successful on this team. “You should be a self-starter; someone who is independent and takes initiative,” says Shubham. “You can work without supervision and begin projects independently. However, you should also be a team player. This is important for anyone joining our team, because we deeply value collaboration and look for people willing to share responsibilities with other team members if need be. “Being technically sound and curious are great qualities to have. You should have a good understanding of basic computer science concepts (experience in any programming language and MongoDB/SQL is preferred) and be willing to learn new things and experiment.” Lastly, Shubham says, “having empathy toward our users is incredibly important. Not everyone learns in the same way or at the same pace, and it’s important to listen carefully, have patience, and show a level of understanding.” Interested in pursuing a career at MongoDB? We have several open roles on our teams across the globe , and would love for you to build your career with us!