All about Machine Learning

In our third episode of Breaking 404, we caught up with Srivatsan Ramanujam, Director of Software Engineering: Machine Learning, Salesforce to discuss everything about Machine Learning and the best practices for ML engineers to excel in their careers.

Subscribe: Spotify | iTunes | Stitcher | SoundCloud | TuneIn

Alfred: Hello everyone and welcome to the third episode of Breaking 404 by HackerEarth, a podcast for all engineering enthusiasts, professionals, and leaders to learn from top influencers in the engineering and technology industry. This is your host Alfred and today I have with me none other than Srivatsan Ramanujam, the Director of Software Engineering, Machine Learning at Salesforce. Welcome, Srivatsan!

Vatsan: Thanks for having me, Alfred.

Alfred: Maybe for the benefit of everyone listening, you could start off by giving a quick introduction about yourself and maybe giving a glimpse of how your professional journey has been so far. 

Vatsan: Absolutely. So I started out of my undergrad, working in India for a couple of years. Initially I was working for a company that was into mainframes, building software for insurance clients, and that was not my passion. So I switched jobs and started looking at a startup, which was into building bioinformatics tool kits for computational drug discovery. And I guess that’s where I learned that I was passionate about Data Science and Machine Learning while building some algorithms to help this company out and the product that they were building. And I figured that I needed a little bit more theoretical grounding and understanding of Data Science and Machine Learning. So that inspired me to apply for grad school, and that got me to the United States. I went to grad school in Austin and specialized in Computer Science, for the most part, it was on Machine Learning and Data Science. And a couple of internships like, you know, I interned at IBM, Alberta research. Again, focus on Data Science and Machine Learning. And then when I graduated, I started my job at Salesforce. At the time I was a software engineer. I was building. parts of the reporting and dashboarding infrastructure of Salesforce. Wasn’t doing much Data Science because at that time the company was still in its infancy as far as Data Science and Machine Learning were concerned. So, I switched jobs again and I worked at Sony Mobile for about a year and a half. Was building Android applications, which incorporated features from natural language processing and Machine Learning to enhance the experience of Sony Mobile customers. Following Sony, I spent a good four years at a company called Pivotal where I was part of the Data Science team, leading engagements for our customers to demonstrate the value of a big data processing infrastructure and how Data Science can help customers tap into the value that they have for, you know, the vast amounts of data that they had access to. That was a good four years spent at Pivotal that I got a good breadth of Data Science exposure because we were working on Data Science problems and multiple industries. And eventually when I was looking for a new opportunity, Salesforce popped up. It was a company that I had worked at before. So this time I was boomeranging back. So I spent an initial two years in the customer success part of the organization, building internal-facing Data Science and Machine Learning products to help drive our revenue, minimize attrition problems in that space. And then two years later, I switched to the engineering side of the organization where I currently lead team-building marketing automation solutions, bringing Data Science and Machine Learning to solve these problems for our customers. So that’s a quick summary of my journey, I guess. 

Alfred: That’s great. That’s good to know. And it must be great to start your career at Salesforce and then after all, after building up a lot of experience in between boomerang back there as well. So that must’ve been a good experience for you as well. 

Vatsan: Yeah, I mean, it was a great company that I left, and coming back was a no brainer. And by the time I came back, there were tons of new products focused on Data Science and Machine Learning, so it couldn’t have been an easier decision for me. 

Alfred: Just out of curiosity, and this is, this is a fun question that I usually ask a lot of people I speak with, do you, do you remember the first line of code that you ever wrote.

Vatsan: The first line of code was something silly in basic programming. I guess I was in middle school at that time. At that time we didn’t really know what a computer was capable of. So typically it involves printing your name and then having a GoTo statement so that it keeps printing it endlessly, which excited me quite a bit. So was something that’s silly. 

Alfred: Great. Awesome. Okay, so let’s talk a little bit about Data Science, right? So I mean, it is a domain that’s seeing a lot of interest lately, but there’s a lot of people who come to me and ask me this one particular question, right? When do you realize that you know, you have an inclination towards Data Science? So, I mean, I want to put this question back to you. Like when did you really realize you had an inclination towards ML and AI and when did you decide that you want to have a career in this field? 

