Software Misadventures - Ashwin Kumar - On learning new things by breaking them down, the secret to winning >$100k from hackathons, the art of storytelling, and much more - #15

Episode Date: October 12, 2021

Ashwin is a Startup Partnership Lead at Stripe. From web development to co-founding a YC startup, to deep learning, Ashwin has a knack for picking up new skills extremely quickly. In this episode, we chat about the methods he employed to successfully make these transitions, learnings/tips from winning 30+ hackathons in a row, and what engineers can gain from better story-telling.

Um, there's less certainty. With engineering, I love to know what I need to build and then use my engineering hat to go break it down, look up the right tutorials. Like that's the part I usually love the most about hackathons because it's so certain. This is an uncertain path. You're basically talking to people hoping to find something and it always works, but you always feel like, is it going to be a good use of my time? I don't really know what I'm going to get. It feels kind of amorphous. And for things like that, I think design thinking is something that I've kind of read about design thinking, and I've used it extensively in basically everything I do. And it's been really helpful. Welcome to the Software Misadventures podcast, where we sit down with software and DevOps

experts to hear their stories from the trenches about how software breaks in production. We are your hosts, Rannoch, Austin, and Guang. We've seen firsthand how stressful it is when something breaks in production, but it's the best opportunity to learn about a system more deeply. When most of us started in this field, we didn't really know what to expect, and wish there were more resources on how veteran engineers overcame the daunting task of debugging complex systems. In these conversations, we discuss the principles and practical tips to build resilient software, as well as advice to grow as technical leaders. Hello everyone, this is Guang. Quick update before we get started. It's been almost a year since our first episode, and it's been really rewarding talking to interesting experts on topics that

we really care about, and being able to bring those conversations to you, our listeners. As you know, and as we tell our guests in every episode, we are complete noobs at this podcasting. But as we get better and look into the second year, in addition to bringing on more experts in infrastructure engineering, we're really excited about expanding the range of conversations by talking to people who started out in engineering just like us and have over time accumulated deep expertise in a specific area in tech, whether that's becoming a bootstrapped indie hacker, starting a company, transitioning into product management,

or getting into venture capital and Android investing. Through these conversations, we hope to bring you practices and mental models that make these people really good at what they do. We will explore what different path being an engineer can lead to. And lastly, of course, stories of misadventures they've had along the way. With that, the guest of this episode is Ashwin Kumar. Ashwin is a startup partnership lead at Stripe. From web development to co-founding a YC startup to deep learning,

Ashwin has a knack for picking up new skills extremely quickly. In this episode, we chat about the methods he employed to successfully make these transitions, learnings and tips from winning 30-plus hackathons in a row, and what engineers can gain from better storytelling. I've known Ashwin for years, and it was super fun catching up with him. So please enjoy this episode with Ashwin Kumar. So Ashwin, welcome to the show, man. Hey, awesome. Happy to be here.

So Ashwin, you and i have known each other for almost three years now and we're still friends can i just say how impressed i am by how much patience you have so you know please please keep up the good work is that the uh is that the reason you invited me to the show to celebrate the fact that i survived three years didn't didn't think about it but i should really really mark it on my calendar, the three-year anniversary. Well, Guang must really like you because he doesn't say nice things to me. I digress, I digress.

Okay, so I was LinkedIn stalking you, as friends do, and you have a pretty unique background. You started out doing investment banking, and then you co-founded a YC-funded startup, and then you worked on ML at a hardware company. That's where we actually met. To now, you're leading startup partnerships at Stripe. This is a pretty exotic career path. Tell us about some of the highlights.

Yeah, I'll just kind of walk you through, and I think it's going to give you an idea of my thought process. So I studied finance, and I investment banking mostly because I didn't really know what I wanted to do. And that's I felt like the kind of safe thing to do where you get into it and there's a track and, you know, pays well and all that kind of stuff. But as most bankers, I kind of hated myself after a couple of years and really was looking for what's the next move here. And this is where i actually got into coding so i never studied cs in school and at that time in 2014 these coding boot camps were starting up right like dev boot camp and now everybody knows of them but at that time dev boot camp had just kind of started hack reactor had started and i heard about these and i was like okay maybe

this is where i want to go maybe i want to start trying to do software so i did this code academy class while i was still working at my job and i just fell in love i was like, okay, maybe this is where I want to go. Maybe I want to start trying to do software. So I did this Code Academy class while I was still working at my job. And I just fell in love. I was like addicted to it. Couldn't wait to get back home to keep doing Code Academy and kind of finish through the path. And I thought, okay, this is what I want to do. Like I'm so hooked on this thing, which happens to be a career that you can get into. And it also enables me to build my own products which has always been kind of a dream for mine so so i did this book i quit my job did this boot camp which was a huge

risk back then because you just didn't they had no it's not like lambda school now where it's kind of clear that there's outcomes right it's or maybe not i don't know about that but like it's uh it was a risk but the rest is history. Yeah. Did you, like, tell your iBanking buddies, being like, yo, check out or guess what I'm doing? Like, how did they react to... I remember telling them, like, going and quitting my job and telling my boss, like, hey, I'm going to quit so I can go do this, like, coding boot camp thing. And, you know, he was like very confused as to what was going on. Uh, but he, you know, wished me luck and probably thought I was crazy.

And I probably was a little bit, I felt myself like, what am I doing? This is such a huge risk at the time. I thought I felt it was right. Looking back, like it really wasn't that big of a risk, uh, to try this out, but you know what's interesting with investment banking, as much as people like to hate on it and finance, part of the job is doing financial modeling and using Excel. And Excel, if you think about it, has a lot of paradigms of programming in it where you really are using logic to kind of set these things up. And that was the part of the job I really loved, like creating these really fancy financial models and and practically coding actually is what you're doing in a very different use case. But but yeah, anyway, I told him like, hey, this is what I'm doing. I love doing the financial modeling. I'm going to quit and I'm going to go do this boot camp. He thought it was crazy, but, uh, but you know, I went, so I did the, I did the bootcamp, right. Uh, and then it became an engineer. I actually, it worked. I thought there was no way that you could do this nine week

program and then become a web developer. Uh, but I did. And then I got a job as a web developer for a year and got a little bit restless and felt naively that I know enough about software that I can now build my own startup. Uh, and I just quit my job and took the leap without an idea, without a co-founder, thinking that I was good enough of an engineer to pull that off. And I wasn't, but I did find a co-founder and I did come up with an idea and eventually we got into Y Combinator. But that's, that was my path into startups. Nice, nice, nice. And then what happened after that? We went through YC and I'm happy to talk about that. That was, that into startups. Nice, nice, nice. And then what happened after that? We went through YC. I'm happy to talk about that.

That was a wild experience. But we went through YC. We raised money. Ultimately, the company ended up closing down as most startups do. But I learned through that company how to do data science as a kind of ad hoc thing. We needed to do it for the product that we were building. And so afterwards, I joined Insight, where both of you have gone through,

and then I transferred that into being a machine learning engineer at Mythic, which is where I met Guang. So it was kind of a, everything, each of the steps directly was connected to something else that came right before that. And soon after that, now I've started working at Stripe because I really do love software and I really do love startups. And the job that I'm doing at Stripe

is helping startup founders and partnering with VC firms and partnering with accelerators to help startups succeed on Stripe, but in general, go faster, raise their next round and succeed. And so it's kind of a dream job. Nice, nice.

