Algora | Algora TV

Sematic (YC S22) Interview Highlights

Algora

Watching now

00:00 So I'm originally from France. I started my career in academia about 15 years ago.

00:09 I was doing physics research at CERN, the big physics lab in Switzerland. Eventually,

00:16 I moved to the US in 2014 when I joined Instacart, a grocery delivery company, after four years at Instacart, I joined Cruise, the self-driving car company based in San Francisco.

00:30 Built all sorts of systems, infrastructure, and backends to support all of the machine learning and data science teams at Cruise.

00:38 And we were able to support the commercial launch of the Cruise cars.

00:46 were able to support the commercial launch of the Cruise cars. So now Cruise has robotaxis going around the city of San Francisco, Austin, and Phoenix. Training those models requires a lot

00:51 of infrastructure because you have to consume a large amount of data that's been collected by the

00:58 cars, transform this data into feature data sets, train large neural net models. Sometimes, you know,

01:04 the training jobs can last

01:06 for many hours or many days,

01:07 and then estimate performance metrics and so on.

01:11 So that requires a lot of infrastructure

01:13 to run those pipelines.

01:13 So we built all the tooling

01:15 so that engineers could easily train those models.

01:19 I left Cruise in April 22 and founded Sematic.

01:24 So the idea behind Sematic is to bring the learnings

01:27 that we gathered from working at Cruise for four years to the rest of the industry

01:31 and also make it open source. Got into Y Combinator for the summer batch.

01:37 So we did the S22 batch, graduated in September. We raised a seed round. We raised about $3 million in September

01:46 and that enabled us to grow the team.

01:50 So now we're a team of five engineers,

01:52 four of which are ex-Cruise engineers.

01:56 And so now our target is to build

01:58 a fully hosted SaaS product

02:01 on top of the open source platform

02:03 that we've built so far.

02:04 So that's roughly where we are at this time. We launched the product in July. So July 1st, we had zero stars. And

02:11 right now we're almost at 700, I think 660 stars by now. Be happy about it. Obviously,

02:17 as I mentioned, that's not necessarily an indicator of success. So being part of Y Combinator was

02:23 very helpful to get started with those stars because when you're part of YC, you get access to Hacker News.

02:30 I'm sure you know Hacker News.

02:33 And getting on the front page of Hacker News is very difficult usually.

02:36 But when you're part of YC, they give you almost a guaranteed spot on the front page for about 12 hours.

02:42 Like for one day, basically, you get to your launch.

02:45 And typically, if your product is good, that gathers a lot of comments and front page for about 12 hours. Like for one day, basically you get to your launch. And typically if your product is good,

02:47 that gathers a lot of comments and a lot of stars as well.

02:50 So that was very helpful to get us started.

02:52 And now, you know, we get those stars by, you know,

02:55 getting on newsletters, on podcasts like this one, for example,

02:58 or other types of, you know, LinkedIn as well as a good source.

03:01 Also a lot of like email marketing and so on.

03:04 So that's for GitHub stars. Then in terms of revenue, as I mentioned, you know, we're very

03:10 early at this time. So we do have a little bit of revenue, but nothing really to brag about,

03:14 because we're still in the phase of figuring out product market fit. Another sort of metrics of

03:20 growth is the team itself. So, you know, I'm a solo founder, so I started by myself.

03:31 And now we're a team of five engineers, and four of which, including myself, are ex-Cruise engineers. So I was able to attract very senior talents from Cruise and other companies. You know,

03:38 if we look at all the pedigree of the team, you know, we've worked at Cruise, Instacart, Adobe,

03:46 You know, we've worked at Cruise, Instacart, Adobe, Microsoft, Google, and so on.

03:47 So Adobe as well.

03:54 So a group of very skilled engineers, which gives me a lot of confidence as to our ability to build a very good product.

03:58 So we did hire an infrastructure engineer that we didn't know before.

04:02 And the way we hired him was also to leverage the YC network. So, you know, YC has a job board. When you're a YC company,

04:06 you can post a job listing there. And because it's very popular amongst developers, you get a lot of

04:12 inbound applicants for your job listings. So that worked well for engineers, group partners.

04:20 So you have four of them, and they typically try to assign you partners that have expertise in the area of your company.

04:28 So not necessarily the machinery in our case, but at least open source or developer tools.

04:33 And so, for example, for us, one of our group partners was Nicolas Dessigne, who is actually a French founder, who founded Algolia, this very big search company. So, you know, if you use, if you know any, almost every search out there in every, like

04:50 Gitbook, for example, or Hacker News, or many other companies are using Algolia for their

04:56 search, it's very powerful.

04:58 And so Nicolas Dessaint has a lot of experience building a developer tool into a unicorn company

05:04 and making it like the standard.

05:06 So they have experience growing successful companies in the past, so they can tell you what mistakes not to make.

05:12 That's really the big thing about YC is that those people have seen hundreds, if not thousands of companies before.

05:18 Some of them fail, some of them succeed.

05:21 And so they can tell you the general mistakes that people make and that you need to avoid.

05:29 For example, don't hire too fast, don't spend your money too fast,

05:33 focus on your product and getting customers first and so on, which seem like, you know, obvious advice when you hear it like that. But it's not so obvious when you're, you know,

05:39 knee deep in the work and you head down and you're not looking up. So this is very valuable.

05:45 What has changed?

