So I would say, my first piece of advice and the thing that has been most resonant in my career is that I've spent the last 20 years, I met my co-founder for my current venture, the first day of college, and we've known each other now for 20 years. And so, you're in a great place right now. College is such a great place to meet your future business partners. Your future co-founders, your future employees. So I think that is something that I think about a lot is, how would you, who were the people you're meeting in college and how are you building your own legacy, right? If someone needs someone who's really good at XYZ, are they going to be the person? Are you going to be the person? Are you going to be the person they reach out to? So that's one thing to do in college. And, also your professors, right? A lot of times I, when I need to find talent or when people are looking for talent, they would go through the Professor network at my university to find me or I find others. So I think a lot about, how do you think, how do you leave a legacy at every organization part of. So I think one I got really lucky, I met my co-founder on the first day of school. And we've worked together on and off for the last 20 years. So he brought me into work at Yahoo. I brought him into work on some other start-up projects. He went back to business school, and then after he was graduating from business school, we decide to get together and work on something else together and that was in 2012. And it goes to show kind of the imperfectness of planning because we had all these ideas for things we want to build, and yet, at the same time, every time we'd be on, so he was going to the warten and we'd be done at Warton and working on business plans in his dorm room or his apartment and all his friends of Columbia said, Hey, you guys are both engineers. Can you guys like to teach us how to do some of the codings you're talking about? Right? So 2012, learn to code was still a pretty new idea and so we can say no, we're coders, we are not teachers. And finally, after enough prodding, people said, "No, you got to do you have to do something." So we set up a landing page. He said David and nimit are going to teach a two-day workshop on learning to code for business school students only. And someone sent it out. It went on to mailing list and before we knew what we had, 40, 50 sign-ups, more than we could handle. And this is a couple 100 bucks a pop, too. So, like, it's not a lot of money, but it was a nice kind of pocket change, and then before you knew it, people at NYU Columbia, Warton, Harvard, MIT. They were all hearing about this. They were like, "You got to come up and do a session here." So we spent probably three months going up and down the East Coast teaching at business schools. How to do code? We would add on, like, coding seminars, learning how to talk tech, etc, and then this is the same time we're building other startup ideas. And finally, I think one day we were on, we were on an Amtrak going back home, and we were like, You know what? There's clearly a strong demand for learning how to code and we were, our classes were getting rave reviews, and people kept saying like we have a talent for it and we really like it, and what would a business look like? The one shift in our mind was, what programmers? We didn't want to teach wouldn't want to teach MBA students a little bit of code. We wanted to take people all the way to where we were. Our mental model was how do we train people to be the engineers that we would have hired? So that was the basis of the full-stack academy, yeah, and the rest from there. For the last eight years, we've been building out, we think about scaling a few different vectors. One is just the number of students that we can service a year. Two is the number of curricula that we have right. There's more than just programming and just more than just web development tech. And now it's really how do we expand the distribution that we have? So we've been partnered with universities running university boot camps. We continue to grow the full-stack brand, and we work with local governments on workforce development initiatives, so, and then 2019 we actually, we were in the process of fundraising, and as often, as I've heard often happens, as you start fundraising, strategic start being part of that conversation, and sometimes they become interested in, instead of just investing and buying. So we were actually acquired by a publicly-traded company in 2019. And so, I think the last year understanding what that means, understanding kind of the financial reporting that Wall Street requires. So that's been an interesting journey as well. But yeah, that was the history in that show. I really like what you know Mark Anderson wrote once, it's like if you had a look at your product, your product, your market, or your founders, what's the most important thing? And one thing is that we got to go where the market is right, and it is very hard. I think one thing that college students often have is they don't know enough about markets. They know only about kind of their own problems, and their own problems seem to be, I can't tell you how many times students will come up to me and says I have a new idea for an events listing site because I don't know what is going on this weekend, right? I'm like no one needs another events listing site, right? No one needs another chat app, and you're going to go with the markets are, and then the market oftentimes are, like Mark Andrewson's thesis is good, a great market will pull a good product out of mediocre founders, right? And that market, that often is a better scaling directory, then great founders, great product, no market because it's very hard to educate people on a new market on a new idea, right? I often think if you're not solving problems that people really have right now, while there are too many things grabbing their attention otherwise so it's hard to plan when all you know is, you know your product and yourself.