I feel like the obvious question is kind of like, how did you go about picking up new skills with each transition? Because they were all so different. But even before that, how did you get over sort of the mental block, if you will, of having to learn something completely different

that's completely out of your comfort zone how how do you think about that it's really hard i'm not someone who it comes naturally to i feel like it was i had to do it because i had to do it so it all started with learning to code during that boot camp right coding if you've never done it in school or in other capacity learning software is a very daunting thing. It's not something you can just do as a hobby. And I know a lot of people who think it is and they try and they completely give up, right?

It's, there's so many different things you have to learn in order to kind of do well at the job. And the bootcamp really helped me get that confidence. If I can learn this, right? If I can learn, I remember what was really interesting is they break things down. I remember the first time that I really had an aha moment was when I made my first, I learned how to make a get request. That was like one of the classes. Right. And I did that. And I was like, this is incredible. I can talk to the Internet now. And then the next day we made a post request.

And I don't know why, but a light bulb went off in my head like now I can create something like and I can actually write something and create something that's going to change something somewhere and that was this this uh little kernel of interest that got me just to learn the next thing like okay if I can do that why don't I do some make an application or website where I can do both you know I can where I can actually have access to both. And if I can do that, why don't I kind of level that up? And I feel like the way I learned the skills is get into that aha moment as fast as you can, and then kind of work backwards and figure out, okay, now, now that I'm excited about this thing, what are the, what are the component pieces of it and how can I level it up to the next,

the next level? So that, that's kind of been my mo the whole time interesting like so it was would it be fair to say it was more about the curriculum like for me for insight part of it was actually other people pushing me to do stuff where i thought having a cohort of other people like-minded also trying to get through like the similar struggles like for me that was huge um i think just the moral support and then knowing that we're all sort of suffering through the same thing but i guess your point though like having the structure to be able to i guess tackle those things sort of um stepwise so that you're not just getting stuck i guess well so the big thing i learned from that boot camp which i've actually now used going forward to learn anything is first of all learning how to learn, is the thing that a lot of us can use some

help with. And if you can learn the structure of how you learn something new, that's the meta learning. That's the skill that really helps. And that means you can learn anything, right? And so the confidence that I learned from the coding bootcamp was for me, what really helps me is if I want to learn something, do it like dive into something like drown in it. Right. And so in this example, what we did in the boot camp was we just copy and pasted a crud app. Like we just kind of the assignment, the very first day assignment was go to Stack Overflow, go to some tutorials and just like get something to work. Don't even know what's going on and get it so if you press the button something will happen that was it right and copying and pasting have zero idea what's happening but we got the button to work and then you get excited like whoa what just i just made

that thing work now let me go back and start to go to the like break it down into the basics like what exactly went down right i feel like a lot of people do a bottoms up which is very natural and that's what we learn in school is like day one is how does a computer work? And day two is like, you know, you kind of build yourself up. But for me, I've learned that it's much better to just jump, get confused, get exposed to all the different terms or all the different mind maps of the vocabulary so that when you actually do go bottoms up, you kind of remember, ah, this makes sense. This is something I actually ran across and now I actually know what it means. And so I've used that for everything. When I started my company, it was the same thing. You just kind of incorporate, when you start a company, it's no one knows how to start a company. I think there's this like, uh, feeling that you're an entrepreneur, like that's your profession or you studied it in school or something, but absolutely nobody knows. Like how do you get insurance, health insurance for yourself? yourself how do you incorporate how do you do any of these things that means starting a company and it's the same thing a lot of times you just have to kind of jump into it and then

then you can work backwards on the things that you think need to be need to be learned a bit more deeply that's really cool that now that i think about it yeah it's it's almost like you did three boot camps for transitioning into three different things right into coding that's the debt boot camp and then into building your own startup that's yc and then into ml that's uh insight um what was the hardest one um they were all they were all hard in different ways right i think the the confidence i got from each of them is the thing that allowed me to do the next one. So like learning to code when you've never done it professionally or learned in school, that is in seeing that actually that I can make something from it is gave me the confidence that maybe I can start a company.

And doing that, not knowing anything about how to start a company and actually going through the motions, getting into YC, actually doing it gave me the confidence that I can learn something completely new, which I've never come across before. And then you get into deep learning, which is a lot of math, actually. It's very much mathematical than it is kind of web development. That doesn't really transfer over, right? And so relearning calculus and derivatives and understanding how all that works, I think I just was able to be numb to the fact that I didn't know the thing.

I knew that I can know the thing. And so it's just a matter of time and finding the right resources. And so I think they were all difficult. And I actually feel like if you're not doing that, you may not be going in the right direction. I really do feel that it's when you're out of that comfort zone, you're probably going towards something that is going to lead into something bigger, like lead into something that's more interesting or ambitious or meaningful to you. You're going to have to face some kind of discomfort.

And so now I see it as almost like a good signal. I guess there's sort of a sweet zone, right? Like if it's too much you know in the comfort zone then you're not learning as much but i think if it's too far out it just seems so daunting that it's almost becomes discouraging is that would you say that's fair right yeah exactly so so what you do is if it's so far if it feels like so far out of your reach you have to break it down i actually think this is why engineers you know what we software engineering, a lot of what we do is we take a big thing and break it into small pieces and then build ourselves up, right? Like that is all of software. It's all about you have something you

want to solve and how do you make it into different pieces? And you can even go all the way down into a JIRA ticket, right? But it's like, it's literally like tiny little pieces lego blocks that then build up to something bigger and so if you do the same thing with anything you're learning where it's you know i need to start a company or i want to start a company that's a big daunting thing but if the very first step is how do i figure out what how what people want right okay well maybe i can read a book on user research i've never done user research before but i'll read i find the best book that people recommend just read it and then just go do tenant user interviews that's that would be the first kind of step to that and i i think that engineers we we have this in our mentality which is great but you can learn anything new just by

breaking it down into smaller pieces and then starting and the momentum will kind of pick it up from there it's pretty neat that uh you mentioned like learning to learn as a skill you've obviously i mean it's obvious from your career that you're really good at it no seeing that you've done it so many times um how do you decide what to learn though i want to pause and rephrase that i don't think i'm good at it because I've done it so many times. I think I've done it so many times, so I'm good at it. Yes, well said. How do you decide what to learn then? So I can't, I'm not someone who can kind of just academically learn something like, hey, I want to learn the history of Greece. And so I've tried things like that where I really want to learn philosophy, so I'm going to sit down and try to do it. And it just doesn't work.

For me, it has to be an external pressure of some sort where it's I need to learn this thing in order to do something else. Like I need to learn this thing in order to solve a problem that's helping me go towards something I care about. And so the best way is to just learn the thing. Right. And, you know, something that I've done a lot in my life are hackathons. And I can go into a lot of detail on hackathons, but the thing that I really love about them is they are kind of an external force for you to learn something in a very quick way.

And that has always been the most motivating thing for me, to learn something new. That's cool. Like hackathons is something that we definitely want to get into. I'm going to bookmark that here just so that we come back to it. I want to dig deeper on that part though. Like you've gone from one role to another,

which has been different, in my opinion, very different. And it's pretty impressive. What I feel through personal experience and through experiences of many of the people I know, there is usually an inertia to change once you learn something and get good at it, because then you start, like you mentioned that aha moment, and you start thinking,

oh, I can do more of this now. And one track people choose usually is go deep in that one domain and a little wide, but in that same neighborhood. And any extreme change, there is a little bit of inertia to that. And that inertia is for a few reasons, like skill sets is one part, which you mentioned that one can learn with that confidence and one can break things down. The other is also appetite for risk, because now you're going from one thing to another, which is different and unknown many times, at least in your case. How have you navigated that part when you go from one to the other?

