Becoming a founding engineer at a YC startup

[Music] Everyone, thanks for joining. I'm Paige from Y Combinator on our work at a startup team. Um, that's the site that our portfolio companies use to hire people and the site that candidates can go to, to get jobs at YC startups. With us today, we have three guests who are all early and founding engineers at YC companies. I'm going to let them introduce themselves and then they'll kind of share a bit about their backgrounds, their companies, and then we'll dive into Q&A after that.

Awesome, thanks Paige. Um, yeah, my name is Gar. I work at Cambly, and we're an English tutoring company. We connect English tutors with students around the world over video chat to learn English. I joined Cambly in 2014, so I've been there for eight years. I was the first full-time engineering hire and now we have an engineering team of 25 engineers and I lead that team. Before this, I was at Google, which is where I met one of the founders of Cambly, which is how I came to join Cambly.

Hi, I'm Jen. I'm a software engineer at Findlay. So like I said, I've been working here since October last year. Um, Findlay is creating debt capital management software and so we're just trying to streamline the process for a lot of these kind of very, very manual financial processes for our customers. Um, so before working at Findlay, for joining last October, I used to be more of a consulting software engineer and so worked on projects here and there. In my past life, I like to say I was a molecular biology researcher, so I was the lead in life career switcher, but loving it so far! And I've always kind of coded in my free time and so living the dream, getting paid for a hobby!

So hey, um, so I'm Jordan. I'm an engineer at Explo. I've been in Explo since April of 2021, so about a year and a half now. Um, at Explo, we let you make customer-facing dashboards that you can embed regardless of your database. Um, just kind of like fully customizable dashboards that can fit in your website. Um, before I was at Explo, I was at this other company, Applied Protective Technologies. I was on like the architecture team for that company and I was getting to maintain and build features on like all these cool core components that our platform was running on. But I wasn't getting to build any of those and I wasn't getting to like I was working with the people who had built the foundation, but I really wanted to be that person who had built the foundation. So I found out about Explo, it sounds like a great opportunity to start learning how to do that, learning like how to build an email system, a job queue, like deployment infrastructure, all that stuff. And it's been a pretty cool journey since then.

Great, thank you. So maybe we will start with what I assume everyone on the call wants to know: what is a founding engineer and what does that kind of mean to you when you hear someone say that or talk about that or you can see that in a job description? Yes, I don't know about the rest of you all, but this is at least a text guy. This is the first startup that I'm working for as a software engineer. So before joining this call and I mean when I was job searching, I kind of googled what does that even mean? Like what is a founding engineer? Um, and like Google likes to say that it is kind of early engineers who not only like contribute technically but also kind of set the tone of what kind of the engineering culture is like at a company. So I don't know for Gar and Jordan, who probably have more experience than me, do you find that to be true or what has your experience been?

No, I think that's totally true. Like when I was looking for jobs, I never thought I would work at a startup just I didn't think I necessarily had like the skills toolkit to kind of have that responsibility especially as a founding engineer. But I realized like really quickly that a lot of it does come down to that. Like you are helping define not just your engineering but a lot of your culture. And like I think that is somewhere that I like do bring a lot and I do excel. So I like totally agree. I think that when you're a founding engineer you definitely have both of those responsibilities to bear. My experience was a little different because the two founders are also engineers. So I was the first one to join, but I quickly found that as founders, they're distracted by all these other things and trying to fill all the other roles. And so I quickly was in that same spot where it's defining like what does the technical vision look like? How are we going to expand the engineering team and kind of lay the framework for growing that engineering team?

When you first joined and in the early days, how did your day-to-day role end up differing from either what you were told or what you expected? I think I thought it was going to be just engineering and then you end up bleeding into all these other roles. Like I remember answering customer support tickets and then things like okay like what product features do we need to do? So you end up doing a bunch of this PM work that I had no experience doing before but got to speed on that pretty quickly. So definitely I'd say like a lot of broadness to the role and like executing a lot of different roles.

