[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 or 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
and before this i was at google which is
where i met one of the founders of
cambly which is how he 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
finley uh 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 um for
joining last october i used to be more
of a kind of consulting
software engineer and so worked on
projects here and there and in my past
life i like to say i was a molecular
biology researcher so i was the leader
in life career stitcher 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 uh with i've been in xflow for
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 xflow 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 xblow it sounds
like a great opportunity to
start learning how to do that learning
like how to build
a
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 uh 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 um but this is the
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 what is a funding 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 for uh
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
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 like
responsibilities to bear
my experience was a little different
because i 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 uh 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 um 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 it 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 um 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
um 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 on your company the one 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 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 company's car 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 as the company grew how did your
role change
um and
how 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 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
on boarding 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
nines 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 on board 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 on
board 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 today
just because
i
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
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 finley i think we're at about
the same size
as expo 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
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 sunken cost fallacy
so like you you just need to kind of
roll with the punches and kind of
be fluid to wherever this
raging river takes you kind of 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
um i know that will be a contentious
statement for some uh 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 up 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 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 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 uh 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
rock star 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 higher engineers um
even though it's not um and then
the second half of your question was i 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 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 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 guard yeah
yeah
i'm also the founder in union yc startup
but i 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 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 uh 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 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 like more products 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 in your role with like
cto you know and also in different stage
of the startup so
i think it's like yeah open
communication is really helping like
with the founders like a team to 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 uh 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 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 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 two 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 the
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 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 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
gary 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 eu
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
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 it can't play
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 commander 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
um 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
uh 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 uh 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 cooker
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 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 lego
in my experience
um
in this last job hunt i had applied to
uh lots of different startups and kind
of they were at many different phases it
was like pre-series a series a series
bbc 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 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
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 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 survives 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]
you