And that's a new domain, which you probably know less about than the one before. How do you manage risk there? Well, I think risk is an interesting word. I feel like a lot of people use that word, but it's what exactly? There's two things you need to learn or to think so risk is an interesting word. Like, I feel like a lot of people use that word, but it's what exactly? There's two things you need to learn or to think about about risk. One is what is the actual risk? People say something is risky. Joining a startup is risky.

So specifically, what is the risk? Is the risk that you're going to the opportunity cost of like you could have spent that time somewhere else where you would have made more money? And because the startup went out of business, that opportunity us the risk and you can quantify that or is it uh i'm not sure but like there's just like so you have to be very specific on what risk means to you yeah so the and then the other part of risk is you know in finance and basically in in anything risk is always associated with the reward uh and so what you see is this combined, right? And so people, a lot of times focus on that risk part, but you, if you're going to focus on the risk, you have to also think about what is the reward if you're going to take that risk. If that reward is meaningful

enough to you, then risk takes a different form. Then you think of it like, okay, well, that is part of the game, right? There, that just kind of something I have to deal with. Is the reward good enough to deal with that? And so for me, like every risk I've taken is not because I'm a risky person. It's more like, I really want this reward. Am I willing to put up with the risk? Okay, I guess it's not that big of a risk. And I'll give you an example.

Like when I left to start my company, so I became a web developer for a year, thought I was good enough to start a company. I started a company, right? And at the time i thought oh my gosh this is the biggest risk in the world right i'm going to uh something as bad is going to happen i'm gonna like not the company won't work out i won't have an idea and then what exactly i maybe i was scared that i would never get a job again i don't you know looking, it's almost laughable because there was really not much of a risk. But the reward that I saw was so captivating for me that I could run my own business.

I could create something that millions of people can potentially use. I could go on this adventure that I would regret if I never went on. And that reward just is so obviously bigger than the kind of vague risks that it came up with that it just seems very clear, right? So I feel like focusing on the reward and being very clear on why you want to do the thing can put the risk in a different light. Just to make myself feel like I didn't waste the whole semester in this investment class back in grad school. Like, I remember this concept of a Pareto curve where you're thinking about risk and then you're thinking about the reward. And then basically for the same amount of risk, like what, like which, I guess, stocks or, you know, whatever, have the highest return. So I think maybe that's like a very uh basic idea here but i think yeah like doing the calculation there

but then once you are on that Pareto curve then yeah i mean that's pretty cool the way you think about it it's like yeah like the more risk then necessarily that there will be more rewards yeah or it's just just be very you can quantify it and in a lot of ways i think if you think about something as risky the first thing you should ask yourself is, if I was to put that into numbers, what the negative outcome would be, how would I go about doing that? It's a good exercise either way, because then you'll think about what is it that I'm actually defining as risky here. If it's salary, it's usually something about money people feel is risky, then try to figure out what are you actually risking? And then if you look at that number and you're like,

wait, that's actually not that bad in the worst case scenario. I think it'll help you get over that risk in a way where you feel like it's worth trying anyway. And it's interesting, right? Like for the startup, so I ended up not, the startup didn't end up working out. And when I left my job as a web developer, I thought this would be it. Like if I don't get the startup to work, I would have spent however many years doing this company in which time I wasn't working as an engineer, meaning that I have no option. I have no other way to get back as a job as an engineer. And it ended up being, I leapfrogged the title that I would have gotten as if I just stayed there for those three years and became an engineer because I was able to talk about

the story, how I built my own product and how we had to do actual production issues and that leapfrogged me in terms of title and so it was like obviously I didn't know that at the time right uh but it was something that I uh that was interesting like looking back on and that gave me more confidence that maybe just just believe that you can keep going that's pretty neat. So in terms of the rewards that you mentioned, I have one last question, and then we want to jump to hackathons. Considering the variety of experiences you got through starting a startup, working as an ML engineer,

and now you're working at Stripe, how do these different experiences now help you in your current role? You know, so the current role right now is I'm basically helping startup founders all the time. And startup founders, so being a startup founder is very essential to this role because I can empathize exactly

with the issues that they're dealing with. And so when I talk to them, I say, here's maybe a product that we have, a Stripe that could actually make you go faster or make it better for your next pitch to investors if you incorporate it. I know it's not salesy. It's me talking to you as if I were in your shoes this would actually be something useful for you. So that's one huge thing. The other thing is just this feeling of

building and growing something. So Stripe is a company that's been all about growth. It's all about how do we create new products? How do we expand the scope of what we can offer to businesses and help commerce on the internet, right? And just that drive is something that I see in a lot of people that work there because there, if you have an idea and if you have a better way of doing something, you have the ability to kind of pitch it and actually get resources for it. And so I feel like the idea or the fact of building something that's useful to people, which is what I did, you know, building a startup or when I And this is something that Guang has told me about, that you have won. And you can fact check him here. He has told me that you won, if not hundreds, tens of thousands of dollars in hackathons, which is-

Millions? I think I said hundreds of millions of dollars. I wouldn't go. That last part was not true. Regardless, it is pretty impressive. So tell us more. How did this happen? How did you become so good at doing hackathons?

So this is how this all started. When I was still in business, when I was still doing finance, I was living in LA. I went to this thing called a hackathon. I didn't know what it was, but at USC, they were hosting this event. I thought it was interesting, something to do fun on the weekend. I went there and it was comical because there were 90 business people and 10 engineers at this hackathon. And so what happened was at the beginning, everybody gets to pitch an idea. And so I pitched something and then it's a mad rush to get one of the engineers to get to,

to come with you. And we ended up, uh, and so it was, everybody was chasing these engineers. And then we, I ended up like not being able to get one. So I ended up on a team with all business people. And the thing that we submitted was this, uh, PowerPoint presentation and because we couldn't code. And I just thought to myself, this is embarrassing. It's like terrible. There's got to be a way that I do not want to be in this position again. And so anyway, fast forward. And then once I learned how to code, I started going to these hackathons. It's almost like a redemption. Like I need to go back and actually participate. I need to be able to build something. So I went to my first one and went there, coded something, pitched it, and I got second place at the thing. And I thought, wait, this is crazy. There's all these PhDs and there's all these like CS people here. What is,

you know, I didn't win any money on that one. It was kind of a, just a free hackathon, but it occurred to me that there's something different about winning hackathons than what people think it is. I think a lot of people go into it thinking it's a software competition. And in reality, it's a pitching competition. You have to pitch your idea and you have to pitch your prototype that you build. But you have to be able to talk about the business case and talk about why it's useful and why it actually would make an impact in the world if it existed. So it's a lot of marketing. It's a lot of pitching.

It's a lot of kind of the stuff I learned from business, actually. And so I got hooked on this. So as I was working as a web developer, I would just go on weekends to these hackathons and eventually started flying to them, started winning like at 1.30 in a row where I was just like going, going, going. I had it down to a science on how to do it and wait wait how much money have you won like we're gonna put this like bolded in our in the title of this episode for them you know for that sweet seo so you know uh i would it's in the

hundreds of thousands but i would not i would not that is crazy yeah so i started going to these events and i started and then i started finding out that there was these big money hackathons so in vegas for example all these conferences they had they had a fintech conference and attached to it was a hackathon because these companies wanted to show that they were developer friendly or whatever right and the money at these events was was huge like we're talking twenty thousand dollar prizes fifty thousand dollar prizes and i thought this is really fun because it's, you go there, you compete, you're coding. I'm coding, which I love to do. And you're, and I love competing and,

