>> what does it take to be a standout founding engineer? Michelle Lim was the founding software engineer at AI startup warp and is now the founder at her own startup Flint where she is now also hiring founding engineers.

In this conversation, we cover Michelle's thinking process to take a risk and join as engineer number one at a littleknown startup when she had better paying and safer options. Thriving as a founding engineer and why only to pick up work that no one else wants to do. Figuring out if you're more of a product first or code first engineer so you find your place better. How Michelle's current startup builds autonomous websites and uses AI coding day-to-day and many more.

If you're currently working at an early stage startup or want to work one day at a place like this and want to know the tactics on how to do well in these environments, this episode is for you.

So, Michelle, welcome to the podcast.

>> Thanks, G. I'm so glad to be here.

>> It's awesome to have you. How did you get into software engineering?

So I actually started in college. I first joined an entrepreneurship club and I was working on a bio company but every week I saw that the companies in my club that were making the most progress were people who had programmers on their team. So I felt like oh like if I wanted to move faster in entrepreneurship I wanted to actually build the thing myself so we can move a lot faster. So, I took my first computer science class ever in the spring of my freshman year, which is very late compared to I think most of your listeners.

>> Yeah, it's it's never too late, is it?

>> Never too late.

>> And then from there on, did you move over to computer science? Did you start studying at a university or did you do it on the side?

>> Yeah. So, at that moment, I actually then started majoring in computer science. Um, I really fell in love with computer science, especially the debugging was my favorite part, which is really funny for most people, I think.

So, the backstory was that I almost became a medical doctor. Like, I grew up in Singapore. Yeah. Where that was the uh the thing to do if you're good at the sciences. And I really fell in in love with medicine because I really liked diagnosis, like differential diagnosis. you know, someone comes in with, you know, a swollen left leg, you're like, "Oh, that could be a problem with your right lung." And I thought that that was so cool. Or based on the vision that you're seeing of your eyes, it could be a very specific part of your brain that was malfunctioning.

So, I really liked the debugging part of my computer science assignments where I started seeing that there was always a pattern in which the bugs occurred and then I could trace it back to the specific lines of code or systems that led to it. So I felt like almost like I was a doctor for the computer and I it also helped me a lot in terms of being able to build things which I really love. I started uh interning at um tech companies and really fell in love with the with the art of software engineering um and that that just further um validated that I really love software engineering.

>> And then you entered at some really cool companies. I think it was Meta, Slack, Robin Hood. How easy or hard was it to get into get your first internship? Obviously, the first one is always going to be the hardest. And then what did you learn at these places?

>> I was very lucky to um have had this university program where they actually placed students in tech companies. Um and my very very first internship actually was in Sa Paulo, Brazil. Um where I was working as an intern for a healthcare company. And that was where I really got my start and really learned uh software engineering from a very senior developer there in Brazil. Um so I'm very thankful for uh for that. And for um guess the listeners who have university programs who are in student school um reach out to the careers office. They could be really helpful in helping you get your start.

for Facebook. It was uh also it was me co-applying to uh the website uh to this program called the Facebook University. So this is for folks who are underrepresented um and who are new to computer science and they bring you into the program and then bring you through a a two-eek boot camp where you're building an app every single day. So there every single day.

>> this is pre prei, right?

>> This is prei. So I was using my hands to uh write Android apps in Java and so every day we were building apps and then after the twoe boot camp we were put into pods where we had to build a fully functioning app by the end of the internship and that's when I learned git for the first time. I learned how to collaborate with my friends. Um I learned how to read uh really large code bases.

um because we were uh building a receipt splitting app. um through OCR as well as like Bluetooth where you could find your friends near you and then drag and drop avatars into uh the receipt items. So if there are three broccololis and you ate two broccololis and I ate one broccoli, I would drag avatar twice into the receipt item and mine once and then it would split accordingly. It was really fun, really cool because this was a personal problem of mine, splitting receipts, but we ended up having to dig really deep into uh the uh open source libraries of uh the OCR from Google as well as like a Bluetooth protocol um that was online. So, I became really good at that. And I was also very fortunate that like our team actually won for being one of the best apps in the internship program.