Vatsan: That’s an interesting question. So since, you know, I went to college more than 15 years ago. My undergrad program at that time didn’t have any focus on Data Science. You know, I hadn’t heard the word Machine Learning at that time. And I, like I was mentioning in my introduction about my career journey, I stumbled on Data Science and Machine Learning in my second job out of college where I was working for this bioinformatics startup in India, doing computational drug discovery. So I was hired to help write Data Science algorithms for the product that the company was building. And that’s when I figured that this is something that I greatly enjoyed. You know, I enjoyed exploring these data sets. I enjoyed debugging these algorithms, helping scale them, bringing in some randomized algorithms to help improve the performance of some of these routines. That got me excited and I figured that I needed to learn a lot more about the theory behind Data Science, and get stronger in the fundamentals. And that’s what inspired me to go and specialize in Data Science and brought me to grad school. And all my internships and all my jobs that I’ve held since was because of that initial exposure that I got to Data Science, where someone took a chance and offered me this position that I didn’t have any background to start with, but I learned things on the job. So that’s my story. 

Alfred: That’s great. I had a quick question on the back of my head as well. So what’s really the difference between an ML engineer and a Data Scientist? I mean, I see these terms being used interchangeably a lot of times out there, and I’ve always had this confusion in the back of my mind is, okay, what’s the difference? I’d like to hear that from you. So does it differ in terms of responsibilities in terms of the role itself, or does this definition in itself vary from person to person and from company to company?

Vatsan: Absolutely. So this is a question that a lot of prospective candidates also have in their minds, and so do junior hires. I guess partly the industry is also to be blamed for this confusion because what is called as Data Science has been changing over the last couple of years. So I think the current definition across many companies for an ML engineer is someone who builds end to end pipelines that involve Data Science and Machine Learning. So an ML engineer typically has a solid software engineering background and the math background to understand linear algebra, optimization, so on, and so forth. But they own the end to end pipelines. Now the term Data Scientist is where there’s a little bit more confusing because there are, I guess, a spectrum of roles that use the same title called Data Scientists. You know if you at Gartner, they classify three different kinds of analysis that you could do. So one is descriptive analysis and then there is predictive analysis. And then finally there is prescriptive analysis. So the traditional descriptive analysis typically fell under the role of a data analyst. And typically anything that has predictive, you know, more forward-looking was the role of a Data Scientist. And prescriptive was typically between a Data Scientist or a research scientist and a Machine Learning engineer or a researcher. So I would say a Data Scientist has dabbled with data quite a lot. Now, whether they do that for making predictions to guide the function of a business, or if they’re doing it as, you know, as an analysis, as a postmortem of something that happened at a business. Those are two distinctions that you could make for people who are called Data Scientists. But in reality, they could be running experiments or they could be doing predictive modeling. 

Alfred: Got it. And I think that should definitely clear the confusion for a lot of people who are listening right now, including myself, because I’ve been faced with the situation that people have actually asked me the difference, and I’ve never had an answer to that. Okay. So one other thing is, since Machine Learning usually involves a lot of user data, I mean a lot of user data to train itself security is certainly an issue. And so is privacy. Right. So how do you handle the privacy of data that are being used to train these models in the first place?