and the competition for me drives out like the will to win and the will to really level up as fast as possible. And the other reason I started getting to hackathons was because I was an engineer and I felt like I want to learn all these new things and I can't really do it at my job. I'm doing web development, but I really want to try learning how to do an iOS app, but I don't have an external motivator. And so I would use these hackathons. I would always build iPhone apps at the hackathons because it would force me to learn how to do it because I wanted to win. And so it became kind of this thing where anytime I wanted to learn something new in terms of dev, I would use the next hackathon to kind of learn that thing because I know it'll force me to do it. And so that was like a really interesting thing.

If you're out there and you're thinking about like how do I kind of experiment with different skill sets or different languages, a hackathon is a great way to force you to do it. And it can be really fun if you're doing it with a group of people that you like working with. So that's how I got into it. That is super impressive. How did you find these hackathons, though? Man, it's a small world. Once you get into the hackathon world, we all know each other. We really do all know each other.

You actually do. I do go to a hackathon and then I meet the same people. And then they tell me about another one that's coming up in Missouri or something. And then I see them in Missouri. And it's like this small little crew of people that just goes and competes against each other. And it's great. And then you get on the newsletters and you get on things like DevPost, which they'll kind of keep telling you about new hackathons that are coming out. So let's say I'm an engineer out there and I want to start doing some of these.

Where could I go and learn more to find the first hackathon I could go to? So, you know, because of COVID, obviously, hackathons were the first hit. Unfortunately, yes. They have not come back in person yet, but online hackathons have exploded. Uh, and so the place I would tell people to go, there's this site called dev post D E V P O S T. They have tons of hackathons. There's right now, talk of the town is blockchain and crypto. And so you go on there, there's some that are giving out multimillion dollar prizes and you can do them right now from the comfort of your home. So, uh, there's a bunch happening right now and you can go check it out.

And, and, and I encourage anybody encourage anybody to kind of join a team. I'm happy to give you advice on how to win if you need it. Oh, that's neat. We'll later ask you about how people can reach you for sure. And I'm pretty damn sure after we put this in our title, there will be some incoming requests to Ashwin. Hey, Ashwin. From me as well.

Please don't forget your friends. All from Guam. You mentioned it's a small world. So now if you, and you mentioned at one point you won like 30 hackathons in a row. Like, that's pretty crazy. So as people,

I'm assuming people started noticing you that, hey, there's this guy named Ashwin. He comes to hackathons and wins them all. So when you would go, would people kind of try and get on your team knowing your track record?

Yeah, they would. Or yeah, this is coming off as bragging. I'm not saying this to brag. I honestly say it's okay. Really, the reason I really want to bring up the hackathons and the winning is because I think the interesting thing here is not that I'm great at this thing.

It's more that I kind of hatched the hackathon, right? There's a, if you break it down, like I've been talking about, and I broke it down into what is this event? Like what is, what is, how do you actually win? What do you grade it on? And who are the actual judges? Now here's a huge insight. Most of the judges were not technical at these hackathons. A lot of the judges were business people who were, you know, the head of that division, right? And so a lot of the other participants would go up there and they would pitch the technology and go into all like what they did on the back end, which the judges eyes would gloss over because they're not even technical, right? So something as simple as who are the judges even? Like that's the first thing I ever do at a hackathon is look through,

figure out who the judges are, what's their background, what do they care about, right? Because then you can start to see what is it, how am I going to resonate with them? Because they're the ones that are judging your project and that's how you win. And so I think what I read the takeaway here is, is just applying again, the same thing about breaking something down and then like looking at the individual components and then seeing what, what happens if you think about things from first principles. And for me, winning the hackathons, I'm more proud of the fact that I was able to kind of think about it that way.

And it resulted in winning, implying that maybe that was the right approach. But that's the takeaway I want people to get. And to your question, I did a lot of these by myself. So people would not try to get on my team. They would know I wasn't interested in them having on my team. They would, if there's a challenge category, if they knew that they would try to fish to figure out which one I'm in and then try to get changed to something else.

Because a lot of these hackathons are like different tracks. Like that's what they would do. But again, it was more, it was more about the kind of approach I took that I think is interesting. And I think a lot of people can learn from that. Yeah, that's very impressive. Like you mentioned, to break down what it was about and then finding what's the recipe to actually win the hackathon. So pitching is something we want to get to, as you mentioned.

That has been one of the key things, which is not the first thing people think about when it comes to hackathons. I think pitching is something that is not very intuitive to even many engineers at regular jobs, because who thinks about pitching? Before we get to that, there is another aspect of also coming up with ideas. Like you mentioned, you went to different hackathons, somewhere about fintech. There might be others about different domains. I'm assuming you were coming up with new ideas as you go there to pitch. Even though the pitch was really good, you needed the idea first. How did you go about coming up with different ideas at so many places?

So I think this is where my experience running a startup or starting a company really helped, right? Because what you're trying to do, let's say a challenge. A lot of these hackathons will have a specific challenge. They'll say, we're Visa or MasterCard or whatever, and we're doing a fintech hackathon, and we have a challenge. We want you to make it easier for families to manage their finances. That's the challenge, right? And so the first step that I would do is what I would do if I was starting a company is I would figure out who the users of this product, the end product would be, and then try to talk to them and figure out what are the jobs to be done that they have, right? So like, I would actually interview people and do user interviews before the hackathon started,

just because in hackathons, the way it works is you can't code until you get there, but you can do everything else. You'll learn about the challenge, you can design, you can do whatever you want except for code. So I would do user interviews with people, just a few and say, you know, what is it? Like for that one i

think i asked uh my family friends parents like hey how do you manage for finances with your with your family what are the issues that you have right and try to figure out what is the thing that's missing and that almost always will result in interesting ideas uh because you'll organically just they'll say something that just obviously because you know how technology works, you can think this is something we can solve with a couple of API calls. Like, and this is something that could actually be of use. And so it becomes something you do in a hackathon, right?

So I think that's the way that I generally go about doing anything, honestly, is like figuring out who the end user is and then seeing what it is that drives them and then work backwards to figure out what the idea is and you also that way make sure that you have an idea that makes sense because a lot of times you know you go to these hackathons and it's very interesting to see like i really want to use some kind of crazy technology so i want to kind of shoehorn an idea into that thing right um one way to escape them yeah that's a huge problem i mean

i think all engineers love technology and so they want to really learn the new fancy shiny thing but when you when you start with the user and you kind of start with who would be actually use this product if it existed and go backwards you almost always end up with something that's at least realistic yeah i love that it's yeah both things, right there, you're really taking like an audience kind of driven route, whether that's the, like figuring out what's the idea, what's the product actually built for, but also the, like actually, you know, digging up, I don't know, the history on the judges to kind of see like, you know, what I thought that was. Yeah, it seems, you know, I don't know, when I did it, it was like the first thing I did with my first

hackathon. It wasn't like, hey, this seems like something that's a secret I found online. It just felt like so obvious that if the people, if you win based on scores by these people, then it's those people that you need to be presenting to. Not the audience or anybody else. And so if you're going to be presenting those people, you need to know about those people. Like, what do they care about? What do they know about? Are they technical? Like, it just seemed very obvious to me.