Yeah, I think that's one of the things that really excited me. Like I kind of figured that I was going to be doing a lot of PM work, customer support work, and that was going to be an interesting change of pace. So definitely a big jump into the deep end, just going from you're an engineer, you're doing your tasks and like maybe part of other meetings to you're in meetings all day, you're jumping between 50 different things, but it's a cool jump to take!

I have a question for the panel. So I know titles, you know, often in the startup world people sort of think titles, you know, title schmeidel, what does it mean? But the reason they matter, in my experience, is when you're interacting with people outside the company, they want to have on some idea what your role is. So my question is how does founding engineer relate to say CTO or senior VP or you know some of the titles you see at, you know, more established companies? Is there some sort of mapping?

Yeah, we didn't do titles, we still haven't really done titles at my company. We're like in the process of just doing that. It's like, um, I think if the founders weren't engineers it would have been important to just give like some random CTO or VP title for exactly the reason you said. But maybe caveat that with it's it means nothing like that early on and internally like that's probably subject to change.

So yeah, I think at a startup or—sorry, Jen you should go.

Oh yeah, no worries. Um, I think it really depends on your company, the culture, and two, also the size. Um, like for example at Findlay right now we don't really have enough engineers to really justify having levels. A lot of engineers are working together for lots of different projects. We have different engineering leads that basically end up working with our business side to have like project managers. So a lot of the roles that you would see broken out at larger companies into specific roles end up being handled by like one person, especially because of the startup size. Um, so having like engineering levels, kind of like Gar said, we know just like baseline years of experience and kind of the background and context that other engineers have. Like even though we all have the same title, I can rely on the more senior engineers to actually like answer a lot of these technical questions. But the nature of our work is that everyone is responsible for their kind of technical area and that part isn't even playing field. So having like senior engineer titles and stuff like that at our stage doesn't really make sense. At our company we do have a CTO, so I don't know about your companies Gar and Jordan, but we have a CTO, um, and then everybody else is just titled software engineer.

Yeah, it's the same for us. It was basically the same for us except they recently as I took over the engineering team they just gave me the title of director of engineering for exactly the reason have brought up Daniel. That's helpful for external communications.

And maybe going off of that, as the company grew, how did your role change? Um, and how did that, how did you kind of shift out of the founding engineer role or was it something that kind of stuck with you because of how early you joined?

Yeah, I mean the role definitely changes that as the team grew inevitably like you have all this institutional knowledge and so people start looking to you. It's pretty typical you're probably going to be leading the engineering team. I think like there's a good chance of that and so then it just moves into like managing, growing the team, onboarding new people, defining the processes, um, and culture as kind of Jen and uh, Jordan pointed out.

Yeah, I think in the past couple of months as we've like onboarded new people, definitely kind of like the realization that I have a lot of like the institutional knowledge and like context for a lot of our stack and a lot of our code base has like become more clear and that's like an exciting evolution of my role. Um, don't exactly know where that's going to lead yet but, um, it was a cool realization to hit.

I kinda, I'm at the same spot as Jordan as well. Um, even though I only joined nine months ago we have a smaller engineering team. So the reality is when we onboarded like three new engineers a few weeks ago, it's like oh well who's gonna help onboard? Well, everyone! And so it's like what? Um, we've kind of gotten to this thing where different people lead kind of different technical areas of our stack and so, um, just as their engineering team grows, like I said you have institutional knowledge because for me I didn't really have any background in finance at all. So even knowing the lingo, kind of knowing what our product is, what the actual problem with our product is, so just being comfortable in that area kind of helps you kind of lead and helps you just onboard and get all the other engineers really comfortable with working on your team. Things like that.

How many people on your team day to day do you work with?

Um, we're 14 people so far. Um, and I think I work like especially when it comes to the engineering like side of our company, I work pretty closely with everyone on the day-to-day just because I do a lot of like our deployment coordination. So I end up interfacing with people and then on the sales side I think I also end up at least speaking to someone kind of in our BD on a day-to-day basis. So yeah, I'd say I'm interacting with like half the company on any given day.