Vatsan: Yeah, absolutely. So for Salesforce, you know, we have several published values of the company, and the number one value that we often highlight to our customers is trust because we take trust very seriously. You know, we’ve been in the whole cloud software business for more than 20 years. And since our very beginning, we have paid attention to multi-tenancy. So we have tons of customers who are businesses. They in turn have their own customers, who are our users of the software that we provide for our customers. So it is highly important for us to make sure that we are not accidentally mixing data from one business with another. So we take a lot of care in maintaining security. There are a lot of formal processes that we have in place to ensure that the data is strictly locked down. There’s no possibility of mixing data from one client to another. Uh, it doesn’t mean that it couldn’t happen by accident, but when these things happen, we have like extensive postmortem to understand the root cause and we put in place stronger measures to ensure that this does not happen again. Likewise, we cannot access customer data, unless there is an absolute need for that. So, for example, let’s say a customer opens up an investigation. There are strong audit firms auditing systems in place, which decides access is only granted for them. You know, the minimal set of data sources that you need to solve that investigation and only for a limited amount of time. So everything is, you know, locked down. Likewise, there are so many other systems in place to ensure GDPR compliance. Let’s say a customer disables our feature, we are required to legally purge that data within a certain timeframe. Now, when we start working on building a Data Science product, we typically work with pilot customers and you know, we have a whole legal system in place as well where the customer accepts to provide access to that data for some period of time, but we can build this product, show it to them, and gather their feedback. In that scenario we do get access to customer data to build some Machine Learning models. But again, these are all kept in secure environments with the proper authorization. And so on. And in any case, you know, we can’t touch publicly the PII data basically. So those are also accounted for. And then finally, there are scenarios where we are trying to build a Data Science product, we could leverage our own data. You know, Salesforce also runs on Salesforce internally we call this as ORG 62. So there are scenarios where we could use our own data to build some initial models before we try to tailor it to our customer’s needs. So all of these ensure that we are upholding our number one value, which is trust. 

Alfred: Great. Yeah, that’s, that’s certainly interesting. So, well. You work for Salesforce, which I mean, a company that’s heavily driven by data and statistics. So how do you go about understanding the sort of mistakes that an algorithm makes? 

Vatsan: That’s an interesting question. So I guess we have to first talk about or think about the kinds of mistakes and categorize them. So when I think of algorithms making mistakes, it could either stem from mistakes in ETL pipelines. You know, you’re perhaps not getting the input correct. It could be mistakes in the learning algorithm itself, you know, classic overfitting and underfitting kinds of problems or it could be the changing nature of customers’ business, you know, distributional shifts and the data, or as, as it is called in the Machine Learning world, Concept Drift. So identifying which of these three kinds of mistakes is the root cause for your problem is one place to start with. So in my team and broadly in Salesforce, we have a variety of tools to, you know, cater to Data Scientists, dev-ops engineers, and product managers. So for Data Scientists, these tools help us understand the health of our customer data. It also helps us understand trends in customer data over time. Now, these are essentially the signals that go into your model. So the first thing we would look for is that any unexplained variation in the signals that feed into a model. The second thing we might look for is, is that any unexplained change in the outcome variable that we’ve modeled, you know, whether it’s you know, let’s say you’re talking about the conversion of leads or you’re talking about any attrition models that you’re building. We also look into any other unexplained variations and the outcome variables of interest and to do this, we have a variety of tools. Typically some sort of Jupiter notebooks that are run per tenant. Every time we try to train a model, we also have notebooks that are used explicitly for debugging, where for a specific customer scenario, you can, totally do a postpartum on all the signals that go into the model. Understand how the model fits as well as look at, you know, the outcome variables of interest. And we also have dedicated teams to look into some of this. So, you know, we have an AI trust team as we call them. So they are constantly monitoring the performance of our models across all of our tenants. So they are, I would say, the first line of defense when they notice that something is off before a Data Scientist gets involved in doing these postmortems. An often overlooked area of mistakes and algorithms is also related to the biases that an algorithm inherently learns and biases come because of the kinds of data that an algorithm is trained on. So we also have specialized, you know, ethics and AI teams inside of Salesforce where we make sure that the algorithm is not biased and discriminating against underrepresented groups. So all of these in some sense help us understand what are the mistakes an algorithm is making and fix those for our customers. 

Alfred:  Got it. Understood. Well, there’s a lot of information, research being conducted today in the field of Machine Learning. How do you remain updated? How do you keep yourself updated with all the latest trends and what’s going on in the world of ML and Data Science today without being lost in this massive pool of information we have out there? 