So it's, and spoiler alert, like when we talk about pitching, it's, I think this applies to everything. If you always think, what is the audience for whatever I'm doing for this podcast or for a book or for a presentation at work or use for making a product, if you think about them first, you're almost always going to make something more useful because you're thinking of the end user, of the end person.

Why do you think not enough people do it, especially engineers? Is it because you're doing things that don't scale? So engineers just have a tendency not to do that? There's less certainty. So what I found in engineering is that with engineering, like like like just have a tendency not to do that or do you um there's less certainty so you know what i found in engineering and and is is that with with engineering i love uh to know what i need to build and then use my engineering hat to go break it down look up the right tutorials

like that's the part i usually love the most about hackathons because it's so certain uh this is an uncertain path you're basically talking to people hoping to find something and it always works, but you always feel like, is it going to be a good use of my time? I don't really know what I'm going to get. It feels kind of amorphous. And for things like that, I think design thinking is something that I've kind of read about design thinking and I've used it extensively in basically everything I do. And it's been really helpful because in design thinking is all about how do you take something uncertain and then put some kind of structure around it. Right.

And how do you take user research, which is just a bunch of people talking to you and then put some kind of structure to suss out. What are the insights here that can help you build my product? And so that's been, that's been great. Where can I learn more about this design thinking stuff? It sounds like very useful yeah so the stanford the

stanford d school is kind of a gold standard of this of uh they teach uh this is a design school at stanford they kind of really originated a lot of the research in this a lot of the books that have come out of it i would just look for books on design thinking there's a few that you'll find keep coming up over and over and i can't remember off the top of my head but they are um just like a single book or or maybe on youtube find a design thinking session that someone runs and see what it's like that'll give you enough that'll give you enough to get started and to for for the engineers who are listening that is it's i think of it as like how do you apply software engineering ish uh structure to something completely uncertain. That's what design thinking is.

If you look at it, it's breaking it down and using terms. And there's a process of steps that you take to go one by one in order to actually come up with something that's useful, which I thought was fascinating. Like they took something so uncertain and they put some kind of structure around it,

which is amazing. Yeah. It took something so uncertain and they put some kind of structure around it, which is amazing. It's really interesting because when you take something like data science, which I've had a little bit of experience with, it's sort of different, but then it's not as different. It's probabilistic. There are a lot of experiments you run.

You don't know if it's going to succeed or not. At the end of the day, it's still very quantitative versus for something like this, what you're describing, like talking to users and things, it's going to succeed or not. But at the end of the day, it's still very quantitative versus for something like this, what you're describing, like talking to users and things, it's very qualitative. It's in addition to the probabilistic nature of it. So that's super cool. I'll definitely check that out.

Thanks. Cool. So on the topic of pitching. So for the longest time, the concept of giving a pitch seemed pretty foreign to me, especially as an engineer. The show Shark Tank, I think, would come up on my YouTube feed. You can tell some people pitched it much better than others,

but it still wasn't super relatable, especially if I'm not trying to start a company and talk to investors. It's like, why would I care? But having worked with you personally, have really like changed my perception about pitching, because I remember we would have these like one on ones, we're talking about, you know, stuff, going out with the projects, or maybe outside of work. And then every time I feel like I walk away being like, you know, you'll be telling me some idea,

I'll be like, Oh, wow, that sounds like a great idea. Like, Oh'm like ready to go let's like let's do it um and i think it's like way after that like after i you know try my i guess own luck at starting a company that i realized you know a lot of what you're doing is you know it's pitching but not like you know like in the very formal sort of uh sense and i just that's kind of why i realized like holy shit like that's a very like valuable skill because it's not just that um it's kind of like right like it's uh influence without authority and then you're like you know um really like that energizing aspect i found it like um anyways tell us about pitching how did you get so good well so first of all uh I think people confuse pitching with selling. So I want to be very clear, like pitching.

So when you're selling, when you're thinking about sales, right, there's some overlap. But in selling, you're trying to get someone to a transaction of some sort. You're trying to get someone to sign the down to the dotted line. You're trying to make, I think of pitching as you're just trying to convince someone of an idea. Like you're trying to convince someone of that something is important or that something is worth their time, just something to kind of convince them to pay attention, right? And to think it's compelling. And the other thing I would say is you're always pitching. Everyone's

pitching all the time. You pitched me on joining you for this podcast. You didn't call it that, right? But you did something to the effect of this is a good use of your time. Would you please do this thing, right? And that's a pitch. and everything that you do is, is you, if you notice it, like anytime you need something from someone or you want something from another human being or an organization, you're pitching regardless if you call it that or not, and whatever format that takes, whether it's a presentation, it's an email, it's a call, it's taking someone out for dinner, whatever it is. Right. Okay. So the reason I had to learn how to pitch is because I was doing these hackathons as I was telling you and I learned very quickly

from the first one it's about pitching it's a pitching competition right I and then being the software engineer that nerd I am I'm not a nerd you know engineers aren't nerds but I consider myself a nerd I was like I'm gonna get a book on myself a nerd. I was like, I'm going to get a book on pitching. I'm going to go figure it out. I'm going to break down pitches and figure out what makes a good pitch. What makes Steve Jobs so compelling when he talks about something? Anyone you can think of, what is it about them? Can I break it down? I got this book. It's called How to Pitch Anything. It's an awesome book. And it helped me a lot, actually, because the big theme that I've learned and which the book kind of talks about is that, which we've actually talked about

throughout this entire podcast is about, you have to understand who the audience is for your pitch and then tailor your pitch to them, okay? So I alluded to in the hackathon case, if my pitch was to business people, then I need to think about what drives them or gets them excited or could convince them of something. It's not going to be the backend API libraries that I use. It's going to be, hey, this prototype, if it was out in the wild and your company used it,

can result in potentially billions of dollars in revenue to your company. That's the pitch, right? But if I was presenting that same project to a complete, like a CS class, that may not resonate. What they care about is maybe I'll talk about why it was so complicated to build this thing, how this thing could scale out, what are the different tools we have to think about to make it extensible. So the first thing in all this is think about the audience and think about what makes it exciting for them, right? The second huge thing I learned, and this is from iteration, is that people's attention spans are so low that... I don't know what you're talking about.

Yeah, Mike's already lost me on this conversation. People's attention spans are so low that the best shot that you have is to pre-digest this information, like baby food, and give it to them. Like make it so easy for them to see the main concept of what you're trying to say that it's so obvious that they don't even have a chance for their eyes to gloss over. And one of the things that I do to do that is visual. So like whenever I give a presentation, whether it's at work or

at a hackathon, I always think about what is the visual that's going to get the point of this app across easily. So here's an example for Tinder. Okay. Everybody knows Tinder and they know it's the famous thing about the swiping left and right. So if Tinder's whole pitch at a hackathon or something when no one had, it never existed before was we're going to help people find a match and we're going to make it easy as possible for them to do it. It's going to be like a game. So it's not going to be so daunting. Okay. That's cool cool but if they showed in just 10 seconds the swiping left and you see a photo you swipe left you see if what you like you swipe right and then boom it's a match that 10 second visual is so much more compelling and gets the point across in such a such a

efficient way that they could have just done that and then I that is the thing that I would tell everybody is once you have the main idea of what you're trying to present in whatever format it is figure out what is like the fastest and most compelling way to give it to them and always I always think visually I think visuals are animations are underrated when you're giving presentations at work I think animations are really important because animations can really help boil something down in a very simple way and show the flow of information. And I think that has helped me a lot in communicating something. When I look at a hackathon, when I plan out what I'm going to build, first I do the user research. And then I think about, okay, before I do anything else, what is that final image or visual that