>> Awesome.

>> And got to meet Mark Zuckerberg uh in his office.

>> Wow. So after a Facebook internship, you ended up working a little bit at Slack and at Robin Hood as well, right?

>> Yeah, that's right. Um and that was where I really caught the uh startup bugs. So um I joined Slack through the uh Kleiner Perkins fellowship program. So um this is like a fellowship program for uh for students to intern over the summer with the portfolio companies of this VC called Kleiner Perkins. Um, and at the time no one I knew was really using Slack. It was only 1,200 people uh at the time. And um I was really excited about the chance to uh see what this whole like startup scene was like. I mean at the time I considered Slack a startup. Like looking back it's not a startup but it felt like a startup to me. Like someone who at the time wasn't really familiar with tech companies and I had such a good time uh at Slack.

And I I think we can also be fair like sure Slack today is maybe not a startup but like compared to a lot of companies they still act way more than a startup even today.

>> Oh yeah it was it was really awesome. Everyone had so much product ownership. It was a lot of fun because it was also incredible to be at a company where you were using the product that you were building every single day.

>> Yeah. like it was like I would start using a feature um then I would be like oh like I think that instead of me having to search through my emojis every time I need to react what if we put like a frequently used emoji like you know I I I'll design it myself post it in this like feature request channel and Steuart Butterfield at the time responded being like yes we should do this and then I had another idea around like scheduling messages so that um I didn't have to wait till the time I wanted to send message to send it out and I posted it to the channel as well and he said, "Ah, that's so unnatural. We'll never do that." [laughter]

>> But that's really cool getting feedback straight from the CEO or co-founder. That's awesome.

>> That was like such an awesome uh culture to be in where the CEO was so excited about the product.

>> I I feel the culture talks a lot, you know, both at Meta and and at Slack. The fact that the CEO and co-founder is very is open to talking. Okay, they're not going to spend whole day, you know, talking with like interns or or new joiners, but they do and they're accessible. I feel that's going to make a big difference between, you know, like some companies and then other companies where this is impossible.

>> Absolutely. Yeah. Um especially now as a as a founder myself, like I always make sure to spend a lot of time and be generous in my time with with people on my team.

>> And then what did you learn at Robin Hood?

>> So Robin Hood I found uh through uh through a tech fair. Um, Robin Hood was where I really found my sweet spot about what I loved uh to do in software engineering. I was working on the Robin Hood news tab. So, um, this is a tab that let you see let users see the the news for the day and how that would, you know, affect their their their stocks. And at the time, Robin Hood only had three tabs. The first tab was the main tab, you know, trade

>> portfolio trade. Yeah.

>> And then the third tab was like settings, so notification, and I was working on the second tab, and I had it was maybe like five or six of us working on that main tab. Um, and I was in charge of deciding um what news to show on every person's feed.

>> Yeah. And this is like millions of people using it, right? And making decisions based on that. like this is like not some like hidden feature.

>> Yeah. And I was 19 or 20 uh very young and they gave me that opportunity to build that and I really found that I love I love that I found my sweet spot in that I felt like I got to work on very cool computer science concepts like we were using Robin Hood version of Cafka to do the data pipelines when we received for messaging. Yeah. for the messaging because we had to parse um the uh video feeds and the news feeds coming from a lot of our partners like like Bloomberg was selling the news to us and then we had to then tag them.

um and and then based on the tags and as well as like what the users uh were invested in figure out like what are the relevant news what to do if it's too sparse how do you um populate the feed such as there no bias for machine learning cuz we also wanted to keep learning what to rank first. And if you had a very prescriptive way of uh ranking your feed, then you would just be giving biased data to the machine learning algorithm for deciding what is the most interesting uh item.

