Develop Yourself
To change careers and land your first job as a Software Engineer, you need more than just great software development skills - you need to develop yourself.
Welcome to the podcast that helps you develop your skills, your habits, your network and more, all in hopes of becoming a thriving Software Engineer.
Develop Yourself
#260 - From Lead Engineer at MongoDB to Fashion Tech: On Hiring, Remote Teams, and Start-Up Life
Harish, former lead engineer at MongoDB and current co-founder of Flaire, takes us on a journey through his unusual career path—one that didn’t involve grinding LeetCode or chasing FAANG.
Instead, he got deep into cybersecurity, built large-scale systems, and eventually started his own company that’s redefining how small businesses use software.
We talk about:
- What it’s actually like to work on database internals and secure infrastructure
- Why most engineers shouldn’t become founders—and why he did anyway
- How to use AI for real business workflows (not just ChatGPT hacks)
- The rise of “cybersecurity as product” and how ops teams still run on spreadsheets and WhatsApp
- Why learning to code isn’t just about DSA and bootcamps—it’s about solving real problems
“A lot of tools are built for enterprises, but most businesses are duct-taping together spreadsheets. We built for them.”
“You need to understand how your workflows actually function before throwing AI at them.”
“Don’t overbuild. Build just enough to learn something, then improve.”
If you’re newer to tech and want to understand what actual engineering careers can look like—this episode will open your eyes to what’s possible.
Connect with Harish here: https://www.linkedin.com/in/scharish/
Shameless Plugs
🧑💻 Join Parsity - For career changers who want to pivot into software.
✉️ Got a question you want answered on the pod? Drop it here
Zubin's LinkedIn (ex-lawyer, former Googler, Brian-look-a-like)
Welcome to the Develop Yourself podcast, where we teach you everything you need to land your first job as a software developer by learning to develop yourself, your skills, your network and more. I'm Brian, your host Today on the Develop Yourself podcast. I'm here with co-founder also former lead engineer at MongoDB, harish, and I'm really excited to talk to you about leading engineering teams, what software developers can do to stand out in today's market and learn a little bit more about how you became lead engineer at MongoDB, everybody's favorite database. So welcome to the show.
Speaker 1:Thanks for having me Happy to dive into any of the questions you have going to wonder how did you become lead engineer or a lead engineer at MongoDB? Because, like, that is probably the most popular database choice for self-taught programmers, web developers, full stack developers. It's pretty nuts. What led you to do that? Like what? How did, yeah, how did you go from learning to code up to lead engineer at MongoDB?
Speaker 2:So first, as I talk through this journey, it's like I never wanted to be a manager. Being a lead engineer was never my ambition or a plan B. I am someone who likes solving problems, who just sees what is in front of me. So I did my master's in cybersecurity at Johns Hopkins, which was a very great experience, and while doing cybersecurity I realized I'm not interested in consultancies. Rather, I would still like building software. So I wanted to get a software engineering job, which took me to Bloomberg and I joined as a software engineer, even though I did my master's in security. But that's the first time that one of the security team called up and be like hey, we need someone who is security minded to build authentication systems, encryption systems within the company. That's what I realized that being a software engineer, big security is like a very niche field. I think now, after crypto boom and everything, people are more aware of this field where you are a software engineer building very security-focused product, and I guess 10 years back the number of people out there were very less, and that's how I joined Bloomberg.
Speaker 2:Four years later, in Bloomberg I implemented a bunch of security-related things for data centers, increasing security in general for the terminal product and two weeks around that and four years later, mongodb cloud team was formed. Like you know, mongodb database exists for like Teclis years, but Atlas is pretty new. And that's when they called me for an interview and be like hey, we don't have a security team in Atlas yet and cloud is expanding, people are starting to use Atlas more and we want to form a security team. Do you want to just come and interview? Funny thing is I straight up told them like hey, I am happy at Plumwork. I have never done lead code. Now that I'm ready for interview. But then the company was small enough. They were like it's fine, just come. We understand, you haven't done lead code. We want to ask the typical lead code questions. Okay, very cool.
Speaker 2:I went to 12-6 hours of interview with 5-6 people, but most of them were asking similar questions around like hey, now that we are in cloud, how do you improve security for each cluster that gets deployed? How would you scale that? Because Bloomberg is very different. Because it's on internal systems, you have more control, whereas when it comes to cloud, you are deploying in three different cloud providers. There are hundreds of users that come and use it, so the scale varies. The consumer-facing part of security also comes into play. I had fun just brainstorming, discussing things, and at the end of the interview they were like, if you join us, this is what you're going to implement. And yeah, that's what led me to MongoDB. Basically, I loved the interview. I know that they showed me a problem that I am excited about.
Speaker 2:I had a great brainstorming session with the whole team.
Speaker 1:And you avoided lead code.
Speaker 2:That's awesome. No, I don't lead code.
Speaker 1:That makes a lot of sense. I mean one. I think that most things are negotiable, and also, if you see somebody with a skill set, that you obviously need in a pretty niche field, that's interesting, though, because cybersecurity has become super hot, right Like, I feel like that's become one of the most hot professions. A lot of people are thinking they want to enter into it. I don't know much about it at all, but my opinion is that you probably need to have a lot of foundational knowledge, and I'm just wondering what's your opinion on that, because I see there was a lot of boot camps and a lot of coding programs that say we'll make you a cybersecurity professional in six months, and I was always super skeptical of that, more so than the full stack developer route, because I feel like cybersecurity requires a lot more knowledge. What do you, what do you think about that? How does somebody become a cybersecurity professional?
Speaker 2:I don't have a playbook for it, okay, yeah, but it's like hands-on experience. Like example, at mongo, I have like an executive coordinator who moved to cybersecurity for project manager and that led her to read more about it and then she just moved up into more technical role from like a project coordination. So I think that's what I kind of meant Like just look at the opportunity in front of you and if you do it really well, other things will follow.
Speaker 1:I like that, yeah, kind of follow where your passion kind of leads. Because I like coding, I thought I was going to be a front-end only web developer. That was really what I liked. I'm like, oh, this is so cool. If somebody pays me to do this, that would be amazing. And then I quickly had to switch gears and learn like C, sharp and SQL and MongoDB and more traditional full stack. And now I'm doing like some data engineering, but it's fun. It's fun to see where things can take you doing like some data engineering, but it's fun. It's fun to see where things can take you. Hey, I hope you're enjoying this episode.
Speaker 1:Now you know that I own an anti bootcamp with my buddy Zubin, an ex Google software engineer. If you're interested in not just learning how to code and you know it's going to take more than three months and you're serious about making a transition into a career in software and you want to work with people that have done it before and are currently working in senior plus levels, Join me and Zubin at parsityio slash inner dash circle. You can learn all about our philosophy, how we approach learning how to code and switching careers in a much different way. If you're interested in being one of the few people that works with us this year. Go and apply at parsityio slash inner dash circle. And now back to the episode. As a co-founder now at Flare, do you do any hands-on technical stuff or are you mostly like in a leadership position?
Speaker 2:I kind of built most of the platform and I built most of the back end of the platform and I have an amazing front-end engineers who has done like a tremendous job with the front-end. That's also because it's like as a co-founder you need to do everything sales to coding. You don't have much money. Yes, we raised a pretty hefty receipt, but that's still not enough to have a bigger team and it's also very important to be hands-on at the beginning stages because you are still ideating, you are still moving fast, your products are still changing. I have been coding most of the time. I go on call and then I go for sales.
Speaker 1:What's your day like? What time do you start your day and end your day?
Speaker 2:I start the day around at 9, 9.30 because my standard time with my engineering team is at 10. And usually I break around 4.35 and then log back in at 7 because my engineering team is in India.
Speaker 2:So it kind of helps if I'm awake at night to make a little more coordination Night with my engineering team, I code Till morning, stand up, I code, and other times it's around. See, sometimes it's just pitching and okay, yeah, what things are like coming on the podcast. One of the reason is like you don't need to put your face out there yeah, it's not just sitting inside and coding, so those type of work also like takes over that, yeah, that's a big one.
Speaker 1:Like I, I have a business as well. Um, and just fully transparent, this, this podcast. We have a lot of customers and clients come from the podcast. It's really cool and plus, they know you, so it makes it easier to understand if you're going to be a good fit for that person, because then they're like oh, I know this person already. But it's different, because most software developers, as you know, we're not used to being on camera or writing or putting ourselves out there at all. How do you recommend they learn some of these skills that are needed to get into leadership, because now you're a founder, you're leading a team, you're having to be also like the face in the sales. You're having to learn a lot of skills well, outside of traditional software engineering. How did you learn these skills and how would you suggest other people learn these kinds of skills?
Speaker 2:So switching into leadership was a little more seamless for me. Like, uh, I was a security engineer at mongo db. I was the only one, so I kind of like switched around teams based on which team has better, say, like security related projects, that order I would work with it, which led me to have the breadth of knowledge within the company, within within like cloud. So when I became the lead, you come with a technical background and it's a very technical company. People look up to technical leaders, so this initial switch was very easy. And when I became the co-founder for Flare, my engineering team looks up to me, so it's not like I have to sell myself. Okay, yeah for sure. That led to the easier part of running like my engineering team. The harder part, obviously, is getting credibility with customers, putting these like face in front of like a camera. If it's just up to me, I wouldn't do that. I am someone who loves just being and like in the room, just like down coding, yeah, but you can't do that.
Speaker 2:And one of the biggest thing as founder that always happens is getting out of your comfort zone. You personally, you have to challenge yourself, otherwise you don't want to be a founder. You might want to be a founding engineer, founding product manager. So it's kind of a challenge you make. Yeah, not everyone has to be a founder. Not everyone needs to see this uncomfortable situation.
Speaker 1:Yeah, I'd actually say most people should not be founders or really most people shouldn't really even manage people. To be completely honest, I was a manager for a brief amount of time and I was kind of shocked how different it was. I'm like this is? They always say it's not a promotion, it's a job change. I'm like, yeah, whatever. And I'm like, oh, you're, they were right. Like this is a complete different job. I liked a lot of aspects of it and I was also completely unprepared for many aspects of it as well. It's it's a little easier to deal with with.
Speaker 2:like MongoDB I need to manage, whereas when you're a founder, people are reporting to you. You don't want to manage them. You want everyone to be self-sufficient. So basically, here I'm not coaching people. The founding team needs to have that. I will do things myself. I will come to you if I am stuck, if I need any questions.
Speaker 1:Okay, that leads me to a good segue here, because I have worked at a lot of startups. I'm working at one now in addition to running my own business too, and I've been the founding or one of like the few engineers on the last two companies where I've worked, and in the past as well. It's way different. Can you tell me, like, what you're looking for when you're hiring engineers at an early stage startup or just a small team?
Speaker 2:when you're hiring engineers at an early stage, startup or just a small team. Yeah, first, cultural fit is very important, because it's a small team and you are going to go through a lot of stressful days, so it's really, really important to have the cultural fit. The second part, about solving problems, is like you don't. First of all, I don't. If someone is waiting to me assigning the tickets, someone comes in and say what should I work? Yeah, right, they are not the right person for my funding team. Yeah, yeah, they need to pick work, they need to figure out what to do, and you come to me with like suggestions and solutions and not just problems.
Speaker 1:It's a really good one yeah.
Speaker 2:And in terms of technical challenges, I would say let's have fun, right? Sometimes I use this called BFF pattern. Sometimes we would do a hackathon and be like if I complete the endpoint first, I will define what the contract needs to be. And the front-end people is like if you complete it first, you define what the contract would be and I would change my code to adapt to the routing layers.
Speaker 2:So First you define what the contract would be and I would change my code to adapt to the routing layers. So sometimes it's just like being at a technical company is easy to have fun while not out solutions. And you know like playfully.
Speaker 1:I like that a lot. It's important because it can be pretty high stress, like. The reality is, your hours are variable. Some days I've worked like just a few hours and some days I've worked like 12 or 14 hours and I'm like that's kind of how it works.
Speaker 2:And within my engineering team we don't have like the whole holiday policy or like when someone works hard and doesn't. It's also really important that, unfortunately, there is no work-life balance or like the border of the company, so we all know each other's life.
Speaker 2:When someone has something happening at home and someone needs to take care of their family, it's an unwritten rule that other people will pick up the slack and we won't bother them and it just takes an ounce right Like one person has goals, one person comes. The balance is out at the end of the year, but it's really important that's what I meant by cultural fit that like people are more open, like I have this issue I need to take care of my dad, I need to take care of the kid it's fine. If you're not open about it, then it becomes harder to plan, then you are stressed stressed with like a lot of tasks, whereas when you're open about it, I wouldn't assign you a task.
Speaker 1:I wouldn't ask you to do something Exactly. I like I love that style, like that's important, especially at smaller startups. It's like it's important. I didn't take this seriously enough actually, but what you said is what I've seen at really good startups, where people know each other and I know that can be more difficult in a remote first environment.
Speaker 1:But like getting to know each other is like a little bit about their personal lives because you're working so closely that it is kind of important and you want to avoid, like a bus factor where that term where if you know, if somebody got hit by a bus tomorrow would your company still be able to keep going God forbid. But you know, if somebody got sick or whatever, could you still keep going and can other people jump in. And it's important to trust each other, have that high level of trust, not just technically but like personally, like hey, can I trust you're going to get this thing done and can I trust that you're going to help me out or tell me if I'm having a terrible idea or moving the company in. That's really important. Which leads me to the remote thing, because doing this remote adds a layer of complexity. I'm curious how do you manage a remote team and create a culture of trust and also people feel autonomous and can do things and yeah how have you approached remote work?
Speaker 2:Fortunately, a lot of things I learned from MongoDB because I was a manager during pandemic. That means there was a lot of leadership training around, like how to manage a remote team. Yep, some things are simple, right. I always have a launch chat that I post my own like weekend pictures or if I am going out, because that kind of brings like the human element to it rather than like, well, you are my manager.
Speaker 1:Yeah, yeah.
Speaker 2:Kind of like the first thing and everyone follows right. Once you see the people at the top post their life, other people will post. So you get to one of them would be like, hey, this is what my kid did this weekend. And then naturally like breaks a barrier, icebreaker happens and people get the cultural part of it. In terms of technical part of how do we collaborate, like I said at the time, just make it a little more fun. Who gets it first, who runs first, who comes up with the most interesting solution?
Speaker 2:So you just challenge, but make it fun.
Speaker 1:Yeah, the human aspect is something we don't think about enough. I feel like I feel like there's too many companies where it's just like you're remote but there's no like real cohesion or there's no sense of like unity. I remember when I first started working remotely, I was terrible at it and one of the things I was really bad at was communication and I didn't understand the differences in communication between being in person and being online, which meant I got used to just coming in the office and people would see me and they'd see what I'm doing and that'd be it right, and then online. That's really a terrible idea. You can quickly just disappear into the void. What are some mistakes that you see people making who work remote and what do you? What is your like opinion on communication as a remote worker?
Speaker 2:so the first thing I noticed, especially with my team, is that I have a stand up at 10 am and my team, or engineering team, is especially in india. It's like 10 pm for them and I would see that like at 2 pm my time, because I we talk about tasks, what to do next at their night time. They won't go to bed. They would be like up late working on it and I have to literally ping them and be like no, go to bed Because your kid is going to wake you up at 6 am and then you are not going to be productive the next day.
Speaker 1:How much has your platform grown?
Speaker 2:It has. We have built a lot of features and it has evolved a lot. We run around like $60 million worth of fashion business out of the platform. Wow, no, our revenue is not $60 million, oh yeah, but still, but still.
Speaker 1:That's impressive. I mean the fact people will trust you with that much money. That's impressive.
Speaker 2:Yes, some of them are like well-known brands. Like when I onboard some brands, I used to talk to my friends and they're like, oh, we used to buy from this brand. I'm not a fashion person, I never knew those brands, but my friends would be like, yeah, we know this brand, we buy from here.
Speaker 1:That's so if you're so, if you're not a fashion person. I find this interesting to a lot of founders I've met. They've picked a problem that they might not be familiar with, an industry they might not be familiar with, but they realize they have the technological skill, the technology to fix a problem. What led you to the fashion world? I think you spoke a little bit about that. But was this like a well-thought-out thing where you're like oh, I see a problem, I see something that's ripe for opportunity and I'm going to do it? Or did you?
Speaker 2:kind of fall into it. You see a problem and you see what is out there and then you ask yourself is that a place where I can add value, I can bring in your solution? That's better than what is out there and that would need you there and that also helps you do product planning well right? For example, in this space I felt very closely with shopify because if I ask myself, would I build something better than shopify or an e-commerce platform? Absolutely no, yeah. But then I 100% believe that our ERP is better than other SMB ERPs out there. Is our ERP better than NetSuite? No, but the NetSuite is like catering to 100 million plus revenue. Yeah, we are catering to like 30 to 100 million revenue brands. So for this segment, when I look around, there is no better solution and for the specific niche problem.
Speaker 2:So that's what led to this so that I pointed to what she said is like can I build a better erp? If you make a big, blanket statement, I probably would say I don't know and I do not think which one does well. Can I build a better Shopify? Absolutely no. So why do I pick it? Because that resolves on the intersection of people and customers who is not served very well, and that's why we can bring in the innovation.
Speaker 1:Oh man, yeah, that's a good one that you found like a market and this, and also it's pretty smart because there's such an explosion, I feel like, of smaller brands. Now, too, people like to buy from smaller brands, and these in small. You said like around 30 million, which is still pretty massive, but yeah, I feel like there's there's especially the younger generation, I feel like they're stopping to shop at major major stores and going towards like more niche brands, and you seem like you might be in a really good position to take advantage of this shift that's going on in general Before we take off. I got to ask you this because I know people are thinking this. Everybody asks all this all the time. Of course, you got to talk about AI, and I'm sure people are thinking wait, you're hiring engineers. Why don't you just use AI for everything?
Speaker 2:why don't you just use AI for everything? I use a lot of AI and AI is obviously making my own thought process and even the product, how I think about this product, very different. I couldn't have built Flare to like five, six years back because you need to build and not to be an ERP, and AI definitely enable you to build faster and I truly believe AI is that augment every workflow we do, even for our customers. For example, from manufacturing you get like this huge list of I am producing XL blue t-shirt, 10. I am producing XL red t-shirt, pen yell and if you just multiply by color size, each item is going to be like hundreds of items.
Speaker 2:Hire, like an upvote person who manually goes through that pdf, enters it in excel sheet. Just use bp and AI makes it like instant and and they just verify that okay is. The result from AI matches the PDF, and so I do believe there are so many places that AI is going to make you more efficient and even to use AI efficiently. In the code I have seen that only people who understand basic system design are able to use AI more efficiently. So I don't want to take over the job, but I truly believe that AI To make yourself more efficient. You need to understand how to use it efficiently and effectively.
Speaker 1:I like that take. That's a nice take. I hear too many people with the take of either yeah, it's going to take over everything or no, it's useless, and I'm like it's a great tool. It's a really, really useful tool and it unlocks some significant efficiency that I've found personally and it's interesting because I think we're all learning in real time how to use it correctly. But the use case you just gave is one of the perfect ones, like summarizing large amounts of data and verifying things like yeah, these really tedious tasks. Like hey, summarize every whatever. Sometimes I'll have a spreadsheet full of information. I'm like just summarize this for me, just so I can have an idea of where I can begin looking. But with code it can be dangerous because, you're right, if you don't have some basic system design or kind of coding principles that you know, you can just generate lots of kind of working code that eventually just falls apart once you try to add more stuff to it.
Speaker 2:Some of the biggest use case I have done is like I am coming from a very technical background and I'm selling to a totally non-technical people. I from MongoDB, very technical background, and I'm selling to a totally non-technical people. I used to feed AA and be like hey, is this store technical? If it's so technical, how do I make it? Make these explanations in a non-technical way? So, before going for a sales call, I practice with AA and AA gives a feedback on these are the terms you can use to make it non-technical. Yeah, Kasha is a new industry. I don't understand the nuances of what a landed cost means. I ask AA, give me references and links to that. I can learn. It doesn't juggle, it's my knife easy.
Speaker 1:Oh yeah, yeah, I love it for that kind of thing. It helps me write my emails. If I'm trying to write something technical and put it in a public channel with non-technical people, I use it for the same thing. I'm like, hey, does this make sense? How can I explain this with an analogy? Can you give me an analogy that that that describes this relationship I'm trying to talk about? Yeah, that's a. That's a super good one. That's one that uh, again, people don't talk about enough. It's always like how can I write more code? I? There's plenty of other things it can do too. Where can people find you online? Are you online? Are you like talking online or what I'm?
Speaker 2:active in LinkedIn. Usually, when people reach out to LinkedIn in LinkedIn, I usually reply back.
Speaker 1:Awesome, okay, very cool, and if they want to learn more about Flare, they can go to your website. I assume, right? F-l-a-i-r-e Flare and you're located in New York.
Speaker 2:Excuse me, flaresoftwarecom. Flaresoftwarecom yes.
Speaker 1:Okay, awesome. Well, thank you so much for being on the show today. Really appreciate you taking the time and had a great conversation with you. Thanks for having me. That'll do it for today's episode of the Develop Yourself podcast. If you're serious about switching careers and becoming a software developer and building complex software and want to work directly with me and my team, go to parsityio, and if you want more information, feel free to schedule a chat by just clicking the link in the show notes. See you next week.