Vatsan: Yeah. Too much information is one of the first world problems of our times, I guess. So at Salesforce, we have a lot of internal forums where engineers and Data Scientists and researchers are constantly presenting their work. So that’s one forum where I try to attend as many of those as possible too. To be aware of what’s happening internally, first within the company. And then secondly, I follow a lot of people a lot smarter than I am on Twitter. So that helps me stay abreast of all the changes that are happening, all the advancements that are happening in, you know, whether it’s Machine Learning statistics or software engineering for that matter. So that has helped. I have also recently become a fan of Data Science podcasts. And not just Breaking 404, but, um, when I go out for a run, I listen to econ talk and podcasts by data skeptic and others. So there are a variety of, uh, these channels where you can learn about data signs, Machine Learning tools, and software engineering in general, uh, from experts in the industry. So it’s a good use of time, not, not just running, but also learning something. In addition to these, I also browse through articles on medium. Um, I read some code repositories on your tub. The GitHub feed is pretty useful in that respect. I follow a lot of smart people, and when they start at a repository, I go and check it out as well. So that gives me another means of keeping on top of the advancements. And before COVID I used to attend a lot of technology conferences as well with an emphasis on Machine Learning and data. Unfortunately, a lot of them are now virtual, but it still is an opportunity for us to stay on top of the advancements in this field, even though we may not have the benefit of personal interactions with other attendees when you do attend them in person.

Alfred: One of the things that I really used to enjoy doing a lot is to attend a lot of events myself, and now everything’s gone remote. It just doesn’t give you the same feel anymore. It just doesn’t give you that same feeling when you don’t get to see people and talk to them. Everything is in 2D and not in 3D, as they say.

Vatsan: Absolutely. 

Alfred: So that said, are there any lot of virtual ML and Data Science related events happening of late?

Vatsan: It seems like a lot of the conferences that were canceled have moved to virtual, and I recently learned that the Spark summit is virtual and it’s also being made free. PyCon was canceled and I think they were also trying to go virtual. And, um, yeah, there, there are a ton of these virtual conferences. You know, I saw something about ICLR being virtual, so on and so forth. So it’s, it’s in some sense made it accessible and in some ways to people who didn’t make it earlier. You know, I’ve often seen on Twitter that, uh, people from some countries were not able to get visas for conferences that happen in the US or in Canada. But now that these things are virtual, it’s opened up for everyone. So in some sense, COVID is like an equalizer in a weird way. So, I would say that’s in some sense a positive, you know, if everyone has access to these conferences no matter which corner of the world they are from. And that’s, that’s all great. 

Alfred: Great. Got it. So, how do you see the tech landscape changing over the next few years? And is there something that you’re doing specifically to prepare your engineering team to counter some of those changes that you foresee that’s going to happen over the next few years?

Vatsan: Well. I guess for those of us who are in the Data Science and Machine Learning space, a question that often gets asked is, will innovations and Machine Learning tools such as Auto ML things of that nature, make Data Scientists or ML engineers redundant? And that, that’s a question that people keep asking us. And I think personally, I don’t believe so. I, you know, I would look at Analogs in software engineering, for instance. So if you look at the last two, three decades of advancements and software engineering tools, it hasn’t really made software engineers redundant. If anything, it has helped software engineers specialize such that, you know, routine boring tasks are automated away. So now you focus on more interesting and challenging problems. So likewise, I see advancements and Machine Learning tools and algorithms essentially helping Data Scientists and ML engineers focus on more specialized problems. You know, while Auto ML and advancements of that nature could help generate features automatically, I still think that is value and feature engineering, especially when data is sparse. Domain knowledge, again, is really helpful, especially again in scenarios where data is not plentiful and specialized domains at least. And I also believe that, um, the emphasis going forward, at least in the B2B space, will be more heavily on model explainability. The reason I say that is because all of our customers if you think of them, are businesses. So it’s a person looking at a company that’s consuming the predictions and insights from our models. Ultimately, we can only be successful if we equip that person to do that job well, which means we have to earn their trust by showing that our predictions are intuitive and I think you’ll see a lot more emphasis and disregard in B2B companies where Data Science and Machine Learning models are making inroads. So I expect to see a lot more emphasis on model explainability in the years ahead. I also think that there’ll be more emphasis and scrutiny on the security aspect of it. So a lot of us use open-source tools and technologies extensively. You know, we have pipelines pulling data from GitHub and other sources and building our packages. So any vulnerability that could be injected into these packages could lead to disastrous consequences. So we should. Leverage and invest more in tools that can scan all of these, and I think that’s going to be an area of focus going forward. As engineers, we will continue to leverage any advancements and architectures, algorithms, or libraries to speed the delivery of our Data Science innovations to our customers and also make it more intuitive. So that’s basically what we are investing our time and effort in to prepare for the future.