So like to me like that was really exciting because one I was learning a really cool computer science concept but then two I was also deciding like a lot of the product requirements you know what does the user want but then what is technically feasible based on what are the business partners we had and like based on our tech stack and then based on like latency requirements. So I felt like I was able to activate like like all parts of my brain thinking about the technical side but also the product side and because of that I felt like oh I I really love software engineering like this this is where I want to be.

>> Do you love software engineering startups or both?

>> Um it was actually both Facebook's Slack and then Robin Hood. Um they actually became smaller and smaller right as I did my internships.

>> Yeah. from uh 12,000 people to,200 at Slack and then 300 at Robin Hood. And I found that every time I went down, like roughly an order of magnitude, um I felt like way more ownership and I felt like the line of sight between me building and the users impact that I was making was extremely clear. And so I knew like okay now that I've done the 12,000 the 1200 and then 300 obviously the next step is like joining a twoerson company and then starting my own.

So it's incredible. You had four internships in I guess in four different summers. uh three summers and in in three summers you kind of had them together which is amazing and now like you had all these companies behind your back on your resume. I'm assuming you know you could have decided to go into a bunch of different companies and then yet you decided to go into this unknown company that at the time was was completely unknown. It just raised something. It seems like a pretty risky bet to go into a early stage or like seedstage startup. Tell me what was your thinking after this?

again you've you've seen these different companies and how did you end up at like such a small company kind of it it felt like taking a big risk I'll be honest

>> oh yeah um it was it was a very big risk there wasn't any code written yet at the time

>> there was no code

>> no code written um

>> so it was just an idea and like a founder with an idea or

>> they were very nice mocks um the first the first hire at warp was actually a designer

>> and and then can you tell me like what was the kind of idea what was the stage at warp when you came there what was the vision what were the mocks like Oh yeah.

Well, first of all, it was called Denver at the time.

>> Denver.

>> Denver. And um I remember being like, if you want to think about SEO, Denver terminal is definitely not the way to go. Back then, I already had like a lot of growth intuition. Um but it was meant as a as a placeholder as they figure out what the as Zach, the founder, was thinking about names.

Um, so there was the key mock was a terminal that had the terminal input at the bottom anchored at the very bottom. And then there was a blinking cursor that was a line instead of a rectangle. And then there was a concept of blocks where terminal inputs and outputs were grouped together and there were lines between the blocks

and that was the key the key one. And then I think the second mock was collaboration. So we had like different avatars on each of the terminal um blocks. So it was almost like Google Docs or Figma like oh you could have multiple people looking at this mock at at this terminal. That's so cool. And then there was the concept of like sharing environment variables and presets. Um cuz we all know like everyone is such a pain to get environment variables uh especially in teams. I mean, no one wants to confess this, but I'm sure everyone has had send has has experience of sending environment variables through Slack. Um, and that's it's no good.

>> Yeah. And and also, of course, I mean, you always have them in your local files, which is a necessity, but yeah, as you said, sharing them. You don't want to put it into GitHub, but yeah, how do you transfer them? Yeah, exactly. Sharing those keys that should not be shared because your colleagues need them or your teammates. Yeah, as you said.

So like so like do I understand the vision was like basically the vision was like hey the terminal has been around forever here's a couple of cool ideas on how we can innovate and this was pre AAI right like this prei

>> okay we but already that that was the the vision

now can you tell me a little bit about like I feel not many people talk about this especially when you're still earlier in your career you're a new grad okay you know like you've had a couple of like really cool internships which means probably you know like a lot more companies will be open to to hiring you were you interviewing at other companies as well or was this the first one you did? And how did you think about or how did you go about like negotiating your you know your first full-time composition cuz I guess with internships you don't have much negotiation but but here you probably had some leeway.

>> Oh yeah, every everyone wanted engineers at the time. The thing is that I never really envisioned myself joining such a small company. It was only two people and