What's funny is that, early on, we picked 12 weeks and I think what we did was, we built a schedule. We took our undergrad CS curriculum because we were both CS majors. And we said, what do we actually think we need to learn? And a lot of that brought down to, we're playing with anywhere between 10 to 30 weeks. We ended up after a few different iterations picking 12, and I think that's stuck with most boot camps. Most boot camps are about that 12-week program that's lasted throughout. I think there is a magic to about three months, right? And I think schools figured this out too, right? Semesters comes out to about three months typically, so that was our model for five years. You come in three months, and our idea was to make it very intense. So I learned this from Paul Graham of Y-Combinator. He's like, oftentimes you don't need, you don't need to necessarily do the right thing in life. You just need to stop doing a lot of the wrong things, and a lot of the wrong things is like, going to family events, going to your friend's party, going to XYZ, and he's like, use Y-Combinator as an excuse to get out of all that stuff. So we're like, we tell our students, use Fullstack as an excuse to get out of all other things, your friend needs help moving, you're like sorry, I'm in a boot camp, 9 am to 9 pm every night. So we make it very intensive and so that was the initial model, then, as you realize, we start exploring part-time models. Typically, we see that in the six-month time frame. So, people doing 2 to 3 nights a week, usually weekend, I would say that's mostly where if I look around, the online, in person, or online, synchronous education models. So, you're with an instructor, you're with the team, not like a mook. Then those are the difficult time frames. I think if you go longer, you start having, too much life happens to people, right? They start going shorter because it's too superficial, what you can learn.

I think one thing I've always loved about boot camps is that we're not, we don't debate whether or not we are industry-focused or theoretically focused, right? Where I said, it's a common debate in academia, it's like, do we push the edge of the boundary of knowledge, or do we kind of just teach people the practical tools sets. That's not a debate that we have to have. And so, we're always in talking with our employer partners, what I was talking with, like CTOs, VP of engineering. We're talking about the alumni base. What are they learning? What are they actually using? And then, so that's one access of what's happening in the industry and the other access is if something's happening in the industry, does it, is it more pedagogically sound to teach that versus what we're currently teaching, right? So, for example, I'll give you, when React came out, right? One thing, that React took the industry by storm because it solved the problem in a very interesting high-performance way, especially compared to the tour of the time which is called angular. I remember, angular was an amazing feat of engineering but required a lot of different mental models, a lot of complicated mental models to understand it, right. So, what was nice about react is that fundamentally, it introduced a lot of what I would call functional programming concepts into the programming kind of environment, right? And so the idea of functional programming where it's kind of, I can't remember the term, but maybe the term, like, the same outputs always generate the same, the same input always generates the same outputs, what is it called? Yeah, item potent. Right. So having that property, generate the ritual down, the ritual dumb dipping, and then using its own algorithm to make the most performance down changes. Those were very good ideas, I think, improve how people program, and so that was an example where, not only could we get up to date technology, but we could get better programming concepts into our student's minds. That's always a trade off that we're looking at. So, one thing we're exploring now is typescript, right? So the idea of, how do you use, because typescript is this idea of gradual typing. How do you increase the documentation of code for humans and for compilers to better manage your code. And I think, typescripts one of those things where I think it will in five years, we won't write JavaScript anymore, we'll write Typescript only. Graft UL, another one of those where Graft UL, I cannot think of solving some of the problems at Typescript, right. How do you communicate between the front end and back ends in a, I would say in a type annotated way, that separates the implementation from the actual information that you need, which I think that's not a tool. I find that that's one of those things where the industry is actually not moving as quickly on it as I think, how good of a technology it is, right. But it's a bigger change than just putting typescript in the adoption path. This more kind of a jump step rather than a gradual curve.