Alfred: Great. That sounds awesome. So Vatsan you did mention a while ago that, you know, trust is always, a top priority of any product that you build out at Salesforce. Right. So how do you maintain this balance of technical stability as in how you minimize debt while still being able to deliver high-quality code?

Vatsan: Yes. I guess the question is more around how do you continue to deliver innovative features while also minimizing your technical debt by having a stable product? So I would say that’s a trade-off that is important for all engineering managers to think about. As we build customer-facing Machine Learning and AI products, trust undoubtedly takes proceedings for us. So there are a lot of gates that are in place that ensure that we cannot ship a substandard product. You know, we try to achieve the highest standards of, you know, code coverage, test coverage and we have a ton of automation casts and we, we, you know, follow all the standard deployment practices, like Canary, having a staging environment, so on and so forth. As far as balancing trust with innovation, the way we do it, at least I and my team and many other teams in Salesforce are, you know, we, we follow agile and scrum methodology. So every time we do planning for the next release. We story point all of the things that we want to do, and when we take on user stories for any given to lease, we make sure that 40% of our time is allocated to those items that are related to trust and security and stability of the product. And it’s only the remaining time is assigned for net new feature development, which means that any given point in time, engineers in our team are stabilizing our product, perhaps, you know, addressing a backlog of bugs, adding more tests, increasing code coverage, so on and so forth, while also working on net new features. And I think that has served us well. It makes sure that you know, engineers are also looking at interesting products while our customers, you can rest assured that what they are working with is of the highest quality so their business can, um, you know, function uninterrupted. So that’s worked well for us.

Alfred: Great. That sounds good. Just a little bit of a fun question in between. So while you’re busy building your awesome ML products, what kind of music do you listen to? 

Vatsan: I listen to everything from classical to modern. And for me, lyrics are important. I think the lyrics adorn music. So I listen to music that has good lyrics associated with it.

Alfred: Got it. Do you think listening to music has a direct impact on productivity, or at least on the ability to code. I’ve heard a lot of engineers come back to me saying they need to listen to music else they can’t really code well. Is there any truth to that as does that apply to you or your team? What are your thoughts on that? 

Vatsan: You know, I think it’s a personal preference. I have seen people who are always, you know, have their headsets on and they’re listening to loud music while they code. I think that for me, it depends on what’s the kind of thing that I’m doing. You know, sometimes, uh, the music is not a distraction. Sometimes, you know, something even as good as white noise, like you know of a coffee shop helps you be super productive. So it depends on what you’re doing. You know, there are times when you might need a moment of quiet as you’re thinking through something. But once you figured it all out and you’re in execution mode, then I think music, you know, increases your energy. So both have worked for me. It depends on the person, I suppose. 

Alfred: So how big is your team at the moment at Salesforce? 

Vatsan: Yeah. So we have a team of about eight engineers so far that I work with. 

Alfred: So you definitely are going to be hiring ML engineers and Data Scientists in the near future as well. So with respect to that, what do you think has been the most challenging part of any assessment or interview, especially with respect to tech interviews that you have done in the past? 

Vatsan: Yeah, I would say from, the perspective of a candidate, um, we are looking for how they respond to solving a problem that they haven’t encountered before or something that is very dissimilar to something they’ve encountered before. Because I think skills can be learned. You know, your choice of programming language or modeling framework or, or the libraries that you’ve used. Those are things that you can learn. Um, and those are also constantly evolving, right? So we are looking for that innate ability to tackle novel problems. So that is a skill that is essential. And how soon can people pick up new things? That’s also critical for functioning in a company like Salesforce. So the emphasis is less on specific programming languages or frameworks. More on learnability/teachability as well as critical thinking I guess. 

Alfred: So when you say there’s a lot of emphasis on critical thinking, learnability and teachability, et cetera. Is there an objective way for you to analyze that, or is it something that’s still a little subjective? 