and there was no Kin. Um, so my focus during my uh job search process was focusing on uh 15 to 20 people teams series A. I had a couple options that had $10 million ARR already. So, you know, you you could I could join a rocket ship like see like fast growth and then get to know for sure that there will be a lot of opportunities because when you have a fast growth company, there's just way more things to do than there are people.

Michelle was just talking about how she had the option of joining startups that were growing really fast even before AI. Today, what I'm seeing is many startups are growing even faster because they can get to incredible velocity with AI coding tools. And so, they can ship features a lot faster than before. But without measurement, you don't know which features are helping and which are hurting your growth. When you're shipping 10x faster with AI, that uncertainty compounds. You could be shipping faster towards better metrics or you could be shipping more features that hurt conversion and retention. This is where our presenting partner static comes in. Static built experimentation and feature management that acts as guardrails for AI accelerated development.

And now let's get back to why Tim Michelle chose to join a very early stage startup.

>> So I actually had a lot of those options. Um but ever since talking to Zach um the the founder of Warp, I kept thinking every day about the product and how we could make it better. Mhm.

>> And it was just a product that I had to I discovered that I had a lot of passion for because um when I was uh doing the software engineering internships, I actually found that there was a lot of uh real business impact from improving the terminal. In the summer of 2018, Slack had multiple outages. Um that was the first time that Slack was bringing on new enterprise clients like IBM and Disney. And so what you know the double nested loops that could have worked for uh selling to startups no longer worked at IBM and Disney scale. And so a lot of things were breaking. A lot of terminal comm a lot of uh internal tools were run through CLIs. A lot of commands were being shared on Slack.

>> you were you you were seeing the potential of like how just like I know sharing commands better like better tooling a collaborative C cl C CLI even a Slack could have been helpful at your time right?

>> Yeah. So I saw a huge business impact and then second I also personally as someone who just learned computer science just a few years back saw that it was a very big barrier to entry for a lot of computer science students um because computer science is already so scary um to learn for someone who's new to it um but what is even scarier is trying to move the cursor from one uh character on your command to another and realizing that the mouse doesn't work

like I felt like there was also a lot of impact society that can be made if coding was a lot simpler for everybody. Um if we could make a terminal more accessible, if you could move the cursor with your mouse instead of memorizing control A uh and Emac shortcuts. Um so it was like okay this business idea there's a lot of business u impact and potential revenue and if we do well we can make computer science a lot more accessible like when else can I join such a cool idea as the first engineer. I could always look for a job um in any of these like $10 million ARR like doubling like every quarter things but it's so rare to kind of coincide with the window in which this company was being started and that I get the chance to be the first engineer.

Um the other thing was like in other companies if I were to join I wouldn't get the opportunity to work so closely with someone who was a principal engineer at Google.

>> Yeah. So, Zach was a principal Google engineer, right? Like he's a longtime software engineer.

>> Yeah. Former CTO at Time magazine and I felt like I, you know, some of my friends would go um study masters programs to be better at computer science. But here I had this opportunity to get go through Zack University to become a really good software engineer very quickly working directly with him. He was looking through all my tag dogs, all my pull requests, and I just became a very uh good engineer very fast. That was how I made the decision. Uh it was a it was definitely very atypical. Uh like I I could have gone back to Robin Hood. I had that return offer. Um but I just knew that I needed to be somewhere a lot smaller.

Did you negotiate your compensation? Especially, you know, with startups when you're joining early on in a Silicon Valley startup or or at like honestly most startups that are kind of like either have venture funding or plan venture funding, a part of composition is equity, which is always a bit tricky subject for for most software engineers. How did you research equity? How did you learn about it? Did you negotiate it or you just kind of took whatever was, you know, on the offer? because I feel this is a topic that not many people talk about but it does get pretty important right?

>> It is so important uh to to negotiate for equity. I really negotiated hard for as much equity as possible and what I was willing to trade off was cash.

>> How was your offer presented?