I want them to see on before even code or anything? I just think what would make this point obvious? So for example, for that Visa hackathon, where it was, it was like, give your, how can we help family members manage their finances? To me, what I learned in my user research was a dad or mom would have a young child or not a young child, but a teenager or whatever, who'd go spend money. And they kind of didn't know where they were spending that money. And they couldn't really picture it. Like they couldn't see where it was and that made them

uncomfortable. And it kind of made them feel like, I don't know if I'm, if I trust my children. So for me, it was like an obvious thing would be because each transaction has a geolocation when it, when it gets swiped, have a map view. So the final image that I want to present in the hackathon was a map. I knew it, it would be a map where we would have pinpoints of all the transactions and then color coded by which family member did it. Right. And so you can kind of see as a parent, okay, my, I know where they're spending their money. I feel safe. Uh, and I, and I feel kind of like I have control over it. Right. So that map, that map was the very first thing I thought of because it just made it so obvious the problem that I was solving. And then you work backwards, figure out the pitch,

or figure out the actual script of what you're going to say, and then you break it down and kind of build the thing. And so, anyway, long-winded. Think about the audience, and think about what is the most basic piece of your core proposition that you can, and then how can you display that in the most interesting way? And usually it's something visual.

It's not usually with with text um what i'm getting out of this is uh it's like very meta point um i i feel like i always thought about empathy as something that's more innate like you have it or you don't but then the way you're describing sort of knowing your audience really kind of understanding like in a very engineering-y kind of approach, almost kind of like I think challenges like my perception of that, right? Like where you're very much like taking it like a very engineering approach of breaking things down and then really looking at sort of the cause effect. And then, you know, yeah, I think that's really cool. Yeah. And empathy, like, you know, I wouldn't, I think of it more like I don't know someone's life experience and I need to know it in order to solve something.

In this case, it might be I need to create an app that does something for families. I don't have my own family in kids that I can like know this information from. And so how else can I get that info? The fastest way I can get it is just ask people and then write it down, right? And so, yes, it's empathy, but it's not, like, it is kind of a logical approach to it where I just don't know the thing. And so in order to find the thing, I have to learn it. Like, I have to, and the fastest way to learn it is just to ask people who have that issue. It's the first order approximation to empathy.

Would that be the fair way of describing it? Yeah, I guess I am empathetic. Thanks, Kwon. This makes sense. Thanks for breaking that down for us. One question I have is, as you've gotten so good at pitching, when you have to give a presentation or like you said if you're writing an email or convincing someone to do something

that's whether we call it that or not it's effectively a pitch but when you're presenting something in person or well these days over a video call do you practice before in terms of the script that you would say with the elements that you described before i practice like crazy like crazy here i thought you were just naturally talented oh man no no i uh i practice and everybody you know that i have heard in terms of people who do this for a living and t Robbins and all these people practice like insane. And the only way to come off as not practice is you practice so much that it's hard for you. It's like baked into your brain, right? Very important. If you're ever going to give a presentation, if you're ever going to give a wedding speech, anything where you're actually going to be talking in front of people, I highly recommend you practice enough that you memorize it.

And the reason is because, one, you're not anxious when you're up there as much because you know it's just baked into your brain. You kind of have it. But then second, once you have that hurdle cleared where you already know the information, that's when you can make things interesting. Because then you can not feel so rehearsed because you can use hand gestures and you can use movements. You kind of can be more animated you're just naturally more animated because you're just saying the thing as if it's a conversation uh but yeah i practice it a lot a lot and i i don't think i i don't think there's any pride in when people say oh i just winged it and that like that's what was amazing about it i think really the pride would be, I really was intentional about this. I treated it with like, like the importance that it has. And so I practiced it. And I think

back to what I was, you know, for, for engineers, I, here's one thing for engineers and it kind of breaks my heart because they have to, there's so much important work that we do at company, at the companies that we're at. And if we can only pitch it properly, we could, you know, get that promotion, get work on the projects that we want to work on. Like there's just so much return on that investment of learning how to do this, that I really implore people to take this seriously. The next time you have to pitch anything, you don't have to call it a pitch, but maybe even you're doing your performance review for yourself and you kind of want to pitch to your manager, like, hey, here's the things that I did this quarter. And here's why here's the impact that I drove. Right. Use the same approach. Think about what do they want to

see? Like what would make them excited? And then and then kind of see how the information that you're trying to give to them matches up with that. And so a good practical way of this is if you're building anything in software, if you're building, if you built something over the last quarter, last half or whatever it is, you want to talk about it. Think about what the impact of that thing was, right? Like you made it so that three data scientists could spend six hours less a week doing their tasks because of the setup that you did, the system that you set up that's something that's important and when you want to then pitch to the next job or you want to you know try to level up in your career those are things that you point to because that shows that you're someone

who can add a lot of value and that's something that the hiring managers want to see oh that that's really good point and plus one to that i actually would want to try it to what you mentioned earlier about design thinking because this one aspect that you mentioned well if you're trying to pitch your impact or some people call it present your impact you figure out exactly like reducing six hours worth of time for let's say six data scientists in a week that's incredible many times when engineers think about what was the impact that you had and when there is not a clear line on a graph that shows you that this went up or down and this is something you have to think

from an abstract perspective and then put structure around it it's not obvious for many people at least in my experience wasn't obvious for me a few years back or until a few years back i think what you're describing is like a combination of what you mentioned earlier, like design thinking where put structure around something that's ambiguous or abstract, and then figure out how to present it. I think that combination makes it for a killer pitch. Yeah, yeah, you're totally right. It's, you put structure around it, think about what the audience wants. And then the last step is really important, though, you have to pre you have to think about what's the kernel of it. Yeah, there's this, the scene in Inception, Inception is really important though. You have to pre, you have to think about what's the kernel of it. Yeah. There's this,

uh, the scene in inception, inception is my favorite movie. And, uh, there's a scene where they're brainstorming and they're like, how do we get the, how do we plant this idea in this guy's head that he needs to forgive his father,

right. Or something like he needs to move on. And Leo is like, we need something that's, we need to figure out what the most basic version of that is, right? The most basic, basic, basic version, which is my father doesn't want to be, doesn't want me to be like him. Like that's that basic version. And then we have to convince him of that one thing. And then that will eventually grow into him making that decision, right? So I always think of that

movie when I, when I think of this, it's like, what's the most basic version of the idea that you want to do? And then see how you can make it obvious what that is, right? In the case of the engineering case, where it's you save these hours of time, the big idea might be I create a system that made my company more productive or made the data scientist life easier, right? But the most basic idea is if you just sort of chart a bar chart, where it's like before the system, after the system, average time spent on this task by data scientists. And that was all you showed. You can't forget that. It's just such an obvious thing that someone would understand your concept more so than any kind of long-winded text that you can give.

So think about that and then work backwards. I would always think about that before you start presentation. what's that last thing going to be and how do i get the data or how do i actually get what i need in order to show that thing um very meta comment it's like i think i'm still in the process of learning how to do this better uh myself but before i used to think you know oh the more information I can give, like more details I can add, I make it a stronger case. But, you know, obviously that's not the case. And I think sort of the missing information that I had was that, you know, when you give all the information right up front to the other person, you're getting them to do the work of processing it. Right. Versus you have all this information.