Vatsan: Yeah, so typically what we do is, you know, when I at least interview candidates, I look into their projects that they may have listed on their resume, and I might try to, who’s it in a different flavor to see if they are able to respond to that. And I also pose problems that we’ve encountered in the past within the company and would see how they would tackle it. And oftentimes you can understand if a candidate has seen a problem before or not. And when you do get a feeling that, you know, they may have encountered such a problem before. You’re trying to change the flavor of the problem and see how they respond to that situation. So that gives us an indirect measure of how well they’ll be able to adapt to new scenarios. While also making sure that they remain grounded to the key objective, which is helping solve a problem for our customers. So the solution should also be practical. Not necessarily, you know, the most advanced algorithm that you could throw for a given problem. You should also keep in mind that the solution that you provide should account for any constraints in terms of time or budget. So that is also something we look for. 

Alfred: Got it. That sounds good. So Vatsan given the current scenario around COVID-19, where working from home is now the new normal and practically every company out there has asked their employees to work remotely, what do you think is the biggest problem or challenge in managing remote teams and especially remote engineering teams? 

Vatsan: Yeah, so these are unprecedented times, unfortunately, and I think this might be the new normal, at least through the end of this year. We’ll see. I would say for us, the biggest challenge has been maintaining a healthy balance between work and life. I guess because all of us are working from home these days, we could very easily get up from our bed, log onto a computer, spend hours together in front of a computer, working away, and neglect our health, our family, and so on. So it is important for us to maintain that separation that we used to have and we used to go to an office. The ability to leave work after you leave the office and focus on personal health and family when you’re at home. So that’s important. Um. I would also say that since we are all remote, it is important for us to over-communicate. You know, we have tons of channels, you know, whether it’s Slack or Google Hangouts or WhatsApp or a variety of these tools. It is important that we over-communicate, especially in times such as this, where we are missing those in-person interactions. And often I think, um, you know, when you are at least in an office physically you have your hallway conversations, you have your bankers during lunch, or whether you’re grabbing coffee with your team. All of those social events are missing and in the current scenario. So it is important for us to still try to maintain some of that virtually, of course. So in my team, for instance, we try to get on a Zoom or a Hangout call once a week or once in two weeks, purely to have those social interactions and you know, those lunchtime banters, so we do that. We also periodically check in with members of the team to make sure that things are going on all right. Especially for those who have little ones at home. Um, you know, with the daycares and schools, it was all closed. It’s harder for them to cope with this and because they have to care for a little one in addition to taking care of their work. So it’s important for us to keep that in mind and, uh, give people time, um, and understand that in some such, in some scenarios, the productivity is not going to be as it was when people were physically in an office. Um, as far as what can Data Science do in the current situation, I would say, um, you know, as a Data Scientist, as an ML engineer and manager, for me it’s more about learning what others have been doing in this space. You know, I read a lot of published articles by epidemiologists and biologists, and, you know, statisticians for that matter about this outbreak and you know, projections about this outbreak, which are used to guide public health policy. For instance I am a fan of this website RT.Live by the Instagram co-founders. That helps you track the RT, which is, you know, the likelihood of one person and how many persons are they going to infect at Timestamp T. This sort of tells you if the virus is going to die out, and if so, how soon? On a state by state basis. So I think there’s plenty of interesting things to read, but I personally think that as Data Scientists, we should also be a little bit cautious and that we shouldn’t try to get ahead of ourselves by making bold predictions and claims without domain expertise. There are people who’ve been dedicating their lives to research such as this, you know, epidemiology and virology. So it is important for us to be careful in not getting ahead of ourselves because we could in the process, uh, cause more damage than gain. So, you know, there’s been a recent trend of published research which has drawn a lot of criticism because of weak Data Science or weak epidemiology, and that just leads to more misinformation. So I think in our thirst to satisfy our curiosity, we should also be mindful of not contributing to the spread of misinformation. So as Data Scientists, experiment all you will and use this as an opportunity to study and learn about this one particular outbreak through all published data sources, but be cautious and not get ahead of ourselves and make bold predictions and claims. So that’s, that’s my thought. 

Alfred: That’s great. And thanks for that message to the rest of the ML and Data Science community out there, because I’m sure a lot of people are looking at solutions, but whatever you said is something that I guess everyone should have at the back of their heads while doing this as well. So just one last question. So what would your number one tip be to any engineering manager, VP engineering, Director of Engineering out there for being the best at what they do? What’s your success mantra as well?

