From Engineer #1 at Warp to Founding Flint: Michelle Lim on Early-Stage Startup Engineering
The Pragmatic Engineer
Michelle Lim joined Warp, the terminal company, as its first engineer. At the time the company had two people, a set of design mocks, and no code. She had offers from fast-growing Series A startups and a return offer from Robinhood. She is now the founder of Flint, a startup building what she calls "autonomous websites," and she is hiring founding engineers herself. In this conversation on The Pragmatic Engineer podcast, she explains why she took the riskier path, how she negotiated equity, why she asked her future CEO for references, and why she thinks the best way to excel as a founding engineer is to take the work nobody else wants.
From almost-doctor to debugging enthusiast
Lim came to programming late. In college she joined an entrepreneurship club while working on a bio company. Each week she noticed that the club's teams making the most progress were the ones with programmers. She concluded that if she wanted to move faster as an entrepreneur, she should be able to build things herself. She took her first computer science class in the spring of her freshman year and then switched her major to computer science.
Her favorite part turned out to be debugging, which she ties to an earlier plan. Growing up in Singapore, she almost became a medical doctor, the expected path for someone good at the sciences. What drew her to medicine was differential diagnosis: tracing a swollen left leg to a problem in the right lung, or tracing a particular visual symptom to a specific part of the brain. In her computer science assignments she found the same satisfaction. Bugs followed patterns, and she could trace them back to specific lines of code or systems. She describes feeling "almost like I was a doctor for the computer."
Internships: São Paulo, Facebook University, and a receipt-splitting app
Her first internship came through a university program that placed students at tech companies. She worked at a healthcare company in São Paulo, Brazil, where a very senior developer taught her much of her early software engineering. She encourages students to contact their careers office, since such programs can help with a first placement.
She got to Facebook through Facebook University, a program for students who are underrepresented and new to computer science. It began with a two-week boot camp in which participants built an app every day. This was before AI coding tools, so she was writing Android apps in Java by hand. After the boot camp, interns were grouped into pods and had to ship a fully working app by the end of the internship. That was where she first learned Git, collaborated with other developers, and learned to read large codebases.
Her team built a receipt-splitting app. It used OCR to read receipts and Bluetooth to find nearby friends. Users dragged friends' avatars onto receipt line items: if there were three broccolis and one person ate two, that person's avatar was dragged onto the item twice, and the bill split accordingly. Receipt splitting was a personal pain point for her. Building the app forced the team deep into Google's open-source OCR libraries and a Bluetooth protocol they found online. The team won recognition as one of the best apps in the program and met Mark Zuckerberg in his office.
Slack: product ownership and a CEO who answered feature requests
Lim joined Slack as an intern through the Kleiner Perkins fellowship, which places students at the VC firm's portfolio companies for a summer. Slack had about 1,200 people then, and nobody she knew was using it. It felt like a startup to her, though she acknowledges it would not be called one in retrospect. The host added that Slack still behaves more like a startup than many companies.
What stood out was how much product ownership everyone had and how the team used the product they were building every day. When she wanted a faster way to react with emojis, she designed a "frequently used emoji" feature herself and posted it in a feature-request channel. Stewart Butterfield replied that they should do it. She also proposed scheduling messages so she wouldn't have to wait until the right moment to send one. Butterfield rejected that as unnatural and said Slack would never do it. She found the culture energizing because the CEO was so engaged with the product. The host noted that accessible founders make a big difference between companies. Lim said that as a founder she now makes a point of being generous with her time for her team.
Robinhood: finding her sweet spot on the news tab
She found Robinhood through a tech fair, and it was there that she says she found what she loves in software engineering. Robinhood's app had three tabs then: the main portfolio/trade tab, a settings and notifications tab, and a news tab in between. She was one of five or six people on the news tab and was responsible for deciding which news appeared in each user's feed. The host pointed out that this was a feature used by millions of people making decisions based on it. She was 19 or 20.
The technical side involved Robinhood's version of Kafka for data pipelines. The team had to parse video and news feeds from partners such as Bloomberg, tag the items, and combine those tags with what each user was invested in to decide what was relevant. They also had to handle sparse feeds and avoid biasing the feed in ways that would corrupt the machine-learning ranking. If ranking were too prescriptive, she explained, the model would only receive biased data about which items were most interesting.
What made the work satisfying was that she was using interesting computer science concepts and also deciding product requirements at the same time. She had to weigh what users wanted, what was feasible given the business partners and tech stack, and what latency constraints allowed. She says this activated "all parts of my brain," and it convinced her that software engineering was where she wanted to be.
Shrinking companies, growing ownership
Asked whether she loved software engineering or startups, Lim said both. She points to a pattern across her internships: Facebook at about 12,000 people, Slack at about 1,200, Robinhood at about 300. Each time the company shrank by roughly an order of magnitude, she felt much more ownership, and the line from her work to user impact became clearer. After those three steps, she says, the obvious next move was joining a two-person company and then starting her own.
Warp before it had a name or any code
When Lim joined Warp, there was no code. The first hire had been a designer, and the company had polished mocks. It was also called Denver at the time, a placeholder while founder Zach Lloyd thought about names. Lim recalls pointing out that "Denver terminal" was a poor choice for SEO; she says she already had strong growth intuition then.
She describes the key mock this way: the terminal input was anchored at the bottom of the window, the cursor was a blinking line instead of a rectangle, and inputs and outputs were grouped into "blocks" separated by lines. A second mock showed collaboration, with different avatars on terminal blocks so several people could look at the same terminal, which she compared to Google Docs or Figma. A third idea was sharing environment variables and presets across teams. Lim noted that people often end up sending environment variables through Slack, which is a bad practice. The host summarized the vision as taking a tool that had existed forever and innovating on it, all before the AI wave.
Why she chose the riskier offer
Everyone wanted engineers then, and Lim had options. She had not planned to join a company as small as Warp. Her search had focused on Series A teams of 15 to 20 people, and some of her offers were from companies that already had $10 million in ARR and were growing fast. The appeal of such a "rocket ship," she said, is that there is always more work than people, and therefore more opportunity.
But after talking with Zach, she kept thinking about the product every day and how to improve it. Two experiences had convinced her that improving the terminal mattered. The first was business impact. In summer 2018, Slack had multiple outages as it began onboarding enterprise clients like IBM and Disney. Code that worked for selling to startups, such as double-nested loops, broke at that scale. Many internal tools ran through CLIs, commands were shared over Slack, and there was an ops rotation. She saw that better terminal tooling could have a real effect.
The second was accessibility. As someone who had only recently learned computer science, she saw the terminal as a big barrier for students. Computer science is already intimidating, she said, and it is even worse to find that the mouse doesn't work when you try to move the cursor within a command. If you could click to move the cursor instead of memorizing Ctrl-A and Emacs shortcuts, coding could become more accessible. The combination of revenue potential and social impact was compelling to her. She could always find a job at a $10 million ARR company, but it was rare to catch the window when an interesting company was just starting and be its first engineer.
The third factor was learning. Zach had been a principal engineer at Google and a former CTO at Time magazine. Some of her friends were doing master's degrees to become better engineers; she saw the chance to go through "Zach University" instead. He reviewed all her tech docs and pull requests, and she says she became a strong engineer very quickly. Her gut agreed. The night before deciding between the fast-growing company and Warp, her stomach was upset, which she attributes to the dissonance between what she was about to do and what she really wanted.
Negotiating equity: trading cash for ownership
Lim says negotiating equity is extremely important. She pushed hard for as much equity as possible and was willing to give up cash. Warp presented its offer as a spreadsheet with three options, each with higher salary and lower equity. She liked the format so much that Flint now uses it, with credit to Zach for letting her reuse it. Flint's version calculates what the equity is worth in compensation terms, accounts for tax and dilution at each stage, and includes a calculator for the expected value of the stock across different outcomes and their likelihoods.
She chose the option with the most equity and asked to go very low on cash. Her method, which she admits could be seen as a bad negotiation strategy, was to tell Zach she really wanted to work with him, that she would sign, and that she would appreciate using a different number. Conventional advice says this gives away your leverage, since competing offers are the usual way to raise an offer. Lim's view is that at a company with one or two people, it means a lot to the founder that you are fully committed, and the founder wants you to be happy with the deal.
The host agreed that most online negotiation advice is written for negotiating with faceless corporations, where the hiring manager or HR person doesn't own the outcome. At a tiny startup, the founders care personally, and good founders often won't make offers to people who don't believe in what they're building.
Asking the founder for references
Companies usually ask candidates for references. Lim reversed this. She pulled up the email she sent Zach and read it: she was happy to send her own references, and she also wanted to learn what he was like as a manager. She asked for references from people he had managed, especially when they were junior engineers.
Her reasoning is that people leave managers, not companies, and at a startup you can't switch teams or managers the way a friend at Google might. You are "married to that manager," so you need to learn as much as you can beforehand. Engineers have leverage because good ones are in demand, she says, but it is hard to judge from the outside what working at an AI startup will be like.
As a more junior engineer, her main concern was whether the company would promote and mentor young people. She has seen friends who were among a company's first ten employees get replaced by executives once the company succeeded, never promoted beyond entry level despite the youth and energy they had invested. So she asked references about opportunities for junior people, career conversations, promotions, and what things were like during hard times. Zach, she says, exceeded every test. She spoke to two engineers who had worked for him as new grads or interns and quickly became directors of engineering on Google Sheets. She later saw the same pattern at Warp, where new grads became tech leads and ran critical project streams.
She added that even if you aren't using the references to evaluate the founder, you can use them for advice on how to work well with that person, such as insisting on weekly one-on-ones or asking for feedback in a particular way. Framed that way, she says, asking doesn't hurt.
What she looks for in reference checks as a founder
Lim calls reference checks the most important part of any interview process, sometimes more important than the onsite. At Flint she always does them. Her key question is whether the reference would want to work with the candidate again. She isn't looking for "yes"; she's looking for "hell yes," the kind of answer that asks why she is even asking and how she managed to attract that person. Lukewarm answers like "they could be great" or "they're very strong" fail her test. A one-day work trial is a good approximation, she says, but it is not the same as working with someone over time.
Warp's stack: from TypeScript to Rust
Warp's first codebase was TypeScript. Two to three months in, the team scrapped the repository and rebuilt everything in Rust. Lim gives two reasons: performance and speed of development. TypeScript code was fast to write, but the team then spent many cycles stress-testing it against performance constraints. In one test she drew a thousand rectangles in the JavaScript app and scrolling broke. Terminals must render large volumes of output quickly, so that was a serious problem.
There was also a market reason. Lim says developers strongly preferred high-performance terminals built at a low level. Even if two apps were identical, the one written in Rust would spread better and be loved more. The Rust community was small then but growing fast and very passionate, so building in Rust also mattered for marketing.
When the team switched, Zach sent everyone the O'Reilly Rust book: Lim, the other founding engineer, and himself. They read it daily, and each time they learned something new they rewrote earlier code, for example removing the many unwrap calls. They also worked with Nathan Sobo, creator of the Atom editor who later started Zed. He had extensive Rust experience and pair-programmed with Lim every day. She credits him with teaching her idiomatic Rust and many small ergonomic habits that made a big difference in using the IDE.
Product-first versus code-first engineers
Years before "product engineer" became a common term, Lim wrote about splitting engineers into product-first and code-first. Product-first engineers are motivated by user problems and treat technology as a means to user impact. Code-first engineers are excited by the code itself: performance, the best libraries, elegance. They tend to fit infrastructure work. She thinks this split describes engineers' mental models much better than front end versus back end.
Her internships illustrated the mismatch. In one front-end role she was given mocks to implement and couldn't solve user problems. Thinking back-end work might suit her better, she was placed on infrastructure in another internship and spent two weeks migrating from Amazon Athena to Presto, writing SQL and migrating database roles. It was closer to the metal, but she couldn't see how it solved any user problem, and it made her wonder whether she wanted to be a software engineer at all. Only after she pushed to join Robinhood's news team did she find that she loved solving user problems. Front end or back end didn't matter as long as she was answering the user's question: what news do I see, and how does it look?
How to spot a product-first engineer
The host noted that many startups now hire specifically for product engineers. Lim named several signals. One is whether the candidate worked at a product-first company, such as a user-facing SaaS tool like Figma, Notion, or Slack, since those companies select for product thinking. Another is how candidates describe past work. Some dwell on the technology: the task was hard for various reasons, they tried one library and it failed. Others lead with the business problem. Her example: the company was leaking $700,000 a year to Amazon, so it moved to its own self-hosted open-source Presto, and here is what happened to the business.
At Warp, the interview process included a product round. Candidates were asked what they would change about the terminal or about an app they already use. The best candidates had an opinion on how to improve the product, could explain it from the user's perspective, and could break the work into user-visible milestones. Given a hundred tasks, they would group and sequence them so users saw a difference at each milestone, instead of spending 60% of the time on performance or latency work users wouldn't notice until a front end was added.
The host suggested that engineers without this product bent may fit better in infrastructure, or at companies where product managers handle those decisions. Lim agreed that such roles are important, especially at scale, where performance, memory, and infrastructure choices matter a great deal. But early startups rarely face that kind of scale and need people who can plug every hole in the company.
Founding engineer and product engineer are different axes
Lim sees "founding" and "product" as separate dimensions. You can be a founding product engineer, a founding infrastructure engineer, a later-stage product engineer, and so on. Definitions vary, but hers is that a founding engineer is roughly one of the first five people to join within the first few months. A product engineer is excited about solving user problems and is full stack enough to do so, whether through front end, back end, end-to-end work, AI, or infrastructure, using whatever tools fit.
She adds a caveat for job seekers. Many startups now use "product engineer" as a synonym for front-end-only engineering, since nobody uses the term "front-end engineer" anymore. She advises reading job descriptions closely, because not every "product engineer" posting means what she means.
Pair programming and AI coding at Flint
Asked whether AI tools will reduce pair programming, Lim said that everyone is now pair programming with an AI, and having a bot to talk to gives everyone a daily rubber duck, which makes everyone better. She also sees the return to office creating more chances to sit next to colleagues and learn how they use their tools. Warp was remote-first, and during its first two years, in the 2020 era, she says she never met Zach in person.
At Flint, using AI to code is "almost a requirement" because it makes people more productive. The tool she always reaches for is Claude Code. The team runs Claude Code inside the IDE, Cursor in their case, and one engineer who works only in Vim uses Claude Code from Vim.
Avoiding getting burned when founders exit
The host raised a worry now common among engineers at AI startups: that a founder gets acqui-hired by a larger company and is the only one who benefits financially, leaving the team behind. Lim says she hears this from many friends. One told her that because of these founder hires, she would join OpenAI instead because it was safe.
Lim's answer is to understand the founder's character. Reference checks help show whether the founder is generous and cares about their team. Another signal is whether the founder was once a founding engineer. That experience, she argues, builds empathy you can't get otherwise: living through the day with no code, the first code, the days without users, and the first user. From that position, she says, she can't imagine not offering secondaries, tender offers, and opportunities to the people who trusted her with their careers.
The host suggested asking directly in interviews: if the founders take secondaries in a new round, will employees get the same chance? If there's an acquisition, will the team come along? The answers aren't binding, but asking gives you a data point. Lim agreed that candidates have the leverage to ask now. She added that the content of the answer matters less than whether the founder has clearly thought about it before. When she asked Zach about early employees, his answer was obviously the product of years of thinking. A less thoughtful founder might give a good-sounding answer that was clearly made up on the spot.
Hiring world-class engineers
On the founder side, Lim says attracting top engineers in Silicon Valley comes down to two things. First, showing that you care deeply about the team, that you value them, and that there is enough trust for them to believe you will do whatever it takes to make sure they have a good experience. Second, having a big vision for how the company will change the world, so that joining is a chance to do exactly that.
Flint: websites that run themselves
Flint is building websites that are agentic and build themselves. Lim's example: if a competitor launches overnight, your website will already have generated a comparison page, optimized it for conversions, and will keep tracking product differences daily and updating the page. She says work that would take five agencies three months happens overnight. Flint also plans to automate the surrounding marketing workflows. For example, it could connect to sales calls, including Gong recordings, to identify selling angles or solution pages the company is missing.
She describes this as bringing autonomy to the web: a website not only generated by AI and for AI, but becoming AI itself, more dynamic and proactive. Her co-founder ran teams at Nuro, an autonomous-vehicle company, and they compare autonomous websites to autonomous vehicles. A perception system takes in data, a decision-making system decides what to do based on competitors or sales calls, and a control system implements the pages. The loop then repeats based on how the page performs in its environment, the market. Five agencies were needed before, she argues, because the tools and specialties were separate and information had to be passed between them. Putting perception, decision, and control in one entity closes the feedback loop so the website continuously optimizes itself for the business.
She outlined a roadmap. Phase one is responding to the market using real-time data streams. The next phase is real-time morphing of pages depending on the visitor. If a healthcare executive arrives, the page could emphasize healthcare case studies and compliance requirements, and could even generate a tailored sales demo on the spot instead of making the visitor click "contact sales" and wait a week for a Zoom call. If the visitor is an AI agent, the site could respond in the formats agents prefer, such as MCP, tool calls, APIs, Markdown, or JSON, rather than HTML. Lim says Flint is building a new agent-to-agent protocol for how agents interact with the web. She also described an "agentic web" in which, instead of finding links through Google, agents talk to each other to establish which agents are more credible and quickly work to close a deal for a customer.
One problem she calls almost research-level is generating on-brand landing pages. It might seem like choosing a background color and typography is enough, but she says brand matters a lot now. A SaaS company wouldn't show a generic AI-generated page to a Fortune 500 prospect it is trying to close. Flint says it can produce pages that match a customer's brand down to the pixel, as if the customer had built them. She cited work with Cognition on its events pages and on comparison pages between Windsurf and Cursor, which she says are being cited by LLMs.
Advice for aspiring founding engineers
For engineers who want to join an AI startup as a founding engineer, Lim's first tip is to show you've built with AI before. The skill is in high demand and relatively few people have shipped an AI product, so spending some weekends building one, anything that uses model completion APIs to scratch your own itch, already sets you apart.
To excel once you're in, start by choosing the right founder, then volunteer for work nobody wants that matters most to the business. At Warp, she took what she says most engineers would consider the worst job: being the company's face on Hacker News. She wrote blog posts, published them there, and answered every question. She created the company's Twitter account and wrote its tweets, started a YouTube channel before most developer-tool companies thought of it, started a Discord, filed user feedback, and set up the GitHub presence. She stresses that engineering must remain the main job, and you should only take on extra work if you're already doing well at it.
The payoff was twofold. First, she learned what businesses need, which helped her come up with ideas beyond developer tools. Second, responsibility compounded. After a board meeting, Zach told her that since she had hired all the people in growth, he wanted her to be head of growth and manage the team. She was about 22 and suddenly reporting to the board every quarter on numbers and revenue. She says the key is to do each of these tasks exceptionally well, so the founder knows that anything handed to her will be done excellently.
Eventually she led enterprise sales at Warp. The company had started receiving security questionnaires from companies using the product, and the task had been passed around like a hot potato for several quarters until it landed with her. She reframed it: this wasn't a security problem but an enterprise sales opportunity. A questionnaire could be the start of a conversation in which, for an enterprise contract, Warp would fill out questionnaires and provide SOC 2 reports, compliance controls, and an admin panel. The host observed that juggling so many responsibilities is also preparation for being a founder. Lim agreed that the job of a founder or manager is to take the things nobody wants to do so everyone else can stay in their "zone of genius."
Rapid fire: Rust and a horror movie
Her favorite programming language is Rust. She enjoys the satisfaction of getting code past the borrow checker precisely because it's hard. Flint, however, is a TypeScript shop, since it helps to build websites in the language websites are built with. When the host predicted Rust would find its way in eventually, she replied, "We'll see."
Her movie recommendation was Weapons. It looks like a horror film but has many comedic moments. She liked its nonlinear structure: the story concerns children who ran out of their homes at 2 a.m. and disappeared for a month. Each chapter shows a different character's perspective, which changes how you see the story and nearly changes the genre each time. As a horror fan, she also noticed that each chapter's character fits a different horror-movie trope. The host, not a horror fan, said the film was memorable and still gives them shivers.
In the closing remarks, the host highlighted Lim's willingness to take on unattractive work, which the host connected to her work on marketing websites at Warp and the expertise behind Flint. The host also noted her view that generative engine optimization, meaning LLMs recommending websites, may soon matter more than traditional search engine optimization, and suggested that being a strong founder likely requires understanding parts of the business well beyond software engineering.
I did my internships from 12,000 people to 1,200 at Slack and then 300 at Robinhood. And I found that every time I went down roughly an order of magnitude, I felt way more ownership. Obviously, the next step is starting a two-person company and then starting my own.
The stack at Warp actually first started out with TypeScript. And then 2 to 3 months in, we decided to scrap that repository and just rebuild everything in Rust.
I have to ask why.
It was for performance reasons and it was also speed of development. There was also a very strong sentiment amongst developers that they would only use high performance terminals that were built at low levels.
How do you think a product engineer versus a founding engineer differs?
I think founding engineer counts if
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 little-known startup when she had better paying and safer options. Thriving as a founding engineer and why 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.
This podcast episode is presented by Statsig, the unified platform for flags, analytics, experiments, and more. Check out the show notes to learn more about them and our other season sponsor. 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, 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 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. 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. I grew up in Singapore, where that was the thing to do if you're good at the sciences. And I really fell 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 almost like I was a doctor for the computer, and it also helped me a lot in terms of being able to build things, which I really love. I started interning at tech companies and really fell in love with the art of software engineering, and that just further validated that I really love software engineering.
And then you interned at some really cool companies. I think it was Meta, Slack, Robinhood. How easy or hard was it to 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 have had this university program where they actually placed students in tech companies. And my very, very first internship actually was in São Paulo, Brazil, where I was working as an intern for a healthcare company. And that was where I really got my start and really learned software engineering from a very senior developer there in Brazil. So I'm very thankful for that. And for the listeners who have university programs, who are in school, reach out to the careers office. They could be really helpful in helping you get your start.
For Facebook, it was also me cold applying to the website, to this program called the Facebook University. So this is for folks who are underrepresented and who are new to computer science, and they bring you into the program and then bring you through a two-week boot camp where you're building an app every single day. So there, every single day, I was
This is pre-AI, right?
This is pre-AI. So I was using my hands to write Android apps in Java, and so every day we were building apps, and then after the two-week 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. I learned how to read really large code bases, because we were building a receipt splitting app through OCR as well as Bluetooth, where you could find your friends near you and then drag and drop avatars into the receipt items. So if there are three broccolis and you ate two broccolis and I ate one broccoli, I would drag your 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 the open source libraries of the OCR from Google as well as a Bluetooth protocol that was online. So, I became really good at that. And I was also very fortunate that our team actually won for being one of the best apps in the internship program.
Awesome.
And got to meet Mark Zuckerberg in his office.
Wow. So after a Facebook internship, you ended up working a little bit at Slack and at Robinhood as well, right?
Yeah, that's right. And that was where I really caught the startup bug. So I joined Slack through the Kleiner Perkins fellowship program. So this is a fellowship program for students to intern over the summer with the portfolio companies of this VC called Kleiner Perkins. And at the time no one I knew was really using Slack. It was only 1,200 people at the time. And I was really excited about the chance to see what this whole startup scene was like. I mean, at the time I considered Slack a startup. Looking back, it's not a startup, but it felt like a startup to me, someone who at the time wasn't really familiar with tech companies. And I had such a good time at Slack.
And I think we can also be fair, like, sure, Slack today is maybe not a startup, but compared to a lot of companies they still act way more like a startup even today.
Oh yeah, 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, I would start using a feature, then I would be like, oh, I think that instead of me having to search through my emojis every time I need to react, what if we put a frequently used emoji section? I'll design it myself, post it in this feature request channel, and Stewart Butterfield at the time responded, being like, yes, we should do this. And then I had another idea around scheduling messages so that I didn't have to wait till the time I wanted to send a 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."
But that's really cool, getting feedback straight from the CEO or co-founder. That's awesome.
That was such an awesome culture to be in, where the CEO was so excited about the product.
I feel the culture talks a lot, you know, both at Meta and at Slack. The fact that the CEO and co-founder is open to talking. Okay, they're not going to spend the whole day, you know, talking with interns or new joiners, but they do and they're accessible. I feel that's going to make a big difference between, you know, some companies and then other companies where this is impossible.
Absolutely. Yeah. Especially now as a founder myself, I always make sure to spend a lot of time and be generous with my time with people on my team.
And then what did you learn at Robinhood?
So Robinhood I found through a tech fair. Robinhood was where I really found my sweet spot about what I loved to do in software engineering. I was working on the Robinhood news tab. So this is a tab that let users see the news for the day and how that would, you know, affect their stocks. And at the time, Robinhood only had three tabs. The first tab was the main tab, you know, trade
Portfolio, trade. Yeah.
And then the third tab was settings, so notifications, and I was working on the second tab. It was maybe five or six of us working on that main tab, and I was in charge of deciding what news to show on every person's feed.
Yeah. And this is millions of people using it, right? And making decisions based on that. This is not some hidden feature.
Yeah. And I was 19 or 20, very young, and they gave me that opportunity to build that. And I really found my sweet spot in that I felt like I got to work on very cool computer science concepts, like we were using Robinhood's version of Kafka to do the data pipelines when we received
For messaging.
Yeah, for the messaging, because we had to parse the video feeds and the news feeds coming from a lot of our partners. Like, Bloomberg was selling the news to us, and then we had to tag them, and then based on the tags as well as what the users were invested in, figure out what are the relevant news, what to do if it's too sparse, how do you populate the feed such that there's no bias for machine learning, because we also wanted to keep learning what to rank first. And if you had a very prescriptive way of ranking your feed, then you would just be giving biased data to the machine learning algorithm for deciding what is the most interesting item. So to me, that was really exciting because, one, I was learning a really cool computer science concept, but then, two, I was also deciding a lot of the product requirements. You know, what does the user want, but then what is technically feasible based on the business partners we had, based on our tech stack, and then based on latency requirements. So I felt like I was able to activate all parts of my brain, thinking about the technical side but also the product side. And because of that, I felt like, oh, I really love software engineering, this is where I want to be.
Do you love software engineering, startups, or both?
It was actually both. Facebook, Slack and then Robinhood actually became smaller and smaller as I did my internships.
Yeah. From 12,000 people to 1,200 at Slack and then 300 at Robinhood. And I found that every time I went down roughly an order of magnitude, I felt way more ownership, and I felt like the line of sight between me building and the user impact that I was making was extremely clear. And so I knew, okay, now that I've done the 12,000, the 1,200 and then 300, obviously the next step is joining a two-person company and then starting my own.
And then Slack, did you work there after graduation or was that your last internship?
Robinhood was my last internship. Robinhood last.
Facebook, Slack and Robinhood were my internships.
Okay. And then, well, you had a healthcare company before.
And the healthcare company. Yes.
So it's incredible. You had four internships in, I guess, four different summers.
Three summers.
And in three summers you kind of had them together, which is amazing. And now 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 yet you decided to go into this company that at the time was completely unknown. It had just raised something. It seems like a pretty risky bet to go into an early-stage or seed-stage startup. Tell me, what was your thinking after this? Again, you've seen these different companies, and how did you end up at such a small company? It felt like taking a big risk, I'll be honest.
Oh yeah, it was a very big risk. There wasn't any code written yet at the time.
There was no code?
No code written.
So it was just an idea and a founder with an idea, or
There were very nice mocks. The first hire at Warp was actually a designer.
And then can you tell me what was the 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
No wonder it didn't stick.
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 a lot of growth intuition. But it was meant as a placeholder as Zach, the founder, was thinking about names. So the key mock was a terminal that had the terminal input 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 one. And then I think the second mock was collaboration. So we had different avatars on each of the terminal blocks. So it was almost like Google Docs or Figma, like, oh, you could have multiple people looking at this terminal. That's so cool. And then there was the concept of sharing environment variables and presets, because we all know it's such a pain to get environment variables, especially in teams. I mean, no one wants to confess this, but I'm sure everyone has had the experience of sending environment variables through Slack, and that's no good.
Yeah. And also, of course, 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 them into GitHub, but how do you transfer them? Yeah, exactly. Sharing those keys that should not be shared, because your colleagues or your teammates need them. So do I understand the vision was basically, hey, the terminal has been around forever, here's a couple of cool ideas on how we can innovate? And this was pre-AI, right? This is pre-AI.
Okay. But already that was the vision. Now can you tell me a little bit about, I feel not many people talk about this, especially when you're still earlier in your career, you're a new grad. Okay, you've had a couple of really cool internships, which means probably a lot more companies will be open 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 negotiating your first full-time compensation? Because I guess with internships you don't have much negotiation, but here you probably had some leeway.
Oh yeah, 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 there was no Kin. So my focus during my job search process was focusing on 15 to 20 people teams, Series A. I had a couple options that had $10 million ARR already. So, you know, I could join a rocket ship, see 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 Statsig comes in. Statsig built experimentation and feature management that acts as guardrails for AI accelerated development. Here's how it works. You ship a feature to 10% of users in a control experiment. Statsig automatically creates a control group and measures the impact. If the feature improves metrics, you confidently scale to 100%. If it would hurt metrics, you catch it early when it's only affecting 10% of users, not your entire user base. You're making data-driven decisions at the same pace you're shipping code. Companies like Notion went from single-digit experiments per quarter to over 300 experiments with Statsig. They shipped over 600 features behind feature flags, catching the ones that would hurt metrics early and launching the winners. This is the faster testing, validation, and learning loop that matters when you're shipping at AI velocity.
Most teams stitch together separate systems, wait on queries, and try to correlate user segments that don't match. By the time they know if something worked, they've already moved on to the next feature. With Statsig, you have everything in one place. Feature flags, experimentation, and analytics with the same user data. Statsig has a generous free tier to get started, and pro pricing for teams starts at $150 per month. To learn more and get a 30-day enterprise trial, go to statsig.com/pragmatic.
And now let's get back to why Michelle chose to join a very early stage startup.
So I actually had a lot of those options. But ever since talking to Zach, the founder of Warp, I kept thinking every day about the product and how we could make it better.
And it was just a product that I discovered that I had a lot of passion for because when I was doing the software engineering internships, I actually found that there was a lot of real business impact from improving the terminal. In the summer of 2018, Slack had multiple outages. That was the first time that Slack was bringing on new enterprise clients like IBM and Disney. And so the double nested loops that could have worked for selling to startups no longer worked at IBM and Disney scale. And so a lot of things were breaking. A lot of internal tools were run through CLIs. A lot of commands were being shared on Slack.
There was an ops rotation. And so I felt like
You were seeing the potential of how just, I know, sharing commands better, better tooling, a collaborative CLI, even at 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, because computer science is already so scary to learn for someone who's new to it, but what is even scarier is trying to move the cursor from one character on your command to another and realizing that the mouse doesn't work. I felt like there was also a lot of impact on society that can be made if coding was a lot simpler for everybody. If we could make a terminal more accessible, if you could move the cursor with your mouse instead of memorizing Control-A and Emacs shortcuts.
So it was like, okay, this business idea, there's a lot of business impact and potential revenue, and if we do well, we can make computer science a lot more accessible. When else can I join such a cool idea as the first engineer? I could always look for a job in any of these $10 million ARR, doubling 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.
The other thing was, 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? He's a longtime software engineer.
Yeah. Former CTO at Time magazine, and I felt like, you know, some of my friends would go study master's programs to be better at computer science. But here I had this opportunity to go through Zach University to become a really good software engineer very quickly, working directly with him. He was looking through all my tech docs, all my pull requests, and I just became a very good engineer very fast. That was how I made the decision. It was definitely very atypical. I could have gone back to Robinhood. I had that return offer. 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 honestly at most startups that either have venture funding or plan venture funding, a part of compensation is equity, which is always a bit of a tricky subject for most software engineers. How did you research equity? How did you learn about it? Did you negotiate it, or did you just kind of take 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 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?
I was presented a spreadsheet that had three options with increasing salary and decreasing equity. It was a really good spreadsheet, and I actually use this today, 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. We also calculate tax as well as dilution at every stage, and then we also have this calculator that helps you calculate the expected value of your stock based on different outcomes and the likelihoods of each outcome. And all credit is to Zach from Warp, who let me use this spreadsheet.
But anyway, there are three options, and 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. I will work with you. I will sign this offer. 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 negotiation strategy because you are losing all the cards by saying that you don't have any other options, and, you know, some might say the best way to increase your offer is by having competition. But I think that at early stage companies, where you're joining as just 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, you know, the general advice on negotiation that you read online, first of all, a lot of it is written for when you're negotiating against faceless corporations, where the person giving the offer, let's say an engineering manager or HR, they don't own this thing. They're given numbers and they have a job to do, which is close people, and they don't have too much emotion, and a lot of that advice will work there. But as you say, in a startup it's people, it's a very small team, the founders do care. And I will say this, a lot of good founders will actually just not make offers to people who they don't think believe in what they do, because it's so early. So I feel like what you did, of course, probably goes against all the advice out there, because the advice is not for this. I feel being authentic, being excited, I cannot talk for all founders, but I know some founders, and I do think this means something. And honestly, in the end, following your gut is a pretty good strategy a lot of times.
A funny thing about gut is that actually the day before the offer, I was making the decision. I had, you know, the $10 million ARR company that was doubling, and I had Warp. I was in Denver at the time, and my stomach was actually acting up the night before, because I think it was feeling the dissonance between what I was going to do versus what I really wanted to do.
Now, one thing I've heard that is also atypical and no one will suggest, but you still did it: you know, when a company makes you an offer, or before they make an offer, they often ask for references for you, to talk with other people. I heard you did that with Zach, Warp CEO. How did that happen?
Yeah, I actually pulled up the email before this, and I saw that I said, "Hey, Zach, really excited about this. Happy to send you my ref checks. I would also like to learn more about how you are as a manager. Can you send me references for people that you have managed before, especially when they were junior engineers?"
I mean, I would recommend everyone to do this, actually. They say you don't leave companies, you leave managers. And at a startup, you can't pick your manager, you can't leave a team. 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 reference checks are, by the way, the most important part of any interview process. Sometimes that is even more important than the on-site itself.
So at your current startup, you're also doing reference checks.
Always, always, always.
And what do you look for in a reference check now? Just kind of, you know, thinking a little bit as a founder, you've been on the other side, because I feel they are coming back, but I don't hear about it that frequently, and I don't think a lot of people know how to do it well.
If I, as a founder, am evaluating a candidate, 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 don't even know why you're even asking me this question. You're so lucky to have this person. I don't know what's happening in the waters of your company, but how are you able to pull someone like this?" That is what I'm looking for. If I'm hearing, "Oh, yeah, I think that they could be great," or, "Yeah, they're very strong," that to me is a bad reference check that does not pass my test. One day of a work trial is a very good approximator, but it's just not the same as working long term with someone. So this is very important.
I actually think that engineers have a lot of power and leverage, because for the good ones, a lot more people want them. But at the same time, it's very hard for you to assess what it is going to be like working at this AI startup, because it doesn't have that many reference points from the outside. So it's very important to assess how they are as a manager.
As a more junior person entering a company, I think one of the ways that you could have a bad time is if you join a company where they don't promote and mentor and grow younger people. I've seen this happen at my friends' companies, where they would be the first 10 people who built the company, and then as soon as the company does well, they're replaced by executives, and then they're never promoted beyond the entry level that they were at, even though they built the company and they spent a lot of their time and effort and youth and energy working on the company. So it was really important in my reference check to check how much opportunity someone young and junior got. What were career conversations like? How did promotions work? What was it like during the tough times?
And Zach exceeded all of the tests, in that I talked to two engineers that were new grads/interns working for Zach and then very quickly became directors of engineering at Google Sheets. So he was clearly someone who would bet on young talent and then help to promote them. And I saw that again at Warp, where a lot of younger new grads were given positions of tech lead or were able to run the most critical project streams at Warp, because Zach always bets on the young talent.
And I think in general, this sounds like a great strategy, asking for references from your future manager and asking them about what you care about. In your case, it was, can I have a career trajectory? If you're looking for, let's say, stability, maybe look for that. But I think it's just such an underrated thing. I haven't heard anyone else do this, so congrats on doing it and sharing it with us.
Yeah. The last thing I'll add there is that even if it's not for evaluation, it could be for advice. How would you be able to work with this manager best? Maybe it's insisting on the weekly one-on-ones, maybe it's about proactively asking for advice in this specific way. So it doesn't hurt you to do it, and you can always frame it as getting advice on how to work closer with them.
I love how Michelle shared the story of how Warp was founded and how she joined as a founding engineer. Talking about the founding of a startup touches nicely on the origin of our season sponsor, Linear.
The idea for Linear came about when their founders were going through hypergrowth phases at Airbnb, Coinbase, and Uber. As you'd expect with real scale, these companies started to slow down. What used to take days started taking weeks, sometimes even months. Not because people worked less hard, but because there were a lot more moving parts that needed to be coordinated. As an example, in the early days of Uber, it took a single engineer about 5 days to integrate, test, and ship a new payment method to the app, Google Wallet. But years later, it took around 2 months for three engineers on my team to build and release Google Pay, because there was so much more planning, coordination with stakeholders, working with other stakeholder teams and the vendor themselves. As teams grow in size, product development gets hit
particularly hard. Every team involved in the process using a different set of tools and workflows. This fragmentation means there's no scalable way to answer what has been committed, what's at risk, who's actually accountable, who are we building this feature for. It's often a total mess. The conventional approach is to compensate for tooling gaps with more headcount or with more status meetings, but in my experience, it doesn't help much. This is why Linear exists to give high growth teams the clarity and coordination they need without the overhead. Linear's founders build a tool they wish they had during those chaotic hypergrowth scaling phases. You can try it yourself at linear.app/pragmatic and see why teams like Ramp and Clay also switched over. And now, let's get back to Michelle and her time as a founding engineer at Warp.
When you joined Warp, 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 backend. Where did you end up in this sense?
So the stack at Warp actually first started out with JavaScript and then within
Not even TypeScript?
Oh, it was TypeScript.
TypeScript, okay.
And then 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 suspect why.
Yeah. So it was for performance reasons and it was also speed of development.
Yeah.
So while it was really fast to push out JavaScript code, we then needed to spend a lot of cycles testing, stress testing it against a lot of performance constraints. So, one thing I did with our JavaScript app was that I drew a thousand rectangles and then I started scrolling the terminal and the scrolling was breaking.
Yeah.
And it's extremely important for us to be able to draw a lot of rectangles because, yeah, like terminals output a lot of logs and everything needs to be really fast. There was also a very strong sentiment amongst developers that they would only use 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. Back then, like, the Rust community 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 really funny when we decided to build it in Rust and then Zach sent the O'Reilly Rust book to everybody. So me, the other founding engineer, a log, and him, and then we would just read every day and then every time we learned something new we're like, oh, let's rewrite what we wrote previously. There are way too many unwraps, so let's go fix that. We also had the privilege of working with Nathan Sobo, who was the inventor of the Atom editor and then eventually started Zed, 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 idioms that work really well.
I guess pair programming does work.
Oh yeah. I really enjoyed pair programming with Nathan because I learned a lot of like small ergonomic things that make a big difference in using the IDE. You asked a question earlier about product engineering versus infrastructure engineering, and I wrote a piece many, many years ago before the word product engineer even became in everyone's lexicon. Product engineering and product-first coding are people who are more motivated by user problems and excited about solving the user impact, and they see technology as a means to an end of user impact. And then there's the code-first people who tend to more map onto infrastructure engineering, where they're really excited about, you know, the best performance, the best libraries, elegance. I found through my Robinhood internship that I very much am a product engineer at heart, 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, because of the mental models of, like, people tend to segment into roughly speaking two camps. So the product-first people who care about user impact, they've 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 code, and they tend to map to more infrastructural problems.
When you split people up in front end and back end, it creates a mismatch in the mental models of people. Like, this is my experience. I was a front-end engineer at one of my internships and all I was given are mocks to implement, and so I wasn't able to solve problems for users. So then I felt like, oh, I want to go to backend engineering. And then in my other internship I was placed into infrastructure. So I spent two weeks migrating from Amazon Athena to Presto and all I did was write SQL and migrate database rows, and I was finally working on something that was closer to the metal, but also I wasn't really seeing how I was solving any user problems. And so it made me feel like, oh wow, maybe I don't really want to do software engineering. And it was only after I got that opportunity and I advocated for joining the news tab team, the Robinhood news team, that I finally saw, like, whoa, I actually really love 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 the user, which is what news do I see and how does it look.
And I really sense that product engineer is also a kind of a phrase that is now spreading across startups. So many startups are now hiring specifically product engineers. So it is happening. 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 outside of, like, this person can code and, you know, has the basics? What are the things that will tell you, okay, this person would be good at product engineering versus maybe not as much?
One key signal is whether or not they have worked for a company that was product-first in nature. Like if they had worked on more of a user-facing type SaaS tool like Figma, Notion or Slack, you know that those companies are very focused on product-first thinking and they pick people who are product-first. But then in an interview you can also kind of tell based on how the candidate answers questions. So when you ask them what they were doing at their previous roles, some people will focus a lot on the really cool technology and then others will focus on the business problem of like, oh, you know, we were leaking $700,000 a year to Amazon, and so it was very important that we migrated over to our own open-source hosted Presto, and then we did this and then this is what happened to the business. As opposed to like, oh, you know, it was very important for us to do this thing and it was very difficult because of XYZ reasons, and then we used this library but then this library didn't work. You could really tell the difference.
And it was very important also for our interview process to involve a product round where we asked people, you know, what would they change about the terminal, what would they change about a favorite app that they're already using. And then the best people who are thinking in terms of product, first of all, would have an opinion about how to improve a product, and second of all, would know how to talk about it from the user's perspective, and last of all, are able to create milestones in that product based on user-visible milestones. So if you have like a hundred things to do, how do you group and sequence the things to do in a way where at every milestone the user could see a difference, as opposed to maybe spending 60% of your time improving performance or latency that would not be seen by the user until this front end was added, for example.
Yeah. So I'm hearing that understanding the business, caring about the product, having a lot of things that we might have associated purely in the past with just product managers, having some of that is increasingly important. And, you know, for engineers who have none of it, that's also fine. But it feels like increasingly they might be a better fit for infrastructure work or places where you don't need to think about product, where there's someone, or a company where there is a product manager, and they take care of all of that and it's just implementation, which sounds a little bit less fun, but these places exist and there are engineers who appreciate this.
There are so many, I mean, and they're all extremely important. When you're at a company with a lot of scale, like, really, performance, memory, the infrastructure you use is so important. But then when you're talking about startups, you're just starting out, and so you need someone who is able to plug in all the holes in a company, and the scale at the very beginning doesn't tend to be something that requires that many billions of rows to handle, or requests per second to handle.
Yeah. So you've been a founding engineer, you're now a founder. Clearly you're also hiring founding engineers, and at Warp you also hired product engineers. How do you think a product engineer versus a founding engineer differs? Or do they? Is it just the timing or is it also a little bit of different personality or different kind of challenges?
Yeah, that's a very good question. So I would say founding engineer versus product engineer, they're different axes. So you could be a founding product engineer, you could be a founding infrastructure engineer, or you could be a later stage product engineer, later stage infrastructure engineer, later stage software engineer, AI engineer. I think that folks might differ on the definition, but I think founding engineer counts if you are in the first five or so that joins within the first few months of the company starting. A product engineer in my definition is someone who is excited about solving user problems and they are full stack in being able to do that. So they could go in and build a front-end feature, a backend feature or something that's end to end. They could also go into AI, they could go into infrastructure. They would use whatever tools in the tool belt of programming to solve the problem for the user. I think these days the way that startups are putting these job descriptions out, I think that they're actually more looking for purely front-end engineers. No one uses the term front-end engineers anymore. I think when someone is reading a job description, one should read it closely, because I think that a lot of startups here are using the word product engineer more as a kind of synonym for front-end only engineering. So not all of them mean the product engineer that we were talking about.
Yeah.
What do you think today at your startup, for example, now that we have all these AI tools? Do you think it's going to push us away from even pair programming, even if people are in the same space? Or do you think, you know, the people who still do it are actually going to benefit a lot from it?
I think almost like with the rise of AI, everyone now is pair programming with an AI, and having someone to talk to or some bot to talk to allows everyone to have a rubber duck every day, and that helps everyone get better. I think that with the rise of the return to office, there's also a lot more opportunities for sitting next to each other and just learning how people use their tools that we didn't get during the remote time, because Warp was remote-first and during the first two years I don't think I ever saw Zach in person.
Oh wow. Yeah.
Yeah. During 2020.
Of course, it was that time. At your current startup, at Flint, how much are you using AI?
Oh, all the time. It's almost a requirement at this point to use AI to code, because then you can be more productive.
What are your favorite tools, or commonly the tools that you reach for?
Always Claude Code.
Do you still use the IDE, or not as much, or to review stuff?
So, we use Claude Code inside the IDE.
Mhm.
Yeah.
Inside VS Code, or I'm not sure if you can do Cursor or one of them.
It's Cursor, and then we have an engineer who only codes on Vim. So he uses Claude Code on Vim.
Oh, but then runs there as well. That's pretty cool. It's crazy how quickly we've changed from IDE only for most engineers to actually just warming up to this.
Yeah, technology gets better.
One interesting topic that you mentioned earlier is some cautionary tales about how when you're joining an early stage startup, especially an AI startup, some engineers can feel a little bit screwed by founders. And, you know, we talked about how you managed to get a great offer at an AI company with a founder who checked all the boxes, but I think it's important to talk about some negative patterns you might have seen or heard and how to avoid it, because again, there's an explosion of startups, of AI startups, of founders who want to recruit engineers, and sometimes I guess things can be too good to be true.
Yeah. I'm sensing a lot amongst my friends as well that people feel like, specifically, the founder might be acqui-hired away by a bigger company and then be the only one in the company that received any monetary benefit from
So that we've seen in the news.
Yeah.
Some of the founders being hired away and then the team is left hanging.
That is the specific scenario that people are really scared of. And I actually had a friend who told me that because of all these acqui-hires of the founders that are happening, she's just going to join OpenAI instead because it's safe. I think it's all about really understanding the character of the founder. One great way to find out about the founder is to do reference checks. Like, is this someone who actually has good character, who is generous with their people, who cares about their team? The other good approximator is to see if the founders themselves were founding engineers to begin with, because that's just the lived experience and empathy that you just cannot get unless you went through the ritual of having been a founding engineer, where you're in there. You know, the day that there wasn't even any code, to the day that there was code, and then the day we had our first user, the days where we didn't have the first user, like all that pain and struggle, to now have all this empathy that, hey, these folks are entrusting me with their career and they're taking a lot of risk. I cannot see a world in which I wouldn't offer secondaries and tender offers and opportunities to them. It's a big sacrifice.
And maybe it's even worth asking on the interview specifically these questions: if the company was to raise a new round and the founders would take secondaries, would it be offered to other employees? If there was an acquisition to happen, would you bring the team with you? I guess, you know, it's not binding, but I feel there is a difference between when people don't ask and everyone just assumes, versus it doesn't hurt too much to ask, potentially, especially if it's a startup that seems to have just a rocket ship trajectory.
Oh yeah, absolutely. You definitely have the leverage to ask that in these times.
I mean, it's an innocent enough question, right? Worst thing is they don't answer it, or they refuse to answer, or they can say something, right? And then you have some data point.
Yeah. The other thing is also to not listen too hard on what their answer is and to listen to whether or not they had thought about it before. When I was asking Zach about how he thought about early employees, it was very clear that he had been thinking about it for years. And so the answer that came out was very well thought out and it was a really obvious thing for him to be thinking about, whereas, you know, a less thoughtful manager might give you a good answer but it's very clear they just came up with it on the spot.
So now that you have a startup and, you know, you've now moved from, again, working at companies to being a founding engineer to now founding your own company, and congratulations on coming out from stealth
Thank you.
with Flint. How do you find, what does it take to hire world-class engineers in an environment like Silicon Valley, or with other founders you're talking to, and also from your own experience?
I think it's about showing that you care a lot about the team and that you value people on your team and that there's high trust between you and them, that you will do every measure it takes to make sure that they are going to have a good time. And then it's also about having really big vision about how this company is going to change the world and it's going to be huge and that this is a chance to change the world.
Speaking of which, your startup Flint, can we talk about how you came up with the idea around websites and also how, you know, both what you're building but also how you're thinking these AI agents will change the world, the web?
So the website itself becomes agentic. They build themselves. That means that if you wake up in the morning to a competitor having launched overnight, your website would have already generated you a comparison page that compares you with the competitor, and then it's already optimizing for conversions and it's also keeping track of the differences in your product and them every day and then updating it. So something that would have taken five agencies three months to do suddenly gets done overnight when you were sleeping. And we're thinking of also automating all of the other marketing workflows around that. We can hook into your sales calls and your Gong calls and then find out ways of selling your product or solution pages that you might be missing.
Oh wow.
Yeah.
This is proper next level.
Oh yeah. Marketers really love this.
I mean, I'm not just talking obviously from the marketing angle, but just from a software engineering one, and how you have all these different input channels to capture feedback and then to eventually generate, this sounds really cool.
Yeah. It is bringing autonomy to the web. We're really building a new kind of internet here where the website is now not only generated by AI and for AI, but it's also becoming AI itself, to be more dynamic and proactive. My co-founder actually ran teams at Nuro, which is an autonomous vehicle company, and we talk a lot about how autonomous websites are similar to autonomous vehicles in that they take in data through a perception system. Then there's a decision-making system about, okay, based on this competitor, based on these sales calls, what should we do? And then it would then have a control system that then actually implements the pages, and then it would then start off that loop again where, based on how the page is doing in the environment, which is the market, what should we then do?
So by putting all of that perception, that decision-making and control systems into the same entity, we finally close the feedback loop. That is the reason why it requires five agencies talking to each other to build a page. We had to have the five agencies because there were separate tools and different specialties to be passing information between. And now if you put all of the tools in the same entity, you start having a closed loop where the website continuously optimizes itself for your business. It's very exciting. So the first phase is that, which is let's respond to your market based on real-time data streams.
And then the next phase will be real-time morphing and shape-shifting of the page based on who is visiting. It could be a healthcare executive that comes, and then we morph the page to highlight healthcare case studies or compliance-related requirements from healthcare, and then we could even generate a sales demo that's specifically for that healthcare executive, instead of needing to click contact sales and then wait a week for a Zoom call where someone is extremely bored talking to you. Just have the website generate a demo closely on the spot.
And then if it's an AI agent that's visiting, the website could also speak differently. The agent doesn't want to speak in HTML; they want to speak in MCP, they want to speak in tool calls, APIs, Markdown, JSON. There is a new agent-to-agent protocol that we're building here to redefine the way that agents interact with the web. We also create the concept of an agentic web where, instead of going to Google to find links, you could have the agents talk with each other to tell which agents are more credible than others and be able to communicate very quickly to help to sell a customer on a deal.
This is so interesting because I feel like we're so focused right now, or at least I'm so focused, on how LLMs can help developer tools, like just, you know, change how we do things, that we kind of forget that there's a whole world out there where these tools can really just, you know, change a bunch of stuff, like how we think of websites and how dynamic they are and how ultra dynamic or ultra personalized they can be. This is really cool.
Yeah. Everything we know about the internet is about to change, and Flint is building that even today. One really interesting problem that we're solving, it's almost a research-level problem, is in terms of creating on-brand landing pages. So it might seem very simple from the outside, 'cause like, oh, can't we just choose the background color and the typography of a page and then turn out a page? Turns out that, especially today, brand is very important. If you're a SaaS company, you wouldn't put a Cursor-generated page in front of a Fortune 500 client you're trying to close. You want to make sure that your page really matches your brand down to the very pixel. And we have developed that capability in Flint to create a page that looks almost as if the customer themselves built it. So we work with Cognition on the events pages as well as their comparison pages between Windsurf and Cursor, for example, and that's being cited by LLMs.
So it feels to me, you know, like one part of how you got here, maybe you've got otherwise, but it feels you really got here because you were a founding engineer at a startup, you've seen so many things. So what would your advice be to software engineers who would love to join as a founding engineer, maybe an AI startup or a fast-growing startup? These days a lot of them are AI, not all of them. If it's someone who, you know, has some experience in the field, what tactics do you think might work for them?
It's about showing that you've built in AI before, 'cause that skill is very much in high demand and it's very new. Very few people, relatively speaking, have ever built an AI product before. So just spending some time over weekends knowing how to build an AI product already helps you stand out above many people.
Yeah. And by an AI product, we mean something that is using LLMs underneath the hood to do whatever it might be. I don't know, may that be just a search engine based on LLMs or anything that scratches your itch.
Yeah, really anything that scratches your itch that uses any of the models, the completion APIs. In terms of excelling in that role, it starts off with picking the right founder. But then once you do join, it's all about volunteering to do the things that no one wants to do, but it's the most important thing for the business.
So I did what most engineers would consider to be the worst job ever, which is to be the face of the company on Hacker News at Warp. So I wrote the blog posts, I published them on Hacker News and I answered all the questions on Hacker News. I went out there and I created our company Twitter and I was writing tweets for the company. Then starting a YouTube channel for the company before any developer tool companies really thought about doing YouTube. Starting a Discord channel, filing every feedback, starting the GitHub, things that were very different, outside of engineering, but the business really needed.
And then you're still doing your engineering job, you're still, you know, fixing bugs, etc., but on top of it you're figuring out how to help the company, right?
Yeah, you still have to make sure that you're doing your number one job, which is software engineering, so that needs to still stay the main focus, and you should only volunteer for other stuff if you are already doing well in your main job. The benefit of doing a lot of these things and learning how to do a lot of these things is that then you get to learn what businesses need. You know, you can come up with ideas that are not just developer tool companies, for example. And at one point, because I was doing all these things and then hiring all the people, I remember it was after one of the board meetings, my founder reached out to me and said, hey Michelle, you hired all these people in growth, I want you to be head of growth, you're going to be starting and managing this team from now on. And I don't know, I was like 22 at the time, and suddenly executive, suddenly reporting to the board every quarter on, like, wow, numbers and revenue. You wouldn't get that unless you volunteer to do random things, and then make sure that every time you do this you do them exceedingly well, 'cause it's not necessarily just about doing well in that domain. It's about the founder knowing that whenever they pass you a job to be done, it will be done excellently.
Yeah.
And then this way you get more and more responsibilities. Eventually I ended up leading enterprise sales for Warp.
Oh wow.
Because we had this problem where we started getting a lot of security questionnaires from companies that were using Warp, and I saw that problem and I was like, oh, this is not a security problem. This is an enterprise sales opportunity. This is the start of a conversation in which, if we have an enterprise deal, we could fill your questionnaires and we could have SOC 2 reports and we could have all these nice compliance controls and admin panel if you paid us, like, you know, this amount of money. Yeah, it's things like this that really help you do well in a company. It's doing the things that are very unsexy that nobody wants to do, because before you know it, you might be running enterprise sales because no one wanted to work on security questionnaires. It was a hot potato that was passed around multiple quarters until it went to me.
And I guess it's probably needless to say, but if you are working as a founding engineer, or even as a software engineer, you're picking up all these things and you're balancing all these things, and from the outside it's like, how are you doing all these things? I guess it's kind of preparing you to be a founder, because as a founder you'll definitely have to balance, you know, all these hot potatoes at the same time.
Oh yeah. The job of a founder and a manager is always about taking the things that no one wants to do so that everyone else can be in their zone of genius. They can spend all their time working on this engineering problem and, yes, I will deal with Hacker News.
As closing, let's just do some rapid questions. I'm going to ask a question and then you tell me what comes to mind. Sounds good?
Yeah, that sounds great.
What's your favorite programming language and why?
Oh, Rust. I feel like I get a lot of satisfaction every time I pass through the borrow checker, 'cause it's very difficult to write code that compiles.
And at Flint, you use Rust as well?
At Flint, we are a TypeScript shop. We are building autonomous websites and we're building websites that build themselves, so it is helpful to be writing in a language that builds the website.
I'm sure Rust will find its way in there sooner or later.
All right, we'll see.
What are one or two movies that you would recommend that you enjoyed?
Yeah, I really enjoyed Weapons. It looks like a horror movie on the outside, but it is very enjoyable. There are many comedic moments in it, and I also really enjoyed the nonlinear narrative, where it's a story about sometime in the early 2000s there were children who started running out of their houses at 2:00 a.m., and then they all disappeared for a month. And this is just a real-life story, and then the movie creates a narrative for what could have happened. And then every chapter in the movie was showing a different character's perspective, and every perspective added a different way of viewing the story altogether and almost changed the genre each time. And as a horror movie fan, I also saw that every chapter was a different character in a horror movie trope, which I also found was really smart. So yeah, highly recommend it.
I am not a horror movie fan. I watched this movie not knowing what I got myself in. I will say it's memorable. It still gives me the shivers and it still makes me think. So great recommendation. Thank you.
I do recommend.
So Michelle, thanks for being on the podcast. This was just really interesting to see, you know, how much you can learn being a founding engineer, how you can do it, and how it can lead to starting your own company, doing super exciting things with Flint. So good luck with Flint and thanks for being here.
Thank you so much.
I always find it interesting to hear how someone became a founder, and Michelle's story felt pretty approachable to me. What really got my attention was how Michelle was volunteering to do the unattractive work. In this case, working with a marketing agency to build marketing websites at Warp. And this got her the idea and expertise to start her current startup, which is about creating marketing and launch websites with AI. Michelle's story is a great reminder that to be a great founder, you probably need more than just software engineering. It's also helpful if you understand different parts of the business and you get your hands dirty with non-tech work as well.
One other thing I found interesting is how Michelle thinks that GEO, generative engine optimization, basically LLMs recommending websites, will soon become perhaps even more important than search engine optimization. Things are changing fast in the web thanks to AI, and perhaps web pages will become a lot more responsive and fluid thanks to AI and in response to LLMs. For more details on how to be a solid founding engineer, see the Pragmatic Engineer deep dives linked in the show notes below, including an article on lessons from the trenches of being a founding engineer. If you've enjoyed this podcast, please do subscribe on your favorite podcast platform and on YouTube. A special thank you if you also leave a rating on the show. Thanks and see you in the next
Article published