Yeah, I was presented a spreadsheet that had three options uh with increasing salary and decreasing equity. It was a really good spreadsheet and I I actually use this today uh where it actually

>> at your startup if someone gets an offer they're going to get a spreadsheet like this.

>> Yes, at Flint my company you will get this spreadsheet that helps you calculate what the equity actually means in terms of the compensation value. Uh we also hand like we also calculate tax as well as dilution at every stage and then we also have this uh calculator that helps you calculate the expected uh value of your stock based on different uh outcomes and the likelihoods of each outcome. Um and all credit is to Zach from from War who let me use this uh spreadsheet.

But anyway, there are three there are three options and um I argued very hard for the one with the most equity and I was willing to go extremely low on cash. And in terms of what leverage I had, this is probably a bad negotiation strategy, but the way that I negotiated that was saying, "Hey, Zach, I actually really really want to work with you. Um, I will work with you. Um, I will sign this offer. this is I really want to build this thing. Let's go do it. I would really appreciate if we could do this off this number instead of this number.

Some might say that that's a really bad uh negotiation strategy because you are losing all the cards by saying that you don't have any other options and uh you know some might say the best way to increase your your offer is by having competition. But I think that early stage companies um where you're joining as just like one or two people, it really means a lot to the founder that you are bought in, ready to go, excited to help them and they want you to be happy and they want to make sure that you have a good deal.

I will say like you know the the general advice of negotiation that you read online first of all a lot of it is written when you're negotiating with against faceless corporations where the person uh giving the offer let's say an injury manager or HR they don't own this thing they're given numbers and it's they have a job to do which is close people and they have don't have too much emotion and a lot of that advice will work you know like that they do but as you say in a startup it's it's people it's a very small team the founders do care.

Now, one thing I've heard that is also atypical and no one will suggest, but you still did it, is you know when a company makes you an offer, they often ask for references for you to talk with other people or before they make an offer. I heard you did that with Zach Warp CEO. H how did that happen?

>> Yeah, I actually pulled up the email before this and I saw that I said like, "Hey, Zach, really excited about this. Um, happy to send you my ref checks." Um I would also like to learn more about how you are as a manager. Can you send me a reference uh references for people that you have managed before? Um especially when they were junior engineer.

>> I mean I I would recommend everyone to to do this actually. They say like you you don't leave companies, you leave managers. Um and uh at a startup you can't pick your manager, you can't leave a team. Like my

>> Yeah. Like my friends working at Google could be having a bad time with one team and then they could switch to another team. At a startup you are married to that manager. So you need to learn as much as possible about what it would be like working with them.

And um you have like reference checks are by the way the most important part of any interview process. Like that is like sometimes even more important than the on-site itself.

So at your current startup, you're also doing reference checks.

>> Always,

>> And what do you look in a reference check now? Just kind of, you know, thinking a little bit from a founder,

>> if I as a founder, I'm evaluating a candidate. Um, the most important question I ask is, would you want to work with this person again? And the answer I'm looking for is not yes. The answer I'm looking for is hell yes. I I don't even know like why you even asking me this question. Like you're so lucky to have this person like I don't know what's happening in the waters of your company but like how are you able to pull someone like this? That is what I'm looking for. Um if I'm hearing like a oh like yeah I think that they could be great or like yeah they're very strong. Um that to me is like a bad reference check that does not pass my my test.

So it was really important in my reference check to check how much opportunity did someone young and junior get like what were career conversations like? How did promotions work? What was it like during the tough times? Um and Zach passed like exceeded all of the tests in that I talked to two engineers that were new/in interns working for Zach and then very quickly became director of engineering at uh Google Sheets. Um, so he was clearly someone who would bet on young talent and then help to promote them. Um, and I saw that again again at at Warp where a lot of uh younger new grads were given positions of tech lead or being able to uh run the most critical uh project streams at Warp because Zach always bets on the young talent.