Yes, that's step one but if you are the person that's actually aggregating and you know assimilating all these things into a very clear concept like you're doing the work for them so that's sort of the value add i mean the downside is that takes work right like it's not easy it's gonna take you like days to to really think of something but um i think when i started thinking about it like that it made me feel a lot better about like oh yeah like this is absolutely the productive or right thing to do. Yeah. And you're right.

It takes a lot more work. I spent a lot of time on this presentations. None of this, like if you actually saw it, if you saw the presentation, you think, okay, he's,

this is the natural thing. I actually spent an inordinate amount of time, uh, making the visuals, making the animations. If I'm, if I'm pitching something to, you know,

internally to company practicing way more than maybe the average person, but that animations, if I'm pitching something internally to a company, practicing way more than maybe the average person, but that's also because I enjoy it. I love delivering this. One thing going on to what you said, so that book, How to Pitch Anything, one of the really cool visuals in that book is kind of meta. The thing that it got me was he talks about how

when the person creating a presentation or pitch or whatever information is thinking with their kind of most evolved brain, like the the kind of processing analytical brain and then the person who's receiving it is using the reptile brain and the anecdotal like they're the person receiving it is just has so many other things to think about and it's kind of like you treat them like you treat that as you need to uh cater that version of the brain, right? And most people don't. Most people think that you writing the presentation or creating the slides

is how the audience is going to also be on the same wavelength and wanting to process and analyze that information. It's almost never the case. It's almost always they want to be told something in the most obvious, obvious, obvious way. And it's your job to pre-digest it and give it to them. That's how you make a good presentation. I'm not as special as I think. Before we jump off on this, you mentioned that you practice a lot.

What does practice look like for you when you're doing a presentation? It's actually pretty, it's a messy process. What I do usually is I will, let's, let's take an example of maybe hackathon pitch, right? Like I have a pitch that I'm going to do at a hackathon. And that means I have three minutes or whatever on stage to present this thing. What I like to do always is write out the pitch before I do anything. So before I even start to code, I, the very first thing I'll do is let's just write out the draft, at least of the pitch of like, what am I actually going to say? What are the words I'm going to say? And then try to say it just like read through it. Right. And

then think, okay, is this hitting, is this actually hitting the kind of points that I wanted to hit? If the core thing I want to get across is blank, right? Like it's going to help families manage their finances because of this geography thing. Then is my pitch actually hitting that, right? Is it going to be clear to the audience like that that is the takeaway and yet this you know it comes with practice where you kind of can get in the audience's shoes a bit and get into that reptile brain right and pretend that if jenny you're listening to and and if i was in that headspace like do i actually get it and then once i once it seems like it's morphing to something that that that is what i want uh

practicing honestly is just what you think it is i'm in front of a mirror and i'm doing the thing again and again and again i'm just saying it out loud memorizing it and then the first time i do it i'm looking at the paper and i'm looking and i'm kind of like barely being able to do anything outside of that the next time i do it i can memorize a little bit more is memorized and then i can start using my hands and kind of doing kind of doing things that uh make me more animated and make me kind of emphasize points when I'm presenting. And I just keep doing it and doing it until it's time to do the pitch. And at that point I'm so sick of it almost like I've done it so much that I can, I can

immediately snap to any part of that pitch whenever I need to. And then I'll go on stage and then, and then I'll do it. And then I forget everything right after I walk off. Now just imagining like the nights before our one-on-ones you're just like looking into the mirror and then talking about

the other things that we're going to talk about. Yeah, I never practiced for our one-on-ones. Feelings are hurt. Those are all improvised. Cool, yeah. Ranec, do you have anything else

before you dive into the startups no go ahead cool yeah so you know the last I guess topic so you know

we have to stay on brand with the misadventures you know aspect so wow this sounds like

I'm gonna cut this part out of the podcast you know I feel like I sound like a dick right now but maybe that's also on brand. Anyways, so yeah, tell us about the YC startup experience. That's pretty cool.

Especially, I guess, for someone who, you know, might not like intent on actually starting a company one day, but, you know, he's kind of curious, you know, what it is and such. Yeah. So this misadventures what what is uh what what is what does that mean i i was implying because you know it didn't work out so that's the oh okay okay that's why i was doing yeah that was a dick move on that and yeah i apologize yeah yeah yeah yeah um no it worked it worked out in the sense that i got a lot out of it which is i guess the question you're asking

right um yes so that's the definitely that's what i was going for yep yep yeah yeah yeah yeah okay so you think about i basically it's like if you the way i think about startups is you want to solve a problem and you want to do it in a new way that's better and if you do it correct if you're right about the way you're doing it you're right about the problem you're solving and you're right that people actually want the thing that you're making you will get all the things that the press thinks about startups. You will get funded for your company. You will make money. You will maybe get rich.

You will, you know, grow a team. You'll do all the stuff that you think of a startup founder does, right? But the core part of it, the really thing it comes down to is are you solving a real problem? So, and the reason I bring this up is because, and also the reason you can see why I emphasize so much about talking to users and talking and kind of starting backwards, right? Is that in YC, YC's kind of mantra is make something people want.

That's their mantra. And there's a lot that goes into that sentence, but the real reason they kind of made that their stake in the ground is they found that the number one indicator of sort of failure is that someone makes something that they think people want that people don't want. That is the essence of all failure of startup, right? Of course, there's execution and everything, but that is, you know, you get in, if you get into YC, the whole experience of YC is just proving with your startup that you're making something that people want. And if you prove it using some kind of the metrics that we know from Silicon Valley, like revenue or usage of your product or whatever it is, then you can raise money to prove even more out of it. Right. Raise money, hire a team and then prove it even further.

Do more people want what you're making? And if you made it better, does that expand the type of people that can use your thing, right? That's all it is. It's basically that. And so it's really kind of on theme with all the other stuff we've been talking about. Starting a company, it's like breaking things down on steroids, right? You're constantly breaking things down. You constantly have something that you need to get done and you don't know how to do it because you've never done that one thing before and you don't have time to go look it up

and research everything. So you have to learn very quickly, what's the 80-20 here? What do I need to do to get this thing done? What's the fastest way for me to do it? And then let me do the thing. If you need to do payroll, what's the fastest way? I don't know how taxes work.

Okay, this company, here's a document I can read real quick that'll give me at least enough for me to kind of do the thing. If you need to do payroll, what's the fastest way? I don't know how taxes work. Okay, this company, here's a document I can read real quick. That'll give me at least enough for me to kind of get the thing done. And let's keep going, right? That's what starting a company generally is. YC is an accelerator. And so YC will take a bunch of companies. This last batch had 400 companies that went through at the same time in a cohort and all and accelerate you through a 12-week process where they work with you and they they kind of assign

you a group partner from yc to work with you and advise you to as quickly as possible prove out the very first uh to to de-risk one of the very first assumptions whatever that you have for your company it could be different for every company that goes through. In my company, in my batch, we were making an AI accounting company, right? So for us, the thing to prove out was, would people actually pay knowing that there wasn't a human that would be doing their taxes?

That was the biggest risk, right? So that's what we spent a lot of time doing is trying to get people to pay for our product. There was another company in my batch, they were making a self-driving truck. And they're every week on their weekly updates they would come in i would come in and say hey we got you know 10 new paying customers they would come in and say we got the wheel to turn left and and it was like the update and everybody would clap and it would be this standing ovation and everyone would hug and it was this amazing feeling but