Yeah, our company is like 140 people or so now spread out around the globe and so, um, we used to interact really closely with all our country managers because they'd be feeding us all this feedback but like a couple years ago for my role there was kind of an inflection point where, um, when I was working with all the engineers on the team when we had about 15, ever my day-to-day was very focused on working with them and then once we promoted two more engineering managers and there was like a layer between me and the rest of the team, my role switched to a lot of like working with recruiting, working with um, product and working with uh, the other leads. So there's almost like an inflection point once you reach that scale where like instead of working closely with people below you, you start to work more cross-functionally.

Yeah, at Findlay I think we’re at about the same size as Explo, right around like 13 or 14 employees. What's great here is that I would say I get to talk to probably at least 75 percent of the people on our team on a day-to-day basis. We work really, really cross-functionally because we rely heavily on our capital market side to make sure that kind of what we're building makes sense for our customers. And so I think like that's another really cool thing about being a founding engineer is that instead of if this is something that you're interested in, um, if you don't just want to focus on the technical things like you interface a lot with all parts of the business and you get to see like everything and a lot of the working pieces.

So going off of that, how do you think when candidates are thinking about joining a startup, um, how should they think about like becoming a founding engineer and thinking about like their skill set when applying to roles?

I think when I was applying to startup roles I was really focused on the growth aspect of it. I think especially at a small smaller company like you have the opportunity to kind of put your hand in many pots or wear many hats or whatever kind of thing you want to call it and it's yeah, it's just I think that I went into it thinking that I would be heavily focused technically and grow heavily technically, which yes, that's true, but kind of as the other engineers mentioned, a lot of what I do is um, kind of more soft skill based. So things like leading a project, making sure we deliver on time and things like that. And there's a lot of things that happen when you're founding engineers kind of the roles and responsibilities are different than just being entirely engineering even though that's your main role. And so I think that is a large part to consider if you want to join a company earlier is that you'll be relied on for lots of things that are not engineering as well.

Well, it depends on your company and how they want to work, but I know about our company we just everyone helps wherever they can and so I think for me that's a really exciting part of being an early engineer.

I think like coming back to the earlier thing like for me it was these skills that I didn't expect to have to learn when I joined. I thought I would do mostly engineering but certainly I was like responsible for a lot of business metrics and like tying like what we’re gonna work on and what's important to work on to like actual metrics. Um, and so which was awesome, like it was just something I never thought about before. So having to like dig into that stuff was really an awesome skill that I don't think I would have gotten outside of working at a startup.

Yeah, Gar and Jen have some a lot of what I was going to say. Um, so I don't have that much to add but it's definitely, I mean I don't have personal experience to know if this is like impossible or ill-advised, but it definitely seems like when you're joining a startup at such an early stage like coming in with the idea of like this is I want to do this one thing or like I just want to engineer, like it's kind of a tough mentality. There are definitely startups out there that I'm sure work for that but it's definitely a harder mentality to keep um once you just realize the scope of what you have to do. I think also being really early on, I think sometimes as engineers we feel like our role is defined by like our quality of code and like all the features that we push out and things like that, but early on like I'm experiencing this now, like you learned that at a startup the feature that you treasured and it was your baby for a couple months, it's gonna get trashed because like or repurposed in some way that was different than what you thought because like at such an early stage, we always want to make sure that we're building the right thing for our customers and it's not about like this was super cool technically, we want to keep it. It's like a sunk cost fallacy, so like you just need to kind of roll with the punches and kind of be fluid to wherever this raging river takes you kind of mentality.

Like again, yeah, and at some point, it's like when you build that super cool feature and you learned whatever you needed to learn for that feature, um, and then it gets trashed like three months later, you celebrate the win that like look at what we built, look at what we got to learn, and then like look at what that made us learn about like all this new work we get to do, like at some point you kind of have to turn that and turn it into a win.

Yeah, I also, I don't know if you guys experienced this, but like the style of writing code changed dramatically for me where like I was used to working in a large code base with a bunch of people where you had to write high-quality code that could you know be modified by other people, but early on it's more important just like get them out and test it and you didn't actually have to worry about a bunch of other people touching and maintaining that code because, as you said, like it would get trashed. So it was more important to like get it out quickly.