when you joined warp uh what kind of technologies did you work on and how did you find your so-called kind of stack or place because you later talked about how you know in startups or in tech companies there's kind of like more product and more infrastructure more front end more more backend where did you end up in this sense

>> so the stack at warp actually first started out with JavaScript and then within oh it was TypeScript and then uh two to three months in we decided to scrap that repository and rewrite every just like rebuild everything in rust.

>> I have to ask why although I I suspect why.

>> Yeah. So it was for performance reasons and it was also speed of development.

>> So um while it was really fast to push out JavaScript code, we then needed to spend a lot of cycles testing stress testing it against um a lot of performance constraints. So, one thing I did with our JavaScript app was that I drew a thousand rectangles um and then I started scrolling the terminal and the scrolling was breaking. Um and it's extremely important for us to be able to draw a lot of rectangles because yeah like terminals output a lot of a lot of uh logs and everything needs to to to be really fast.

There was also a very strong sentiment amongst amongst developers that they would only use uh high performance terminals that were built low level. So even if there were two applications that were completely identical but one was built in Rust, it would just be distributed a lot better, people would love it, people would uh you had this at back time back then like the Rust community was was small but growing very fast and extremely passionate. And so it was also very important for marketing that we built it in Rust.

It was very really uh funny when we decided to do to uh beat and rust and then um Zach sent the O'Reilly Rust book to every um everybody. So me the founding engine uh the other founding engineer a log and he and then we would just read every day and then every time we learn something new we're like oh let's rewrite what we wrote previously. There are way too many unwraps um so let's go fix that. We also had the privilege of uh working with uh Nathan Sobo who was uh the inventor of the Atom um editor and then eventually started Zad and he had a lot of Rust experience and every day he would pair program with me and I just learned all of the Rust um idioms that work really well.

>> I guess pair programming does work.

>> Oh yeah. Um, I really enjoyed pair programming with Nathan uh because I learned a lot of like small ergonomical things that makes a big difference in in using the IDE. You asked a question earlier about like product engineering versus infrastructure engineering. Um, and I wrote a piece like many many years ago before the word product engineer even became uh in everyone's lexicon.

product engineering and product first coding are like people who are more motivated by user problems and excited about solving the user impact and then they see technology as a means to an ends of user impact and then there's like the codef first people who tend to more map onto to infrastructure engineering where they're really excited about like you know the best performance the best libraries elegance

I found through my Robin Robin Hood internship that I very much am like a product engineer at heart um and I find that this division of product versus infrastructure engineering is a way better split to think about engineering than front end and back end. Um because of the mental models of like people tend to segment into like roughly speaking two camps. So the product first people who care about user impact, they gone into computer science because of the things that computer science can do for people and then the second camp which is code first people who are really excited about the code itself and really excited about pushing the limits of of code and they tend to map to more infrastructural problems.

and it was only after I got that opportunity and I I I I advocated for joining the news tab team, the Robin Hood news team that I finally saw like wo like I actually really love so solving user impact problems and user problems and then while solving the user problems I get to use tools like back end and front end and it didn't matter to me which one I was using as long as I was solving the problem of like the user which is what news do I see and how does it look

As a founder yourself, I assume at some point you will hire product engineers if you're not already hiring. But what would you look for like outside of the like this person can code and you know has the basics, but what what what are the things that will tell you if like okay this person would be good at product engineering versus just maybe not as much.

**Michelle：**一个关键信号是他们是否曾在本质上是“产品优先”的公司工作过。比如，如果他们曾在 Figma、Notion 或 Slack 这样面向用户的 SaaS 工具公司工作，你就知道这些公司非常注重产品优先的思维，并且他们选择的员工也是产品优先的。

**Michelle：**在面试中你也能看出来。当你问他们在之前的工作中做了什么时，有些人会大谈特谈那些很酷的技术，而另一些人则会关注业务问题，比如：“我们每年在亚马逊上浪费了 70 万美元，所以我们必须迁移到自己托管的开源 Presto 上。” 他们会从用户的角度来谈论问题，并且能够根据用户可见的里程碑来规划产品。