Vatsan: I wouldn’t presume to know, um, or have advice for people far more experienced than I am. But generally speaking, I would say it is important for, engineering managers and leaders to be genuine, and also to be approachable. So I, for instance, never miss an opportunity to have a hallway conversation or a lunchtime banter with my team. And I believe that I know being accessible and approachable to your team is also important, which helps build strong relationships with them. And these strong relationships are often not just built on work-related conversations, but also how well you connect with your team on a personal level. So I’ve learned that from my superiors and it has served me well as well. So I would say that’s my general message.

Alfred: And if you hadn’t chosen engineering, what alternate profession would you have excelled at? 

Vatsan: My wife is gonna not like this, but if I was not an engineer, I would have probably been a National Park Ranger. Perhaps somewhere in Yosemite or Denali National Park, because I love being outdoors. I love hiking, backpacking, and mountaineering, and I see myself being in that role, if not for engineering.

Alfred: That’s interesting. Honestly, this is probably the first time I’ve heard that somebody actually wants to be a Park Ranger. That’s awesome to hear.

Vatsan: I think it’s the best profession that there can. In some sense, I’m also jealous that, you know, some of them get to stay in these beautiful parks throughout the year and get to enjoy nature and enjoy the world and its pristine state while the rest of us are breathing polluted air. And, you know, keeping ourselves busy in our two-hour-long commute to work and back. So, um, I think it’s a no brainer, if not for engineering, that that would have been my life’s calling. 

Alfred: You know what, when you put it that way, yeah, you’re right. I mean, it always has a room with a view, right? You get to stay in, you get to stay in the midst of beauty, the midst of nature. I think it’s a little, a lot of fun things in between as well. So I guess I just didn’t see it that way. Alright. Uh, just one last thing before we wrap up. So use started off with BASIC as you mentioned, right? And then you move to C, C++ and then you went back to the likes of COBOL, IBM360 and then you came back to Python. So in that meandering journey between learning multiple languages or from the ancient ones, or the new ones, you would have probably like in a, picked up a few favorites, so as to speak along the way. So what is your favorite programming language that you like to code in?

Vatsan: I think that’s a no brainer for me. It is Python. I discovered Python almost 14 years ago when I was working for this bioinformatic startup in India. It just opened up a whole world for me. You know it’s a language that comes with batteries included. And you know, there’s this funny XKCD comic, which talks about how this person discovers Python and he could import anti-gravity and now he’s flying. That’s exactly how I felt when I discovered Python. Uh, it’s, it’s really great for rapid prototyping. The kinds of libraries that are in Python are unparalleled. And as a Data Scientist, as an, as a Machine Learning engineer, it makes you super productive. So I think that was an easy choice for me. 

Alfred: That sounds good, Vatsan. That’s it for my side. Thank you so much for taking the time out to join us for our podcast. It’s just an absolute pleasure. 

Vatsan: It’s my pleasure absolutely, Alfred, and glad to have shared my journey with the HackerEarth community. 

Alfred: I’m sure the community is going to learn a lot from this particular podcast as well. I just have to say, once again, thank you so much for joining us.

This brings us to the end of today’s episode of Breaking 404. Stay tuned for more such awesome enlightening episodes. Don’t forget to subscribe to our channel ‘Breaking 404 by HackerEarth’ on Itunes, Spotify, Google Podcasts, SoundCloud and TuneIn. This is Alfred, your host signing off until next time. Thank you so much everyone!

About Srivatsan Ramanujam

Srivatsan Ramanujam is a Director of Software Engineering at Salesforce where he currently leads engineering for machine learning products in Salesforce Einstein. Previously at Salesforce, Srivatsan led the Customer Intelligence data science team, solving problems in customer growth, retention, and platform adoption. Prior to Salesforce he led data science projects for customers in multiple industry verticals at Pivotal (VMWare) and was a lead engineer for NLP products at Sony Mobile and ML products at Sony PlayStation. Srivatsan earned a Masters in Computer Science from the University of Texas at Austin.

Follow Srivatsan
Website: https://vatsan.github.io/
Twitter: @being_bayesian