I know that will be a contentious statement for some, and now we've trended the other way, but like early on I think that was like a tough skill for me to learn, uh, but really valuable.

Yeah, I definitely came in like my team lead at my old company had like a whole style guide and like all these like core libraries we had written and I came in, I was like I'm gonna write all of these like everyone's gonna be able to use my code when we have 40 engineers next year and I very quickly realized that that was not the like best use of my time.

Um, but that's okay. Yeah, I really appreciate the approach that we've taken. It's like I think it's exactly what Carson originally, it's like yeah just ship stuff. Like we have code reviews and things to make sure like nothing too janky goes up there but um like what's really great is that over time as you add more engineers it necessitates more of a convergence more of like a consensus on how we do things. And the really cool thing is, is that here we kind of take not only like the technical like leads opinion but we also kind of pull opinions across the engineering team to say hey how do we feel about this? Do we want to kind of converge on these naming conventions like this or do we want to converge on organizing like data access blah blah blah like this? And so like over time there's less kind of like ship as fast as possible and it kind of everyone's responsible for kind of refactoring their code slowly as you go along and I don't know I don't know how you guys feel like going across old code you're just like oh yeah that maybe that doesn't look so great and our team is experiencing that now but the really cool thing is that all our engineers kind of kind of what I was talking about earlier code quality means a lot to us and being able to make our lives easier six months one year from now.

And so just the ongoing kind of rolling refactors has been kind of like a huge game changer for us to make sure that even though we ship quickly, we're kind of headed in the right direction kind of technically and don't have super old cobwebs that you run across and you're just like oh no, what does this do?

Yeah, we've incurred especially around like testing, you know, a lot of tech debt but there's also just like old cobwebs that I wrote a year ago that now I think especially in the past year or in the past 2022 we've been pushing a lot on the mentality of you have to leave code in a better place than you found it, um, and if that means spending the extra half a day to write tests or to refactor something or to comment it better, like that's really important going forward and it's been a big like mentality shift for us.

I have a question, that is actually grouping together my own question a couple from the chat which is as a founding engineer maybe what was your experience or what do you think the proper division of responsibility is between writing or participating in a prototype or an MVP versus hiring and when you do hire are you looking for kind of rockstar people that far outstrip your own technical abilities but that can restrict their scope or their efforts to a particular part of the product? Are you looking for generalists that can kind of help out and get the thing off the ground? Are you looking for junior people that can… it's what you can afford. So how do you think about hiring your core people and how do you know when to do that or how to split your focus between getting an MVP off the ground yourself, the prototype versus hiring and getting that?

I think like for us it was, um, oftentimes like we just financially couldn't hire more engineers and so that was the balance. Um, a lot of times it's like we would have to go write that stuff but then later like it becomes much more of you have to just spend, I think it's almost easier to go write the thing yourself instead of like hiring like you probably need to like invest in hiring more earlier than you might want to because it seems so easy to score the engineer or go hire engineers, um, even though it's not.

And then the second half of your question was I think generalists are much better early on, it's just hard like when you have somebody with deep skills and then something you're like that's they're not gonna be useful for this feature you're like what do I put this person on in the meantime even though I know what our company's priorities are and they're over here.

So we've we've definitely, I mean it's probably different for every company. I mean we're a web application, so generals are really useful. If you're doing something that's highly specialized then the answer might be different there.

Yeah, definitely agree there. Like we always joke about how one of our like more senior engineers that's really more back-end focused had to write like react code during like, you know some of the earlier days. So it's, it's kind of when you're thinking about technical hiring like it's kind of all the different things that we've been talking about before that your role is more than just like sitting down and writing code even though that's like 90% of your role. And I think generalists are kind of what startups need in the beginning but kind of not, not generalists is kind of a misnomer I would say. Everyone kind of has their own specialty and kind of what their past experience brings and so kind of piecing that together, like but making sure that kind of they know I see is like the main thing that their role will be and that they might have to touch all parts of the stack. So like very early on, before like first five engineers, like you're not going to want to hire like someone who says I don't want to touch the front end like at all just because you're so short-staffed like you have to. There's like no other, there's no other way for us to move forward.