从创始工程师到创始人

**主持人：**你当过创始工程师，现在是创始人。显然你也在招聘创始工程师。你认为产品工程师和创始工程师有何不同？

**Michelle：**这是个好问题。我想说，创始工程师和产品工程师是不同维度上的概念。你可以是创始产品工程师，也可以是创始基础架构工程师。或者你可以是后期阶段的产品工程师、后期阶段的基础架构工程师等等。我认为，如果你是在公司成立头几个月内加入的前五名左右的员工，就可以算作创始工程师。而产品工程师，在我的定义里，是热衷于解决用户问题，并且能够全栈实现解决方案的人。

**主持人：**在你现在的初创公司 Flint，你们使用 AI 的程度如何？

**Michelle：**哦，一直都在用。现在使用 AI 编码几乎成了一项要求，因为这样你能更高效。我们总是在用 Claude。

**主持人：**你还用 IDE 吗？还是不怎么用了，只用来审查代码？

**Michelle：**我们在 IDE 内部使用 Claude。我们用的是 Cursor，还有一个工程师只在 Vim 上编码，所以他在 Vim 上用 Claude。

AI 创业潮中的风险与机遇

**主持人：**你之前提到了一些警示故事，关于加入早期初创公司，尤其是 AI 初创公司时，一些工程师可能会感觉被创始人“坑”了。现在 AI 初创公司和创始人都呈爆炸式增长，你看到或听说过哪些负面模式，以及如何避免它们？

Michelle：是的，我从朋友那里也感受到了很多。人们特别担心创始人可能会被大公司人才收购（acquihired: 指公司收购的主要目的是获得其员工，而非产品或服务），然后成为公司里唯一从这笔交易中获得金钱利益的人。

**主持人：**是的，我们已经在新闻里看到过一些创始人被挖走，而团队却被晾在一边。

**Michelle：**这正是人们非常害怕的具体情景。我有个朋友告诉我，因为所有这些创始人的股权收购事件，她决定干脆加入 OpenAI，因为那里更安全。我认为关键在于真正了解创始人的品格。一个很好的了解创始人的方法就是做背景调查。这个人品格好吗？对员工慷慨吗？关心团队吗？

**Michelle：**另一个很好的判断标准是看创始人自己是否也曾是创始工程师。因为那种亲身经历和同理心，是你除非也经历过成为创始工程师的洗礼，否则无法获得的。

Flint 的愿景：构建自主优化的智能网站

**主持人：**说到你的初创公司 Flint，你能谈谈你是如何想到围绕网站这个点子的吗？以及你认为这些 AI 代理将如何改变世界和网络？

**Michelle：**网站本身将变得具有代理性（agentic），它们会自我构建。这意味着，如果你早上醒来发现竞争对手连夜推出了新产品，你的网站可能已经为你生成了一个对比页面，将你与竞争对手进行比较，并且已经在优化转化率，同时每天跟踪你和他们产品之间的差异。

**Michelle：**过去需要五个代理机构花三个月才能完成的事情，现在在你睡觉的时候一夜之间就完成了。我们还考虑自动化所有其他相关的营销工作流程。比如，我们可以接入你的销售电话和 Gong 的通话记录，然后找出你可能缺失的销售产品或解决方案页面。

**主持人：**哇，这真是下一个级别的技术。

**Michelle：**是的，我们正在为网络带来自主性。我们正在构建一种新的互联网，网站不仅由 AI 生成、为 AI 服务，而且它本身也正在变成 AI，变得更动态、更主动。我的联合创始人曾在自动驾驶汽车公司 Neuro 负责团队，我们经常讨论自主网站与自动驾驶汽车的相似之处。它们都通过感知系统接收数据，然后有一个决策系统来决定该做什么，最后通过一个控制系统来实际执行页面构建。通过将所有这些感知、决策和控制系统整合到同一个实体中，我们最终闭合了反馈循环。