05:46 What is different now, if you could put your finger on it?

05:48 It seems like building an open source or open core company,

05:52 there's something different the last few years.

05:54 How would you describe that?

05:56 Yeah, so I think my view is probably biased because this is the first time

06:01 that I worked for an open source company.

06:04 But I think for a long time, the industry was seeing open source as like, oh, it's a cute little thing.

06:10 Even though large products like Linux, for example, is open source, and almost the entire world is running on Linux.

06:16 All of the cloud infrastructure is running on Linux.

06:19 So open source is definitely not a gimmick.

06:21 It's something definitely unique.

06:23 You look at other industries, nobody is working for free or giving out their source for free. If you think about,

06:30 let's say architecture or construction, things outside of software, very few industries are

06:36 giving away their special sauce for free for everybody to look at. Everything is closed

06:41 outside of software. So it's a very unique behavior that's only maybe in research and academia.

06:47 You know, you where it's basically the base, the baseline.

06:49 You know, everything is public because you're actually writing papers and you have to publish your methods to prove that that you did the work correctly.

06:58 So open source software is a very unique practice. And I think for a long time it was seen as like, oh, yeah, it's cute. It's a way to attract developers. If companies release a bit of tooling, open source is basically just a way

07:10 for them to grow their recruiting brands and hire more engineers, which is great.

07:17 But I think in recent years, there's been a shift. And now people see it as a very valuable way to

07:23 have high quality products because it's

07:26 there's a lot of scrutiny on open source software can inspect the code and guarantee that it's high

07:31 quality so now it's coming it's moving from this recruiting tool to more of a pledge of quality of

07:38 guarantee of quality of of the product and it's also a proof of goodwill of the company. If you're an open source company,

07:47 it means that you aim to make money through additional services, through high quality

07:52 service, not through just selling hacky code to sort of naive customers. No longer like this.

08:01 It's basically your goodwill. You want to build a good product. And on top of that,

08:04 you want a product to be so good that people are willing to pay for it,

08:07 even though they could be using it for free. So I think that's a bit of a shift in the last

08:11 few years. I think you're right. Any piece of advice, any maybe mistake or...

08:16 Yeah. So I think you have to be very humble as an open source founder, because somebody is going to read your code and find it not good.

08:28 Or, you know, you, you have to really be open to criticism.

08:32 You have to be very candid with feedback.

08:34 This is actually a culture that we grew at Cruise where code review was

08:39 extremely candid and direct. You know,

08:42 sometimes when you read the pull request and the code review, you're like, oh my God,

08:45 those people are really rough with each other.

08:47 We're always polite, obviously,

08:49 but we don't sugarcoat things.

08:50 You know, if something can be better,

08:52 we say it as it is.

08:53 We always provide constructive criticism,

08:55 but it means as a developer, you need to be humble.

08:57 Everybody thinks their code is the best ever, right?

08:59 When you write code, you're so proud of it.

09:01 You think that it's the best ever,

09:03 that nobody will have any comments

09:04 and you will be able to merge it right away.

09:06 In the end, it doesn't work like that.

09:08 You typically have days, weeks of review, and at the end, your code is much better.

09:13 So you have to know that even though you think that you're a good developer, there's always somebody that has a better idea.

09:19 You have to be open to criticism, open to better ideas.

09:23 And if you don't like the idea, you cannot just dismiss it.

09:26 Oh, I don't like this.

09:26 You have to have rational arguments

09:28 why the solution is not optimal.

09:30 And that forces you to review your own assumptions

09:32 and to have good justifications for your choices.

09:35 When you're a closed source,

09:36 you don't need to justify anything to anybody.

09:38 You can just write your quote unquote shitty code

09:41 and ship it out and nobody will know.

09:44 So as an open source contributor,

09:46 you need to be able to justify. If somebody asks, oh, why did you choose this abstraction or this

09:51 dependency or this third-party tool to do this? Why not this other way? You can't just say,

09:57 eh, this is what we did. You have to say, well, because reason A, B, and C, and if we had chosen

10:02 something else, this wouldn't be true and so on. You have to convince, you always have to convince

10:05 other developers of the reasons why you did things.

10:08 So you have to have some humility, even

10:09 though you may think that you're the best developer in the world,

10:12 you need to know that that's not the case,

10:13 and others have a lot of

10:15 value to bring you, even though they might be way more

10:18 junior than you are. We've met

10:19 very young developers that were

10:21 mind-blowing in their

10:23 visionary vision of code. code so uh yeah you have

10:29 to be humble so as an open source founder i would advise to always you know be welcoming to

10:34 external contributors even when sometimes you have shitty prs that are coming in you know people that

10:39 are writing a lot of code and that's not very good you have to basically carry them along and

10:44 educate them to get to a better spot.

10:47 The same way that you would

10:48 if it was a junior engineer on your team.

10:50 Let's say you're in a team

10:51 and a junior engineer has been hired

10:53 and their first PR is not so good maybe,

10:56 you don't tell them, this is terrible, you're fired.

10:59 You tell them, okay, let's work on it together.

11:01 Let's make it better.

11:02 And over time, week after week,

11:04 those developers get better

11:05 and the amount of work you need to do

11:07 to get their PR in a mergeable state is lessenless.

11:10 So basically, always be welcoming

11:13 and inclusive of XML people,

11:15 regardless of their skills.

Library