And so I think it's all about like being fluid in the beginning and as the team kind of builds out you can see oh we're kind of missing someone who has a lot more of like experience kind of in the front end kind of at like a larger product level and things like that or oh we're missing like a very, very heavy back and forth. Kind of that's how as you grow up the team or if you think oh this person is like really into documentation or something like that, you kind of like assess the team like as a whole holistically to see kind of where we can skill up by adding another person because it's also about kind of knowledge dissemination in the early days. It's like once like one person is really good at something it brings up everybody's skill level.

I have a question for, I don't know if it's pronounced like that Gar.

Yeah, yeah. I'm also the founder in union yc startup but I'm also like kind of like first hire so I always have a question for you that you know more like at scale and do you have face like send some bar when you decided to, I don’t know like should I continue coding or should I move into a more management role or like product role? How do you face that kind of like decision with the put the founders or like just knowing if like where did you fit in? Because like you, like by myself I also think like I'm not smart as like engineer in the room, that's why I hire a lot of people. I'm more like a general this guy and I focus more on product but there's like there's one step where you should like decide, you know? So I don't know if you face some kind of situation like that.

Yeah, I think, um, if I understood the question correctly like was it kind of like how did I decide to move into the like if you face that that part like, you know, you are coding or you should move more into like more like management or like product side?

Yeah, I think there’s like two things that influence the decision for me is like what's best for me and what's best for the company and like, uh, in both cases the answer was for me to move into this management position. I didn't think there was anybody else that was excited about doing it and then it's also a skill set that like I really want to build. I know it'll be useful for me. I know that like coding is much easier because I've just done software engineering for so long, whereas like, uh, it was kind of my first opportunity to really take on a manager role.

Um, but it's kind of like it’s an invaluable skill set but it's not necessarily one that everybody wants to or like wants to build. So I think like the question kind of comes down to what do you want to do with your career? Like is that something that's kind of setting you up for where you want to go?

Awesome, thank you. I don't know if Jen and Jordan want to chime in on that also or if they have thoughts about that.

Um, I actually talked about this to one of our senior engineers and their take was if you're not a post-it or you're unsure just try everything once to see how you like it. I think, um, at least here at Findlay the nice thing is that yeah one we have to think of what's best for the business and two if you have like open dialogue with whoever the managers or CTO or whatever and saying I want to try this out but I'm not sure if I want to stay in this role like kind of keep having that expectation up front and having kind of like that two-way street conversation so that if you end up not liking it you want to really go back to mostly I see like that door is there. So I think it's always like open communication with what your career aspirations are will really help shape that conversation.

Yeah, I think one of the kind of like decisions like all right people see that you know you're the founding engineer like you're the first hire like you should be the CTO or like I don't even like see myself like being the CTO or just like moving more like I like more product I think I can code and I have those skills but I think I like more product and I have more decisions I want to have more impact on the other.

Yeah, and there's I think a lot of people will misunderstand like the founding engineer role with like CTO, you know, and also in different stages of the startup. So I think it's like, yeah open communication is really helping like with the founders like a team to shape that role.

Yeah, and I think that's the big differentiator between like a startup and when a startup kind of starts to move away from being a startup and become an established company or whatever you call it next where like I feel like that open communication and like flexibility of role and that idea of like oh I just want to try this is like it can still be there but it's probably it might be harder or it might be like a couple more hoops or there might be like more kind of explanation if you ever decide to go back on that and I think like that's it's an important mental or like an important culture to keep.

I think earlier you mentioned someone asked like how do you choose what startup to like join as like an earlier engineer?

Yeah, and I think one of the that's one of the things that is like a really, really, really high on the list for me it's kind of this like open communication that we're talking about, um, because like if you if you're comfortable with the people that you work with and I mean this definitely depends on your personality if you don't care about the stuff then it's not gonna affect you, but for me like having open communication making sure that my manager or whoever I'm working with knows what my kind of personal goals are and how they align with the business in kind of feeling that out when you're first meeting them for the first time seeing if there's a lot of open communication and transparency even through the hiring process I think helps you choose like kind of the clear winners outside of like the other due diligence you should see if like if you even think there's a good product etc etc.