给未来创始工程师的建议

**主持人：**对于那些希望作为创始工程师加入 AI 初创公司或快速增长的初创公司的软件工程师，你有什么建议？

**Michelle：**关键在于展示你曾经构建过 AI 产品，因为这项技能现在需求量很大，而且非常新。相对而言，很少有人真正构建过 AI 产品。所以，只要花一些周末时间，学习如何构建一个 AI 产品，就能让你在众多人中脱颖而出。

**Michelle：**在那个职位上要取得成功，首先要选择对的创始人。但一旦你加入了，关键就在于主动去做那些没人想做，但对业务最重要的事情。

**Michelle：**我做过大多数工程师会认为是最糟糕的工作，那就是在 Warp 担任公司在 Hacker News 上的代言人。我写博客文章，把它们发布在 Hacker News 上，并回答上面的所有问题。我还创建了公司的 Twitter 账号并撰写推文，为公司开设了 YouTube 频道，创建了 Discord 频道，整理所有反馈，启动了 GitHub 项目——这些都是工程之外但业务非常需要的事情。

**主持人：**而且你还在做你的工程工作，对吧？你还在修复 bug 等等，但在此之上，你还在想办法帮助公司。

**Michelle：**是的，你仍然要确保做好你的首要工作，也就是软件工程。只有在你的主业已经做得很好的情况下，才应该主动去做其他事情。做这些事情的好处是，你能学到企业需要什么。

**Michelle：**有一次，因为我做了所有这些事情，还招聘了所有增长团队的人，我记得在一次董事会会议后，我的创始人找到我说：“嘿，Michelle，你招聘了所有这些增长团队的人，我希望你来担任增长负责人，从现在开始，你将负责组建和管理这个团队。”我当时大概 22 岁，突然就成了高管，突然要每季度向董事会汇报数字和收入。除非你主动去做那些没人愿意做的杂事，否则你不会得到这样的机会。

**Michelle：**最终，我甚至开始负责 Warp 的企业销售。因为我们遇到了一个问题，开始收到很多使用 Warp 的公司的安全调查问卷。我看到这个问题时想，哦，这不是一个安全问题，这是一个企业销售的机会。这是一个对话的开始，如果我们有企业级协议，我们就可以填写你们的调查问卷，提供 SOC 2 报告和所有这些合规控制及管理面板，只要你们付给我们相应的费用。

**Michelle：**正是做这些非常不光鲜、没人愿意做的事情，才能真正帮助你在公司里脱颖而出。因为不知不觉中，你可能就因为没人愿意处理安全调查问卷而开始负责企业销售了。那是个烫手山芋，在多个季度里被传来传去，直到传到我手里。

快问快答

**主持人：**作为结束，我们来做一些快速问答。我问一个问题，你告诉我你首先想到的是什么。

**Michelle：**好的，听起来很棒。

**主持人：**你最喜欢的编程语言是什么，为什么？

**Michelle：**哦，Rust。每次通过借用检查器（borrow checker）时，我都会感到非常满足，因为写出能编译通过的代码非常困难。

**主持人：**在 Flint，你们也用 Rust 吗？

**Michelle：**Flint 是一个 TypeScript 技术栈的公司。我们正在构建自主网站，以及能够自我构建的网站，所以用一种能够构建网站的语言会很有帮助。

**主持人：**你有什么推荐的一两部电影吗？

**Michelle：**我非常喜欢《Weapons》。它表面上看起来像一部恐怖电影，但实际上非常有趣。里面有很多喜剧元素，我也很喜欢它的非线性叙事。

**主持人：**Michelle，感谢你来到我们的播客。看到你作为一名创始工程师能学到这么多，以及如何做到这一点，并最终创办自己的公司，用 Flint 做着超级激动人心的事情，这真的很有趣。祝你好运，祝 Flint 一切顺利，感谢你的到来。

**Michelle：**非常感谢。