that's the thing right it's like uh it's like breaking down what is the biggest risk for your company and then attacking that one thing and nothing else and that's the big discipline that the founders need to have so one thing which i think if i think about engineering in general uh we were discussing this earlier too like engineers like determinism or ambiguity as a startup founder you mentioned that there are so many things you just don't know and you're breaking things down on steroids when you need to learn something new you obviously have limited time so at what point do you decide or how do you decide this is good enough for me to know to solve this problem and move on?

Whereas many times for engineers, like I need to break this thing down enough for me to understand all of it and then I'm going to do the thing that I need to do. I think it takes practice to get comfortable with not knowing the perfect way to do something, but good enough and then moving on. I think many times,

and this applies to not just startups, I think also many engineering trade-offs that we make where we let perfect be the enemy of good. But in startups, it's a lot more important. It's the business that's at stake if you make that mistake as the founder of the company. So how did you balance it out or how do you think about that? I mean, I had a tough time. Like, I am a perfectionist. As much as I keep talking about changing and moving and moving to new domains. I would describe myself as a perfectionist. I'm

always constantly at that battle of, I really want to make this thing better. And I know I can, if I have more time and now I have to let it go and move on, even though it's not as perfect as I can make it, uh, it kills me, but it's what I've learned over the years is it's it's uh the only way you're going to move faster and the only way you're actually going to do the thing is to just learn that it's never going to be perfect and instead focus on if you didn't spend that much time perfecting it or in your the example that you gave if you didn't spend as much time learning every concept of something before you you were like okay i've grokked it then it's if you didn't spend as much time learning every concept of something before you you were like okay i've grokked it then it's if you didn't spend that much time then you can learn something else at 80 to up to 80 percent in that time right and then all of a sudden now you

can do something you couldn't have done before versus spending all that time kind of uh kind of researching that one thing it's a really tough thing to know when is it when do i know enough right uh it's trial and error honestly i think as an engineer you you you uh you oh so i guess hackathons also really trained me in this because in a hackathon you just don't have time hackathons for people that don't know hackathons are basically 24-hour competitions like you go there on saturday morning you stay up all night it's a hacking marathon that's what it's called that and then the next morning on sunday you have to at that point you have to build a prototype and you have to you have have to pitch it the thing. Right. Uh, so you have zero, you just don't have time to kind of learn everything that you need to learn. And so what ends up happening is you have to let go of the perfectionism and just, and just be like, I know enough to get the thing, get this one thing done, uh, which I needed to get done. Now let's move on to the next thing. And, you know and repeat that process over and over. And none of it would be as good

as if you had like dug into every single concept. But the whole of it, the sum of it is that you have a working, you have a prototype, you have something that actually kind of works end to end, right? So I would trust your intuition. I think engineers,

we actually do do this all the time where we can't learn everything about a certain new technology or a new database or a new paradigm, but we to know enough to make our do something for our job or solve this one problem and we do kind of have this internal built-in thing of being like okay i know i could learn more if i got a textbooks on this thing or took a tutorial took a class but i kind of don't have time to do that so i just have to to to kind of take this copy pasted stack overflow code and just accept that this is except that i don't know exactly what's going on here but it

works uh and just move on uh yeah it's like well great uh good engineers coffee great engineers paste right yeah no this reminds me of a conversation i was having with my wife and it was completely unrelated actually but something around this was having with my wife. And it was completely unrelated, actually. But something around this came up. And the way she put it was, like, even with engineers, I think with people in general, like, builders versus optimizers. And sometimes it's more of a personality type, too, where some people really like to optimize something out of a system. And for them, it's much harder to let go. And then it's a muscle that you build

to decide when to let go. And then on the different side, there are builders who get good at knowing enough to then move on and build forward. Do you think for you, it took a lot of building that muscle through iterations, through these hackathons and other experiences? I don't, you know, it's funny. It's

like, I really don't think I am a builder. I think I'm an optimizer who's just unfortunately placed in a situation where I can't optimize. It's a constant struggle. Like, I don't want anyone to hear this and think that this is easy. Like, this is like my natural thing. I actually feel like I'm an optimizer and a perfectionist. And so the thing that makes me really oh i always get frustrated at hackathons and i always i'm a complete mess if you actually saw me i'm not the most uh i'm kind of prickly because i keep wishing i had i could like make this thing better right i can make the design more pixel perfect i wish i could i really always wish i could refactor this code right now and and make it modularized and uh and it, you know, eats at me. So in a meta way,

to answer your question, I don't think that I became a builder. I think I just, let me put it this way. I think I got more excited about the thing that I, the next step, right? If I could take this thing to the next step, meaning it's not perfect in the step zero, but if it's, I can at least get to step one at 80%, that means I can get to step two faster and and that's step 10 which i think is really exciting i'm gonna get there right so i i think of it more like unfortunately i have to move on kind of thing it's always like a disappointing feeling but it's always also a feeling towards growth right and so um yeah don't don't worry if you think of yourself as an optimizer like oh that means i'm never going to be able to do something uncertain like you know

building a company most of these software most of these founders are those people the only difference is they kind of realize that building you know solving the problem for their users is just way more important and so they're just going to have to bite the bullet and not be an expert in the thing. That's the whole job of a startup founder is to not be an expert in anything and just be very, very quick at getting to 60% and then figuring out how do you hire or, or build,

bring in talent. That's way better. Uh, so you always feel like the dumbest person in the room, which, you know, there's a trope that that's means you're in a good situation. If you are,

if you're always the dumbest person in the room because you have smarter people around you but uh but yeah i would i would say just get more this is about the risk and the reward thing too right get more excited about the reward if you get really pumped about where about the project that you could build or the outcome or maybe not the outcome but the end result and you get so excited about it you're gonna want it so badly or you're gonna want to get there faster and so the only way to do that is to let go of your optimizations and just kind of move i think that that's the way i think about it nice nice um i feel like that's a pretty good place to start i had actually so many other questions about you know going through yc about

the startup school that you know you like literally sell like thousands of like pitches um super interesting and then like even like things like angel investing but um we uh we need to have you back for another episode we definitely need round two here yeah i'm glad to be back man this is awesome this is fun oh this has been great so any anything that you'd like to share with our listeners um before we call it no you know i would say, and you said a lot of them are engineers and kind of, you know, been working for a little while. I'd say, you know, don't,

I would have some confidence. I think learning to build software is an extremely complicated thing. And the skills that you've learned from doing it, you have, you've by definition have to learn how to learn quickly. You know how to break things down into small pieces. You know how to build things back up and you know how to add value and think about scalability.

All the skills that we kind of think are just part of our job are the same exact skills that will allow you to kind of do other things in life. And if you apply those things, which you already have an internal intuition on because of because of your career you're you're going to be able to succeed just just keep keep with your guns don't kind of for example with angel investing or anything else you know break it down into pieces and don't get scared because it's something you don't know yet just just do exactly you've been doing with your with your software just break it down look up what you need to look up when you feel like it's good enough move on to the next thing and that's uh that's how i would learn anything such wisdom much wow awesome this was awesome by the way we should add it um where can

people find you on the internet because you you did mention that you you're open to helping people out if possible get ready for the emails yeah uh i I mean, you can, you can tweet at me. My Twitter is a Schwinda, S-H-W-I-N-D-A. Well, that's a cool name. Maybe we could learn more about that next time, but yes, we'll add it to our show notes for sure. Once again, thank you so much, Ashwin. This was really a pleasure.

Thank you. Thanks, Ashwin. Hey, thank you so much for listening to the show. Thank you. Thanks next time, take care.