Maybe building off of that, um, I know that people are interested in hearing about why you decided to work at the company that you joined.

So I'm someone who when I first start something out like I just I research everything. So like I read all the blog posts, I watch YouTube videos, I get like really intense and then my family usually tells me hey you should probably cool it a little bit. Um, but so when I was, um, when I was starting to get in the different offers that I got from like from different startups, um, I have like kind of like you have your gut feeling and then I also had this like excel spreadsheet that like kind of plugging in the numbers grading the things on like different things as like culture fit blah blah blah giving them numbers. And for me, I think the biggest, the biggest um, advice I got from kind of I had a family member who had been an engineer for quite a while and they had worked for startups that like got successfully acquired by Google and stuff like that and I was like hey how can you tell if a company is great to join or not and he was like I was like do you want me to give you the fluffy answer do you want me to give you the real answer? And his answer was basically like you don't know like you may think a product is amazing but it's going to fail. He's like you really only have like a one in five chance that a company will be there two years from now after you join if you join so early on.

He's like honestly the thing that you should think about is do you like the people that you're going to work with because that's really kind gonna shape the culture of the whole company and happy people make a successful company at least in um in his opinion. And so if you if you hate your life you're not gonna be putting out your best work, you're not gonna wanna show up every day and and kind of hang out with your co-workers to kind of really kind of talk about the product really deeply. It's not going to be exciting.

And so, um, like you know all the other things that blog posts say you should you should like you know ask them all of these business questions and things like that. I think one of the things that kind of gets put in the wayside a little bit but maybe should should be a little bit more forefront is like do you even like who you're gonna be working with?

Yeah, um when I interviewed I like my interview was mostly just I spent the day talking with working with the four or five people at the company at the time and like there were tons of cool kind of performance questions and like interesting issues of scalability that excited me about Explo, but also I kind of just did that math of like if I'm going to be working like 12 hour days like whatever like seven days a week like am I going to like these people I'm working with? And like there was no doubt in my mind that like I’m fine to spend like two or three years like you know in the battle trenches with these people and it you know that's kind of like the decision you have to go with I think.

Yeah, plus one too like having a team—I mean I knew one of the people I before I joined and so that was a big part of my decision to join the startup. I'm not, and it'd be really tough to work with a team where you didn't like anybody.

Yeah, I think I think the other big thing it's like what I really focused on too was asking questions around how how do you view like constructive criticism or how do you view like different opinions? Like in your ideal world when you have a whole team of engineers and everyone has kind of like something to say, what do you think about that and how how would you deal with something like that because I think that's like a reality early on that you face is that, yeah, we have a lot of different like competing things to competing directions. It's like how do you synthesize that all? How you kind of make sure that kind of ego is left out the door and kind of everyone has a seat at the table to make sure that we make the best product, not the best product that this person thinks is the best product or the best product this person thinks is the best product.

Yeah, I feel like the scariest thing in like those first couple of like, you know, in these first couple of years of being at the startup. It's like the scariest thing is blame. It's like when something goes wrong like is your company going to like find the person who pushed the commit or find the person who like okayed the test and like be like hey why did this happen? Or is it going to be like the team coming together and be like we all let this through so like how can we make that not happen again? And like it ties right hand in hand with ego like you need to not have a blame for culture, um, or like the startup is not going to be a good place to work.

Gar mentioned that you knew one of the founders of the company that you joined. For the other two of you and maybe also for Gar, how did you find this company originally or did they find you?

I can go first even though I think it's probably more real Jen and Jordan's ads might be more or less so. I had worked with one of the founders Samir at Google and he actually tried to have get me to join his first startup they did right afterwards and of course that one failed like so many do. Um, and the timing just wasn't right for me. Um, but then when he reached out right after Cambly had finished Y Combinator and asked me to join like the timing was great for me and so I was really excited to work with him again. He was great to work with at Google and he's been great to work with at Cambly too.

