Vivek Ravisankar
HackerRank | JUNE 4
On whether tech hiring is actually fixed, what AI does to the job of being an engineer, and where the human sits when machines write most of the code.
transcript · reviewed JUNE 11, 2026
#episode 99 transcript
HackerRank | JUNE 4
On whether tech hiring is actually fixed, what AI does to the job of being an engineer, and where the human sits when machines write most of the code.
MeltPlan | JUNE 4
On why construction productivity has been falling for 50 years, what pre-construction planning has to do with everything that goes wrong on a build — and why Bessemer backed him at under a year old.
7,495 words
Dhruv Sharma: Hey there listeners, this is Stream 99 and we're chatting with Vivek of HackerRank. Vivek, welcome to the show. Thank you for hosting.
Utsav Somani: How's it going? Good to have you with us. Thanks for dialing in from SF. Why don't we introduce HackerRank to our listeners?
Vivek Ravisankar (HackerRank): Yeah, HackerRank, we started the company over a decade ago with the belief that skills matter more than pedigree. That is still our core ethos in which we run the company. So we help companies hire AI-first developers using custom coding challenges and interviews and also help prepare developers for the AI-native era. So we work with over 3,000 customers and have a community of over 30 million developers.
Utsav Somani: And how are you adapting to this AI-native world that's coming up, right? I mean people are talking about 10x engineers, 100x engineers, there are tools like Cluly and many others which help people basically become better at interviewing or doing these coding exams.
Vivek Ravisankar (HackerRank): So the second is what are you evaluating? It's no longer about code correctness, it's about AI fluency and your software engineering fundamentals matter much more, your critical thinking, judgment, when do you do the right trade-offs matter much more. And the third one is a candidate experience. How do you go from an IDE to an agentic developer environment? So historically all of, pretty much most companies ask the equal-style question, evaluate correctness and put them on an IDE. We're changing that to real tasks, evaluating on their AI fluency on an agentic developer environment. So that's what we're doing in the first part. I can talk endlessly on the second part, I can also talk endlessly in the first part as well on the integrity piece. I feel like we've seen so many cases that have done like a PhD in cheating, so I'm ready to unleash all crazy stories that we've actually seen.
Dhruv Sharma: We'll get to those stories in fact, Vivek, but before we do, you spoke of AI fluency. I'm curious what AI fluency looks like from L1 all the way through to the CD. How does it vary per experience levels?
Vivek Ravisankar (HackerRank): People are still figuring out what AI fluency means and we have done our bit in terms of codifying what AI fluency means and we'll talk about that, but I think it's a very evolving thing. And sometimes like some of the terminologies that we use are also very as selfish in the sense that, I mean, there's like this famous quote or is this a statistician in the Bay Area as a data scientist kind of a thing. It's one of those things about AI fluency. I mean, AI fluency is how effectively are you able to work with AI to accomplish the job? And the default mindset needs to be, if you're an IC, you got to think of yourself as an EM of agents. This is what I tell my company internally. It's an interesting irony. Every engineering manager is now being evaluated whether you can actually be hands-on, that you can be an IC, and every IC is now being evaluated whether you can be an engineering manager of agents. And all the things that an engineering manager does to a set of humans, which is give performance feedback. In this case, it is just updating a context MD, figuring out who to use for what tasks, figuring out how to ration tasks for different things. All the things that you've been doing to humans, now you need to do for agents. The only thing is the agents don't complain. The agents don't look for your one-on-ones and stuff, but that's the shift. And the way that we try to evaluate is we actually, we have this construct called plan, build, and review. This is the interviewing style that we're moving to, which is we give them a real world task. We ask them to plan with an AI agent, and we actually evaluate how effectively are you planning the task with an AI agent. And because that's the most critical one, because if you get your plan right, then the build piece of it can actually be done pretty easily by the AI agent. And then how effectively are you able to review the output, which is reviewing the PR or reviewing whatever the output artifact is. Those are the important aspects. The plan and review, which is sort of the bookends in the process, are the most important skills to evaluate how good of AI-influenced you are. And in terms of seniority, I guess it's right now very blurry. People are, I mean, like every anthropic change, everybody's titled a member of technical staff. So right now, it's all like very blurry in terms of seniority levels as well.
Utsav Somani: So how do juniors become seniors? Like, I mean, they have to do the grunt work to actually get to a level where they can become a senior, right? Yeah. I mean, you can't, I mean, a junior developer coming out from India, maybe getting a job in like Microsoft or Google, how does he become senior? Like how do you like hire for that?
Vivek Ravisankar (HackerRank): Yeah, it's a good question. I think there are multiple parts. One is, there is a big, I feel like there's a big dissonance between what you see on social media narrative versus what we see in the data, especially when it comes to new grad hiring. Everywhere that you see, what you see is like, oh, new grad hiring is dead. Don't study computer science. Software engineering is done. New grad hiring interviews and assessments are up 25 to 30% year-over-year on Hackerrank. Now granted, there is a little bit of a selection bias on Hackerrank, which is like, if you're hiring, only then you come to Hackerrank, but still the new grad cohort that customers are hiring is actually increasing. Now there is a catch. The kind of people that they are hiring is very different from what they used to. The skills that they are looking for is very different from what they used to. So that is the shift. And in terms of the junior and senior, here's how I would think about it. In order for you to be the 10x engineer, 100x engineer, whatever factor of 10 that you want to apply, there are two aspects that I think you need. One is you just need to be like AI native, which is the default should be about, I'm not going to touch code. I'm going to ask an AI agent to work on. And the second part of it is you need to have judgment in terms of determining how to make trade-offs, how to make the right decision. Anybody who's coming out of college is going to be extremely good at the first one. In fact, it's really funny. I had an intern who looked at the editor, the code editor that we have. Why is the center pane having this weird code? We're so used to thinking about code editor having code at the spotlight when it needs to be an agent. So what do you see in the new grad folks is they're extremely good at AI native, but you can't develop judgment overnight. I mean, like it needs to come with experience. You need to make a lot of mistakes and all of those things. And what do you find in the senior people is they have extremely good judgment because clearly they have seen many different patterns. They've worked at different companies, but sometimes you have to kill your muscle memory to say, look, you need to be AI native. I think that combination is what is going to work. In fact, I think seniors are learning a lot from AI native folks, junior people, and juniors are going to learn a lot from seniors in terms of what is judgment, how do you think about making decisions, taste, and all of those things. So that's how you become a senior developer.
Utsav Somani: Maybe one follow-up question to that. What are companies getting wrong when they say in today's day and age that they want to hire AI native engineers?
Vivek Ravisankar (HackerRank): There is a nuance in terms of how much you want to think about the AI skills versus AI fluency. What I mean by AI skills is there are a set of new skills that have come up, prompt engineering, rag, fine tuning agents, and things in those lines. Now, of course, if you're going to build your own specialized machine learning models and stuff, of course, that matters a lot. But for a very strong application developer, a knowledge of that is good enough because what you really want is how are you able to use agents to accomplish, to solve the customer's problem that is present. So I think that's probably the nuance, which is anytime that somebody actually says AI native, you go down the route of talk to me about a rag system that you've implemented, talk to me about how you find your models. That may not be applicable to all application developers. So that's probably one of the things that you would get wrong.
Dhruv Sharma: And talk to us about how the process of evaluation itself has changed, Vivek. How are you testing for fundamentals? Are interviewers still focused on seeing valid code output? I'm also curious if the process itself has gotten prolonged because the true test of AI agents and tools right now is if they can perform well on long horizon tasks.
Vivek Ravisankar (HackerRank): Yeah. I mean, technical hiring has evolved a lot. I think in the 1990s, developers used to be interviewed on these puzzle-style questions where they tested computational thinking, like how many golf balls fit in a 747 kind of a thing. And then we then graduated to sort of algorithmic-style question that was really popularized by Google where you had to read code over the phone. I mean, I remember attending an interview for Google, where I read code over the phone, hashing through the IO stream, line 16 is this, line 17 is this. But they're still not told my result, so I'm still waiting for them. It's been over a decade. And then we graduated to the same style of questions, but in a whiteboard setup. And then Hackadack kind of quote-unquote invented the online technical assessment. We also invented the way to do paired programming. And today, we're reinventing ourselves into evaluating two critical skills that I believe is going to be the necessary one in the future. Your fundamentals of software engineering and AI fluency. And the way that we're doing that is through what we call as AI-led screen and a human-led interview. So we're actually moving more and more towards an AI interviewer. We launched an AI interviewer. It's called Chakra. If you're a Naruto fan, Chakra is what like, you know, the Naruto gets the superpower. So our goal is like, we'll help you find the superpower of the candidate present. And by the way, I know I'm probably going to be doubting whatever. I really love Chakra. And what's also really fun is that people in America call it Chakra. They think of it as a Chanel. So it has like, even like a better sounding thing. So people call it as Chakra. And by the way, this AI interviewer, it's not like a dorky video. It's only audio only. We've fine- tuned it because we have some, we have decades of expertise in terms of how to interview and evaluate. So to your question on fundamentals, the key thing about fundamentals is not about whether you can write correct code or not. Because AI can actually do that. Like think about like, for a decade, for a decade plus, we've been evaluating developers on the notion of, can you convert a well- written English spec into a programming language of your choice? That's like, if I have to be overly reductionist, that's what you've been doing. And that is done. AI can actually do a better job. So what matters is, why did you choose to pick this? What would you do differently if I added this constraint? You know, those are the things that actually matter, the thought process. And that's what Chakra is able to do, which is like, okay, you wrote the code, you got it correct, like everybody gets that. Now let me actually talk to you about, like walk me through the code. What do you think is the code complexity? How would you actually change it? By the way, not all of these questions you can actually say, Claude, make no mistakes, right? Like, you know, it's not going to fly. So you do have to have critical thinking. That's how we evaluate and assess fundamentals.
Dhruv Sharma: This is reminding me of an interesting story, which is, you know, so I once saw this video of Louis Hamilton on a circuit with a driving coach, put in a Honda Civic. So when you take a Formula One driver out of the cockpit and put him in a bare bones car, that's when you can, you know, truly test fundamentals and see if you've still got it. That's a great anecdote. I'm going to steal that.
Utsav Somani: And I'm going to take a look at what happened after the test, what actually happened in that Honda Civic.
Dhruv Sharma: I saw it a really long time ago, but he got feedback. Imagine like, so no matter how good you are, you can always be better. And sometimes the way to test fundamentals is to, again, throw the training wheels off. Or, you know, if you drive automatic, sometimes you go drive stick and see, you know, if you can still measure up against the fundamentals.
Utsav Somani: So yes, but back to somebody with, I mean, more experience driving a Honda Civic might actually perform better than even Louis Hamilton on that.
Dhruv Sharma: And that's the question one has, right? Like while we're on Formula One, this topic of Formula One, if you guys are fans, I know some of you are, there's another video of Charles Leclerc driving an SF90 on YouTube, which is one of my favorite videos. But Vivek, there's another question I have for you, which is right now, if we were to say that there's this great developer migration of 2026 happening, you have 3000 customers, but many more non-customers, right? Where are the best developers migrating from and who are they migrating towards?
Vivek Ravisankar (HackerRank): So I would say from, maybe I'll have a zoomed out view, and this might be a little bit self-serving, and that's okay. I think the whole narrative of software engineering is completely wrong and incorrect, and you couldn't be more wrong on it. I have the highest respect for Dario Anthropic, we use a lot, but he's completely wrong on this. And at least from data that we're seeing, it's very, very different because engineering is actually entering into all fields. You know the hottest role in go-to-market? The hottest role in go-to-market is the power engineer. And I jokingly tell my CRO, my chief revenue officer, his name is Juan, Juan, you realize like half your team is now engineers, right? Your customer support, our customer support people now go through a technical interview because their job is not to answer tickets, but their job is to build agents that can actually answer tickets. A forward-deployed engineer is, of course, technical because you need to go ahead and implement your product in customer site. Our demand gen person is a go-to-market engineer who actually needs, who actually built a cloud orchestrator with cloud internally, integrating with all of the different systems like Apollo, Play, and all of those things, and go-to-market engineer, of course, was popularized by Play. And then we have an evaluation for our account managers to also be more technical. So now I'm thinking like engineering as a function is now just spreading across the board. In fact, I believe like maybe 100 years ago or so, the term computer was used to indicate people who are very strong at doing arithmetic. So if you said like you had 10 computers, it meant like you had 10 people like, you know, doing sort of like, you know, who are very, very good at arithmetic. So I think of the role of a developer or engineer and things in those lines, the definition will change, but overall, the volume is actually going to rise. Now, so that's probably the headline. Now to answer about like specific areas where we are starting to see, I mean, it's not something super unique. The fastest growth is India. That's what we're seeing. GCCs, which is like, you know, very well known, which when a company headquartered in America sets up an office here, it's becoming more and more critical. India is no longer viewed as a services organization. Every company that we work with, Nvidia, Amazon, Salesforce, Walmart, Adobe, they all have really big product centers, critical product pieces working in India. So I do think like India is like a very, very fast growing region. One of the things that may be an interesting insight in terms of like the shape of engineers is from a hiring perspective, the large scale services organization, I mean like TCS, Accenture, HCL are much more AI first in terms of how they think about hiring than what you would consider as like tech first and other tech forward organizations. So that's probably a little bit of an aha in terms of like, maybe that's because like you do have to tell your clients that you have AI native people because like, you know, you're staffing up a team, but they are much more progressive on that front.
Utsav Somani: And a little role-playing exercise for you, Vivek. I mean, there's a little bit of AI-induced anxiety in the world right now. So suppose I'm a founder hiring my first 10 engineers, how should I go about that process? And I'm a person who's just finished his world standard. I'm coming to the, I mean, going to college for getting new skills and getting a degree. How should I think about my next four years if I'm becoming a graduate?
Vivek Ravisankar (HackerRank): Well, the first one of the first 10 engineers, it should mostly come from your network and network of networks. People that you really trust because it is much more than the technical skills. It's the ability for you to work, trust and work well with each other. I think Patrick Collison says this, which has always been like a good mental model. You're first, you need to be very careful with your first 10 people because they are the ones who are going to interview your next hundred. So if you're not happy with the shape and the type of people in the first 10, you're going to be terribly disappointed with the next 90 people that you're going to hire. So it should almost be like you should curate the first 10 people with your own network and others. On the 12th standard one, boy, what a wonderful time to be. If you go back to college, you have the smartest, most patient tutor in the world available for like $20 a month, or like, you know, everybody is giving free coupons in India. So like, you know, you have it for free. I mean, my thought is always like do breadth first, try out as many things as possible. If you're just like entering college, you can be interested in filmmaking, can be interested in writing, you can be interested in like making a podcast. Like who knew like creating a podcast and working on that would actually be a real lucrative profession that people would, smart people would do like maybe 10 years ago. It's not, you wouldn't have imagined. So we're obviously going to get new jobs. And so the way to think about it is breadth first search and see where your natural curiosity lies and then go depth first. That would be my suggestion to anybody entering college.
Dhruv Sharma: Wise words. Do we have maybe time for one final question or so?
Utsav Somani: Yeah, I think a couple. So we should, I mean, we were having a chat with Vivek about him being the first YC company as well. So should we bring that up?
Dhruv Sharma: We should. Yes, Vivek, why don't you clear the air on which Indian origin founder was the first to attend YC?
Vivek Ravisankar (HackerRank): Yeah, I wanted to have a poster. I don't have a poster. But yeah, HackerRank was the first Indian based company to get into YC. We got into YC in 2011. We'd applied a couple of times before that. We got turned down. And 2011, we got a call. I flew. Hari, my co-founder, he couldn't get his visa because he told his salary was zero dollars, which is, by the way, the truth. But you don't want to set, you don't want to say that to the visa officer, right? Like, you know, because that guy started wondering, like, you know, are you going to be homeless in America? Like, how are you going to survive with all of that? So I had to go alone. It was a 10 minute interview. We got in. It was just life changing. And it still is. Yeah. So there's nothing to clear the air. That is a fact.
Utsav Somani: That's phenomenal. And I'm guessing the experience paid out for itself. But how did you even discover YC back in the day? Like.
Vivek Ravisankar (HackerRank): Yeah, it was mostly through Polgram Essays and Hacker News. And yeah, those were, I mean, that's how we used to Polgram Essays. And again, like my YC interview panel was Pete Polgram, Jessica, Paul Bouquet, Sam Altman, and Arch. It was, it was like, it was like Madame Tussauds in real world kind of kind of thing. And I had 10 minutes to prove that we're worth taking a bet on.
Utsav Somani: Maybe just, I mean, staring into the future for like a couple of years, what's HackerRank like in the next two years?
Vivek Ravisankar (HackerRank): I think the work that we're doing is getting even more important and critical because the question that everybody's asking right now is what human skills are going to be valuable in an AI first world? And for us to be able to define that both to companies and developers and help them connect, not even developers, but we're just like, you know, the word developer can encompass so many things because everybody is now a builder, right? So to be able to define what human skills matter and be able to empower everybody to learn and acquire those skills and help companies to hire people on those skills, I think it's probably the most valuable thing that we can do, probably right next to AI curing cancer or whatever. So very, very excited about operating this mission.
Dhruv Sharma: Vivek, can we quickly round off by saying why are skills more important than pedigree, why developers have never been the ones to let pedigree hold them back?
Vivek Ravisankar (HackerRank): Yeah, I mean, I worked at Amazon prior to this for a year and I remember interviewing a lot of people where resumes weren't always a good match in terms of how you perform in an interview. I interviewed people who were like really good on paper, completely bombed interview, didn't even know basics and vice versa. And also like there was always a constant, I don't know, prejudice whenever companies used to come to college saying, oh, you need to be above this particular GPA. I remember my co-founder Hari, who I consider as like one of the best hackers, he had a lot of ideas. His GPA wasn't really good. I'm outing all his credentials right now. And no company would actually look at him. And I remember telling, I believe it was Yahoo or I don't know which company, guys, you should probably hire this guy more than me, right, or at least interview this guy more than me. So yeah, there's probably some deep-rooted thing that, you know, skills certainly matter more than pedigree. That's how it manifested.
Utsav Somani: Awesome. Thank you so much for coming on our show. Wishing you all the best.
Vivek Ravisankar (HackerRank): All right. Thanks for inviting me.
Utsav Somani: Have a good day. All right, listeners, we're moving on to our next guest. We have Kanav from MeltPlan joining us. Kanav, welcome to the show.
Kanav Hasija (MeltPlan): Hey, what's up? That's why I'm here.
Utsav Somani: Our pleasure. And I see at MeltPlan, you're repeating an innovative playbook, which is unify a fragmented industry, organize the data and then put intelligence on top. So let's introduce MeltPlan with that thought to our listeners.
Kanav Hasija (MeltPlan): Yeah, actually, it's the opposite. It's, we are adding intelligence to a broken system, a war- fragmented system. So construction is the second biggest industry in the world, but the one that's least productive. So actually, the productivity is going down for the last four decades. It's very, it's very tough to believe how can the same labor build less houses or less office buildings now than they used to build four decades ago? And the answer lies in fragmentation of team sites. So there are like 40 skills required to build a building, architect, mechanical engineer, plumbing, expert, and so on and so forth. And then these are now becoming like, these used to be housed under three companies and now they're housed under 40 companies. So fragmentation is a big issue. And I tell, I used to joke this to my software developers that you are lucky because if you ship a buggy code, you can still fix it, but you can't ship a buggy building. It's tough to fix that. So planning and building has to be even more important and the planning there is completely broken. So we are fixing the planning layer of construction.
Utsav Somani: And everything goes over budget, everything goes over schedule. So how are your tools helping sort of bring that in? Because almost everyone building a building, house, residential, commercial, everything is just a broken process, like you rightly said, but everything goes off by such a huge margin in a, I mean, probably one of the longest standing industries of all time. So, and like you said, the second largest one also, why is that happening?
Kanav Hasija (MeltPlan): Yeah, it's the planning. So I'm in New York right now. And I have, whenever I come to New York, I love to visit the Empire State Building because that's the, that's the temple of construction. Like that's the engineering marvel. So fun fact, Empire State Building was built in 1930, in 1931. And it was built in 1931 in 19 months. It was six months in designing and 13 months in construction. Right. Guys, give me one moment. Yeah, so we're in New York right now. And, you know, Empire State was built in 19 months, soup to nuts in 1931. And it is such a remarkable feat, because even today, no one can do this. No one can build a building, a 100-story office building in 19 months, both planning and construction. And the only reason they would do that is because there was one master planner, one team that planned it all. And they took six months in planning the plan. They even planned the manufacturing of steel, not just the building. How will the steel be manufactured in the facility and be transported to the New York site, where the Empire State Building is? Even that was planned pretty well. So the answer lies in planning. And the problem in planning today is it's not one team, it's 35 teams. So a system needs to come in and say, give me all your plans. Let me match them up and tell you what's off. Or if you want to alter the plan, I can tell you how to, what, what impacts does it create to all the team members. So that's what we have.
Utsav Somani: Empire State example, I think regulations might have also changed and evolved over time. That would have added to the extra timelines as well.
Kanav Hasija (MeltPlan): True, but not like from, okay, so let me push you 85 years forward. Salesforce Tower in San Francisco was built in seven years. It's 20% shorter in height than Empire State Building. So 19 months to three years sure from regulations, but not seven years. And again, the fun fact, yes, the regulations were not that good in Empire State Building. At that time, people used to die while, while building the high-rise buildings. Fun fact again, in Empire State Building, no one died. They just had some injuries. So they were much more safer than, than all the other build outs as well.
Dhruv Sharma: This is what you're saying is so instructive kind of because the Stripe founder, Patrick Collison on his personal website has this, he has a microsite called fast, where he lists down things that, you know, came into existence in the shortest period of time. And for some reason, they're all old things, right? Like the Boeing 747 or the Eiffel Tower or the Empire State. And, and one would imagine that we've gotten to a place where we can deliver projects more quickly, but, but that is not the case. But let's unpack the fragmentation problem a little bit kind of before MelPlan arrived in the scene, was it like there were lots of different point tools being used by, you know, those 35, 40 teams. And there is an opportunity here to consolidate them into more like a platform.
Kanav Hasija (MeltPlan): Yeah, I think it's, it's a, they're all using different tools because there are different companies. So they have an option to do so. And they're also using different tools within different stages in the same company itself. So it's a double fragmentation problem, right? So that was one. The second problem is the big change of why I stepped in from healthcare to construction was I wanted to be in an industry which needs AI the most. And if you look at construction in the pre-AI world or the SaaS world, construction is full of documents and images and SaaS could not even read those documents and images. So the best the SaaS could do is fill up some forms and I'm going to help you after you fill up some forms, so the middle management, the lowest management will be forced to fill up forms. The middle management will be forced to review those forms and the top management will see dashboards. That's the SaaS world, right? I mean, that's, this describes every SaaS software builder, right? The junior ranks fill up forms, the middle ranks review forms and the top ranks review dashboards. We were asking users to do more work on the SaaS product than get any value back. The AI world is flipping that. The AI world is saying, you have documents and images? Sure, give me those. Let me make some intelligence and give some back to you, right? So that's what's changing. It's the coordination of people. It's the collaboration between them and the intelligence coming out from documents and images versus them putting a bunch of data into the software.
Utsav Somani: And how much of the problem that you're trying to solve is a data problem versus misalignment of incentives problem between the construction company, the architects and all of the, I mean, different parties involved in this situation.
Kanav Hasija (MeltPlan): Yeah, we're not necessarily solving the alignment problem on incentives because we can't. Like any tech company who is saying they can solve a lot of problems is like smoking something up. But we can indirectly do so. What I mean by that is if you make lives easier for a few stakeholders, they might absorb more risk into their portfolio. So I'll give you an example. Empire State Building, the architects were also the contractors. They were also the subcontractors. So they held everything, right? But if you see today, architect is a different company, general contractor is a different company, all the subcontractors are different companies. If you make the work of every company easy, why did this happen, by the way? Why does this fragmentation happen? As buildings became more complex, regulations became, as you said yourself, more complex, they started to super specialize to increase their margins. Risk increased, so specialization increased. If AI can reduce the risk that they consume on top of that business, they can again go back to a master builder concept. One company can still do a design and construction both.
Utsav Somani: So if you make... Who is the buyer for your services, your product?
Kanav Hasija (MeltPlan): I mean, right now we are selling to everyone, unfortunately. That's more effort on our side, but we have to sell to architects, engineers, and contractors, all the three entities. But not just that, they have to be on the same platform. So our vision and the pitch to everyone is if architect bought something from us that the architect is doing, the contractor can have visibility to it. And if the contractor bought something from us that the contractor is doing, the architect should have visibility to it for free. So we are building a cross-collaboration platform between all the three stakeholders, but our vision is hopefully down the road, we can just sell to one company. Let's see how that happens.
Dhruv Sharma: Maybe we'll ask a question from the Innovesa ears. By the way, we have a mutual friend in Anirudh Verma, who spent time with you at Innovesa, and the CTO is also an offline member, Ankit, if I'm not mistaken. Ankit Maheshwari, yes. Anirudh would always tell me that, dude, this is one company where we really think big, and I'm sure that happened over a period. So this is a very broad, open-ended question about how in the Innovesa journey, all of you co-founders came to start thinking big. It was a trillion dollar opportunity. Even the talent you guys assembled was top tier, people very often older than you, more experienced than you. You raised a whole bunch of capital, so talk to us about what the learnings from that experience were. Around thinking big, mostly.
Kanav Hasija (MeltPlan): Well, I wouldn't answer it as big or small. I would say think something categorically defining. If you're copying someone, you are dependent on them innovating. And we usually saw software coming from India for the world was becoming more of a cheaper version of a software, right? We wanted to not copy someone and price lower. We just wanted to define a new category and not just define a new category because we have to do so, define a new category because the industry needs one and solve that. So at Innovesa, we never had a copied product. We always went customer backward, thought from first principles what the customers need and kind of solve it for them. We never looked around and said, this company is doing this, so let's do that as well. So that's one big difference, I would say, of what Innovesa had compared to other players in the market. I think the second biggest thing is, and I have blogs on that on my sub stack as well, which is it's really easy to say, think from customer's point of view, think in customer's shoes, but it's a very tough thing to execute that. And the way we used to do that is we used to say, hey, okay, what drives our customers' top line and bottom line? Let's just build the whole decision on a value level tree of all the value levels that drives customers' top line and bottom line and just keep on building backwards from that. So we define protein value levels for our first wedge or category we went in and we just kept on executing on that. We just kept on adding products and features one after the other, working backwards on those protein levels. And well, if you just go customer value backwards, things happen in a good way.
Utsav Somani: How about selling to these customers? Because healthcare also is a very stubborn industry and I'm guessing construction also is very relationship driven. So you have early partners. How's the business looking right now?
Kanav Hasija (MeltPlan): Yeah, it's just been one year and four months into building it. So we started commercializing three months ago. We have reached two or six digits of ARR. We are planning to go to seven pretty soon. And it's low. Construction is slower than other industries, but we want to be the fastest in the slow race. So that's what our hope is. Selling to these people, you know, I mean, true. Yes. Yes. It's tough. No doubt. But if you are authentic and you have built something that customers really love, or love is the second part of the party. If you have something that they need, you know, then you are authentic about it. See the enterprise customers, they don't buy products. They buy trust in people. They are depending their promotion on your success, on this contract success. A VP who just came to the organization six months ago, believes in your product, believes in your company's vision, believes in you guys, is riding on it. Because if you are successful, he or she is successful and they get promoted. It's all about trust. So trust cannot be won by selling more than what you have. And trust cannot be also won by not being authentic in any way. I used to, in fact, sometimes tell my customers, if they had a problem, I used to say, I don't have a solution for that. This company does, go for it. And that used to be a bit of a pressure for them. They're like, why are you representing me to your competition? I was like, you have a problem, I have a solution for you. And they used to always call me up to ask for problems. So that's how you win the trust.
Dhruv Sharma: So coming back to MelPlan's problem space, once you've managed to improve pre-construction using AI, what do you foresee the downstream consequences of this are going to be? What gets better?
Kanav Hasija (MeltPlan): Well, one thing for sure is the cost goes down. Because less waste is, there's less waste, let's say that. So the cost goes down. Affordable housing is a big issue in the US or in the Western world. So that gets down as well. That's getting better.
Dhruv Sharma: It's one in India as well, but that's a different story.
Kanav Hasija (MeltPlan): Yeah, absolutely. I mean, India is the fastest growing construction market in the world, by the way. So it's very interesting. So one is that the waste goes down. I think the second big impact is the ROI on building things becomes bigger or better. What that means is more stuff gets built. It's like people are not entering into the build phases because they think the build phases are, as you said, 95% of projects don't happen on time or on budget. So if that stats becomes 20%, people will start to build more because there's more predictability in building. Right now, people are afraid of building because there's the predictability. So they're like, let someone else build and I will just lease that building or buy that building from them. So more building happens, less waste, the building becomes more affordable. That should be the logical impact. I think the third big impact will be prefabrication will become big. Today, prefab is not big because of planning issues. Prefab requires planning, pre-planning, because the good thing of prefab is it saves time. Sometimes cost, not always, but it saves time for sure. But the bad thing of prefab is you have to give out the plan ahead of time. You can't change it once the prefab stuff comes out.
Dhruv Sharma: And you mean both the design and also the supply order to your suppliers so that they can start ramping up production?
Kanav Hasija (MeltPlan): Yeah, I think the biggest benefit of prefab is at least in the many parts of the world. See, prefab costs the same as a ground-up mostly because there's transportation costs, there is installation costs, all that stuff. So if you put total cost all in, it's almost the same. The big impact is, let's say in, at least I can speak for you as, a permit for a hospital, like once you have the design complete, you send it out for a permit to the state to get approval. That permit takes about one and a half years. One and a half years for a state to approve that permit. Until then, you can't build anything on site. But who's stopping you to build in a factory next door? That's prefab, right? So I can prefab that stuff in the factory and then I can ship it off to the site. And I can save time. So time is a big impact and time is money. It's not the construction cost, but time is money. And if a hospital is not live for five months, they lose money. If a data center is not live for a month, they lose money.
Utsav Somani: And as a final closing question, what are some of the innovations that you're seeing in the physical AI space, in the construction industry, specifically in the US?
Kanav Hasija (MeltPlan): Yeah, there was happening all the dividers in many parts. The, what's happening really well already is the progress tracking or the construction management piece, which is, you know, drones and camera helmets. Like you have, you have cameras on people's, you know, helmets on top, or you have drones, which kind of do a site capture to figure out how much has been built or not. So, you know, depending on people to, you know, punch in data of what they build or not, you just do a virtual capture, you get that out, right? So progress tracking is happening pretty well already. There's a lot of robotic stuff happening in, in prefab as well. There's some robotic stuff happening on site, although it's pretty early innings, I would say, because unfortunately, sites need more variability. You might not have a flat land, you might not have good weather, there might be snow, there might be rain. So I will see robotics and humanoids doing good in prefab factories first before site. But we are seeing some robots that can paint a wall, that can do some, you know, paint finishes or pour concrete. That's happening already. But I will see full fledged robots cutting walls and drywalls and all that stuff pretty soon.
Utsav Somani: All right, Kanan, thank you so much for coming on our show. Wishing you all the best as you take on this mammoth task of automating this industry, or at least bringing order to the chaos in the construction world. Thank you. Yeah.
Kanav Hasija (MeltPlan): Thanks, folks. Take care. Goodbye. Bye.
Utsav Somani: All right, listeners, that's it from us. We'll see you on Monday for our stream number 100. It's a banger 2.5 hour special. We're going to tease out some of the guests that are coming and the full reveal on Sunday. So do tune in on our socials and we'll see you on Monday.