I decided I want to work at a startup or like just somewhere where I would have a lot of hands-on experience and a lot of different things. And so I think I googled where do I apply to startup jobs or something like that? Um, and then I knew about Y Combinator too and I ended up finding like work at a startup—this was like in my mode where I was like all right let's apply to all, all jobs known to man kind of kind of mode—because I wanted to be more product-focused versus like doing like consulting and um, yeah, the funny thing is like work at a startup if you if you really fill out your profile in earnest and really like do and do it well kind of put yourself, your personality and everything into it, um, I was very surprised that in less than 24 hours I had a bunch of people like dming me and messaging me on work at a startup, so it's like it's a very active job platform and um, yeah that's how I end up connecting with the current company is just like a cool dm from one of our founders like hey you seem like you'd be a good cook.

Yeah, I feel like my story is well; I feel like less relevant for the panel because I really honestly wasn't looking for like especially like such an early stage startup when I was looking for jobs. And it's like super heartening in hindsight to like learn about stuff like YC and work at a startup and all these places that like are so good for this. Um, I was definitely looking for somewhere where I could be like an early engineer but maybe like a 50 person engineering team around that size. Um, and then I just happened to I had the CTO reached out to a friend asking them if they wanted a job. They knew I was looking for a job and kind of figured I would be a good fit, so they set it up and I was like okay I'm willing enough to see what this is like and like take the interview and just like kind of got really excited after that.

We've hired a few people off of work at a startup and they've been great hires. I feel like we watch that forum very closely for anybody that seems like they'd be a good candidate or a good fit and yeah I would say for anybody that's looking that I've also told other friends like that aren't interested necessarily join Cambly like post on work at a startup.

Um, and then going off of what you had kind of mentioned during that you were looking for a larger slightly larger company. People have been asking questions about like weighing compensation when choosing to work at a startup or working at a bigger company. Anyone have thoughts on that? I know it's kind of a broad topic.

I, I you said going off of me so I feel like I'm kind of on on duck dancer. I don't necessarily have kind of like the best suggestion for how to weigh that like I don't know it's a tough thing. At some point you have to view a startup as like being like incredibly calculated risk, not just in terms of like I could work here for six months and it could be told after that but also like I'm going to take less compensation and it's that hope that like the experience you get not just like technical experience, but like the holistic just like the fun that you have is like worth kind of all the other compensation that you might lose. I know that's like not concrete advice, um but that's kind of the best logo in my experience.

Um, in this last job hunt I had applied to lots of different startups and kind of they were at many different phases. It was like pre-Series A, Series A, Series B, C, Series like I don't even know how many. And I would say that there's actually at least four kind of the talks that I was in um and maybe because it's, I'm kind of lowering years of experience for engineering it seems like compensation for like earlier career engineers it doesn't really technically have to do with at what stage the company is at. So it really depends on kind of what the founders and stuff kind of or just what the company is kind of willing—are they willing to pay what other larger companies are going to pay? And so it, I just want to say that like just because it's a smaller company doesn't mean you're going to be compensated worse than a large company. You might lose out on perks like, oh, um, I don’t know like gym membership or like things like that but if you tally up kind of like the monetary value of a lot of these things maybe you're missing out, you're missing out on like less than 10k or something like that. So if the experience is really valuable to you and I know for some people like saying oh it's just 10k, like that's 10k, it's totally different so everyone's like financial place is very different but um, if that number doesn't matter as much to you at least from my experience, kind of just because it's a smaller company I was very happy with the compensation that I got so yeah I think for me the experience was kind of like the dominant factor of why I made the choice I did and so um yeah I think I think that's like I think that made the choice much more easier for me.

I think like and I look back and I totally think that was the right call like to value the experience above all other things especially like if you're really early on in your career like that's just we all talk about like explore exploit. Um, that's the time to be valuing the experience higher if you can.

So another topic that came up in the questions is around mentorship um as well as just like developing technical skills. So as a technical person when you join a smaller company I think the expectation is that there aren't as many people there who can mentor you or kind of serve as a technical mentor as well to kind of help you with your skills. Um, what was your experience like joining a startup and thinking about your technical development?

Um, I guess I can go first. I think the cool thing um here is that even as like, um, one of them like more junior engineers in terms of like years of experience on this team, I still kind of get invited to interview new candidates and their take is that they want everyone's opinion on like growing the team and especially for me would I want to learn from this person or like would I feel comfortable working with this person because it wouldn't just be kind of like a top-down approach it would be like a two-way street kind of thing. Um, and so at least I that's what I find really cool and what has worked really well for us.

Yeah, I think including everything on or including everything everyone on everything or at least like making people optional is pretty huge. I also think that we took a lot of responsibility to like take on that mentorship ourselves. I don't have—I didn't have that much React experience. We have a front-end engineer he would make pull requests, how can I do code review? Like and how can I code review a be accurate and be like help him grow? And the answer is if I just like ask a million questions on the PR of like why is this just like this doesn't make sense to me but I don't know why and like even if I'm wrong on every single point like he's getting the sanity check so it's good code review and then like I'm getting to learn like oh this is why things happen like this and React and then like the next PR hopefully I'm able to ask fewer questions or like more targeted questions and then like a month down the road because like we've been working together so much in this way and he's been mentoring me just by the virtue of writing code I've become a stronger React engineer and his React code is hopefully somewhat better.

Yeah, I think I had a very similar experience where like we weren't necessarily experts, like we none of us had kindly had written React and we just kind of had to figure it out ourselves but through good code reviews and a lot of like talking back and forth like we became experts in React and so I think the way you grow is different like you don't have the person that's like I've been writing it for so much longer than you so I can help you come to speed on it. You have co-workers that hold you accountable um to learning it and becoming an expert in it through your own self-driven study.

Yeah, and even if you think you are that expert, like you someone asks oh why did you do it like this, you're like oh shoot I actually have no idea and then boom suddenly like the expert has learned something.

Yeah, I think, I think mentorship at least earlier on when you when your company size is small instead of the word mentorship I would use more like knowledge sharing because it kind of ends up being more like like there's not like this ah the one god engineer that knows all like that's not really how it works and so like everyone kind of shares a piece of what what they've learned so far and the context or any troubles like oh yeah don't do it this way because this is this and like oh yeah this is this is like the better way to do it because this isn't this and so just like knowledge sharing the context makes everyone kind of scale up technically.

So I have a question for Paige.

Sure! Um, you work at YC, so you've seen a lot of founding engineers. Can you maybe share what are some good qualities and bad qualities of a founding engineer?

I think this question was kind of answered and I also welcome the panel to to chime in too. I think the biggest thing is adaptability as a positive trait. As you kind of gathered from what they shared earlier in the in the talk, they didn't do just one thing. So you might be hired to do a specific thing and you might, you probably do need a technical skill set in whatever the company is currently doing, um, but being able to do beyond like more than just write code in that one specific language or for that one specific use case is really important.

Anything just in terms of like negative characteristics or things that might be a deterrent is if the person has no interest in doing anything outside of just one thing specifically. Um, still pretty broad, but I think that's kind of been echoed throughout the answers.

Any, so from the panelists, any final words of wisdom for the audience as we wrap up?

If you want to be a founding engineer, being a founding engineer is more than just engineering. Um, so I would say that really really do some introspection to see kind of what your strengths are outside of engineering because your company if you just decide to join early is heavily going to rely on those skills. So always kind of make sure when you're interviewing like emphasize those other things other than your technical experience as well because that's really what might differentiate you between other candidates, other than like your lengthy list of technical skills and experience.

Yeah, I think at the end of the day it's one of those like no plans survive contact with the enemy kind of things where like you can have the longest resume but like every challenge is going to be thrown at you and like every like so much is gonna like go wrong or go sideways or not go how you planned and it's like all about kind of how you respond to that and like that more I think comes from like your character and the people around you and like the trust everyone has in each other more than like any like experience you've had on your resume.

Yeah, and maybe I'll just weird one other thing from earlier was um, the ability to like launch quickly and not be afraid to throw things away and sometimes you'll have to write some code that you're not particularly proud of to test a hypothesis quickly.

[Music]