Hi everyone, my name is Patrick Akil and in this episode we
cover how to be a great software engineer.
So how to go deep into this individual contributor role and
we slice open the topic of lead code very controversial.
Is lead code a good thing or a bad thing?
Find out. Joining me today is Idiya
Pimenov, Senior Staff Engineer over at Myro and just a great
guy in general. So enjoy it.
I was actually on LinkedIn yesterday and I saw this poll
that's a guy I followed that used to work at Google and has
actually quite a good track record.
And his question was, if you were to start your career right
now and get into software engineering, what position would
you probably fill first? Front end engineer, Back end
engineer? Full stack or other?
And then the other people were like QA analyst, business
analyst? What have you to transition into
software engineering? But the biggest amount of votes,
and this was like 2500 votes, was full stack engineering And I
did. I did not expect that.
Why not? I don't know like full stack.
Really good full stack engineers for me know back end well as
well as front end well. And to start off full stack I I
it does help you get a complete understanding of how things
interact with each other, but to start off with that can be a lot
I think. Well, I mean I do unconsciously
think that most people mostly unconsciously start as full
stack engineers because you started some, well depending
like how you start, like you started some computer science or
you didn't or you like I don't know, had a boot camp or started
by itself and then you somehow hassle to get a job.
And basically what do you do at the job?
You just do everything that needs to be done more or less.
You very often do some, like Python, shop HTML and then
connect this to some zippier. Or you just make things work
together. You glue them together.
You're not really good at any particular fields, You're like
very on the surface of things, but you solve the technical
problem of things working together as a product.
Essentially it's a full second generic.
I guess, yeah, that's fair. Maybe I was very biased because
how I got into this, it was not with the traditional computer
science background. I had more of a data science
background and I got into a position where people were their
consultants actually from this company and their task was to
educate me and make sure I can do it without them.
And they were like OK, so have you ever done front end, back
end? I was like a little bit here and
there because we had an exercise in university and they're like
let's pick one and focus on one to start off with.
And I was like OK, I always liked more of the logic site.
So I started with more back end related things.
That's how I got into that until I got to a point where I was
comfortable with that. Then I got into this consultancy
organization and it was like, OK, we don't really have that
many back end specific projects. We have this project with this
which is more front end. Have you with a little little
bit of back end, do you want to learn?
And at that time I was like, I'll learn everything.
I want to learn everything. Still I do.
I think it's great mindset. I think if anything, the best
thing you can do is to keep that mindset.
Well, I've been developing for quite some years.
What I'm I'm 37 now. I started when I was 17, my
second year of university. I joined Sun Microsystems and I
still everyday I feel like I have still have so many things
to learn. Not that they're complicated or
what not, but they're just like I like exposure and I want to be
more exposed because I want to continue to be irrelevant, to be
able to not just manage things but also work together with the
people. It continuously confuses me like
when people sort of run around and they're like, yeah, we need
to build this and that and how we're going to stuff our team
and the way we're going to find the people.
In reality, most of the things software, like I would say
probably 80% is really not hard, like maybe not 90.
It's more like gluing things together integrating.
Yeah, unless you go with like really really deep stuff, you'll
become like Paris in in the back end.
So yeah, building something for a company that has a very huge
scale and like a very big risk exposure.
Most of things are just like you type some texts and strike
computer to do something. Like I really struggle to find a
complexity. It's more fun than the
complexities. Like people are afraid to go
into something and like just try to engage themselves into it and
then they procrastinate for sometimes weeks trying to find
somebody else to help them while they just could have, yeah, bite
the bullets. Spent 2-3 days crunching on
something trying to learn and they would have been OK.
You saw the particular business need and they were able to move
forward. Yeah, it's interesting that you
cut that open because for me, I like the challenge part.
And then at some point you get really good, you get productive
and then it kind of gets automatic to a point where you
lose that challenge sense. And that's when I step away and
I'm like OK, what is another challenge or a new challenge?
And then another challenge could be kind of within the same skill
set. So let's say I was very focused
on back end engineering. I could do another back end
assignment or join a company and do a project like that
specifically, maybe a different domain.
I for example moved to IoT and there were very different
challenges on the back end side for that or that's what I've
done recently is another challenge in the form of not
specifically back end engineering, but more what is
next to that, what is around that and I found that in product
management. Yeah, I have never experienced
product management for me, so I work a lot with product managers
and very often with multiple ones at the same time, but.
You've never found the the allure.
I guess I was always afraid to talk so much with people.
I was like, yeah, I really have to talk with a lot of people.
That's the job. And find the joy in that, if
anything. Recently I learned that one of
the better product managers with whom I work like a very strong
gentleman with whom I work with Miro, that he considers him
himself as an introvert. And I was like, very surprised
by that, Like you're like all over the place talking to so
many people all the time, like hustling day and night.
Like how must be exhausted and yeah.
I I also consider myself an introvert, and yesterday I had a
lot of sessions. I was I was exhausted by the end
of the day. But I like the friction and I
like trying to mediate that from the driver's seat instead of,
let's say, from the developer's seat trying to push up.
Now I feel like I have a bit more autonomy to do so.
Don't you feel like other people will shine better in that
position? Maybe.
Maybe like I'm still trying to find my drive and see if this is
actually, first of all, something I'd like something I'm
good at. People are telling me I'm doing
a good job. But yeah, I mean, I don't see it
as much as other people do. So I like challenging myself in
that as well. And also like with development,
is it then going to be, am I going to look to the next
challenge when things are less of a friction?
I'm not sure yet. But it's like there seems to be
like 2 schools of thought. The I mean you have array of
skills and then some of them you're better, some of them
you're worse. And then to become like stronger
self altogether as professional you can either like focus on
those that are weaker and then your average will go up, you'll
become a good all round professional.
Or you can just double down on the stronger sides and like
fully neglect the weak ones, like just give up on them.
And I guess either can work in reality.
What more like? What has been kind of the
challenge because you've gone more of this individual
contributor route? What still drives you and what
is like most interesting to do on that path as well?
Well, I mean, I need to give some retrospective I guess, how
I ended up here. That's fine because I've been
working as a engineer for quite some years and already when I
was working at eBay I got to what they called the member
technical staff. But at eBay it was a bit odd,
like you also manage people. So I was like people manage
exactly something between both. I think sometimes it's called
TLM or something else. But basically I had people
reporting to me both like FTS and full time replace and
contractors and I ran a part of the product and developed that
part of the product. So I worked closely with the
product manager and the team and did something myself and also
managed a lot of people and the performance cycles and things
like that. And I did it for quite some time
and I was like it's OK. But at the same time I don't
fully feel like Blesley challenged.
I'm challenged more in the amount of work and the politics
and the internal communication and doesn't seem to be that
challenge and just more like the working to continuously do and
like keep focus on that. There's more work.
Yeah. And then I was asked to join
this company which was sort of a studio.
It's basically they asked me to be an intern, CTO for a venture
backed start up that was built in a vertical marketplace.
But it was like a full Greenfield project that was like
nothing, just zero at the beginning.
So hands on CTO. Yeah, yeah.
Well, because initially they're just like, no, but exactly two
people from another project, they were doing 3 already, I
don't remember. And some like architecture that
we were able to inherit because like all the, I don't know,
Terraform code and everything else was written for it and it
was provisioned last on Google Cloud.
And the other gentleman, which was the CTO at this eventual
app, he was very comfortable with that piece of software and
we started building I think the first year it was just a lot of
it was again a lot of IC work and then we started hiring a bit
more people and expanding the team a bit.
It became got a bit more attention and focus.
I think by the the biggest size, it was like around I think 20
people or something. OK.
We'd had very informal arrangement arrangements, but at
the same time you had to manage people quite a lot and like
magic. Also expectations left, right up
and down and there was some people in management, but at the
same time, Oh yeah. Anyway, Long story short, that
experience made me feel that I am moving away from being able
to just build things directly. And I didn't fully like that.
And I thought it's a bit too early that like, I mean some
people, they try to jump into management track as fast as they
can and like, yeah, I won't do that.
I mainly just wanted to do things and enable product
building or like make something that people find useful and be
engaged while doing that. And I thought that OK back then
I was 3536 and I thought that maybe I can spend another at
least five years in IC role before like going into more
management track and then I will enjoy it quite a lot.
But then I will need slightly bigger field to play in because
like. Not a start up, you mean?
Well, I mean you can be. You can also do it in a start
up, but as a staff engineer you like need somewhat of complexity
to be able to solve those problems If there's no
complexity. I mean you can call yourself a
staff engineer or anything else, but like in reality you'll be
just a good senior and you'll be just crunched on lots of code.
But you wouldn't be solving this like non linear puzzles, because
very often you just have to jump into the field where there's
there's lots of ambiguity which is mixed not only with like
technical stack or historical solutions or architecture, but
he also had to navigate the politics of the company, the
interests of people, the sometimes performance cycles or
desires. And what people want to try to
make some part of the org work together even though they're
maybe not like formally directly part of the one reported in the
measurement chain. And I find those like normally
challenges interesting because I've I feel like that some has
blocked. I do have like an array of tools
that I collected over the years and some of them are like
stronger than others that I can utilize in order to address
those nonlinear challenges. And I find it fun.
It's more like I almost say those like, oh, it's an
interesting problem. How can I solve this?
How can I make it work that in negative limitation, So the
desired delivery days will have something that will make
business sense that we can build up on and that we'll be able to
sell through their organization and we'll be able to build with
the capacity of people and the skills we have right now And
those that we're able to do a little further, like a lot of
things like Intersect at the same time.
And once it like clicks and you like trying to sell it and work
through our organization and you feel like, OK, it's going and
like, OK, yeah, puzzle solved and you feel like very nice,
then just like sort of capitalize on the tale of
implementing that solution. And that's what I like.
How do I get here? I don't remember.
It's more from the from the execution side.
And I mean a lot of what you said triggered me in that I'm
now on a path and I don't know what my next role is going to be
because I've I've done a lot of IC work and at some point it
becomes more mundane or there are challenges, but once you
solve them, it's more of the same.
And I don't think this routine of Sprint after Sprint really
helps in that. So I'm trying out product
management. I'm having a lot of fun with it,
but I don't know where the end is or if this is, let's say, a
longer term path. Another part could be
engineering management where I probably go into what you've
experienced and that's more personal development, but also
budgeting with regards to what we can manage and setting
expectations and finding kind of buying within organizations,
things like that. And then the path of developer
advocacy, developer relations, which is more of podcasting and.
That's very completely. New as well.
I personally don't like have that drive in me at all, and I
saw people that are good at it and I'm at O, but I somehow just
don't feel it. It's just a shame, like I think
it's it's almost impolite to the industrial to give back, you
know? Yeah, I mean, I think, I think a
lot of people do give back in whatever form and there are just
a lot of forms to do. So I like talking.
I don't really like reading. So then writing, I mean, I've,
I've learned that it would help my talking.
So I'm not considering it, but I haven't really started that
much. But yeah, those are kind of the
tracks I see and especially when you said that you might have
been a bit early also at that age to jump into kind of more of
a high overall for me it's very interesting because I am already
now considering it. I'm on the on the part of the
people where you said they might have jumped too early, I'm not
sure. And I I do miss kind of this
fulfilment of executing and delivering.
That's what I miss right now. Yeah, but like, I don't think
you can be early and relative. Ideally you would always start
before you're ready. If you're ready, then you're
ready too late. It's almost always like this.
It's anything you do, but you're also gonna go back.
I mean, I need to go back and it's fine, you know, it's it's
all good. Yeah.
But I I wonder, like for yourself, to give you an
example, I personally somehow feel in myself that just
projecting Ilia forward like 5-10 years, I don't feel like
growing into enterprise management positions.
I somehow don't. It doesn't collect with me.
I don't find it interesting. If anything, I guess like even
at like 40 or 50 I'll be looking into just starting the venture.
So like going like from zero to 1 but like then growing it up
all the way. It's not necessarily something
where I feel I'm the strongest or where I get the most anger
from like I solve. I like solving the problems.
But once the problem is solved, I slowly become less and less
and engaged. I recognize that.
So in that sense, and I over the years trained myself to have
enough patience to see towards the like final outcomes or the
solution. I'd like to stick around and
implement it all the way through.
But I don't feel like that's like my strongest side.
I feel like I'm much better at like breaking the walls.
And that's I guess what I'll we'll keep on doing in in that
frame if I will look forward and how potentially we want to found
another company myself. The best skill you can have is
being in IC because like you will be in IC in the first year,
2/3 of your own company. Whatever you'll be building,
you'll have to be ideally, you'll be different, engaged.
And that's if you actually. Tech side they will some like
hustler on board or like maybe you'll become a hustler, but
there'll be lots of things to do to build just like with your
hands. So that's why I think the
current track still aligns with that potential out of my vision
for myself. So for that, I wonder, like, how
do you feel about yourself? No, that's exactly why I'm
hesitant because I I am like you where I don't know, it's
something entrepreneurial I guess that's always been in
there. I want to build something of my
own from scratch from zero to 1, make it scale and also all the
way through and the I see role and skills are incredibly
valuable there and then and early on and I don't want to
lose that. That's why I'm kind of hesitant
and I I try and kind of get a feel for a lot of things.
So then I can also judge kind of on that journey what is going
well and what is not going well. Know a lot of kind of
everything. But I still need depth.
That's true. That's why I'm hesitant in going
all in and that's why I'm trying this out now.
I wonder if that's true. You need the depth to start
companies like they don't have a company I guess.
I mean the people that started companies tell me that you don't
need that and just start it. Yeah, Yeah.
I mean you start and then you can just continue and you
acquire the depth all the time. But I feel like even like from
the knowing that little bit about you that I do if you're
now, I mean you've been the full stack back end and now you're
going to product that's a very good all around skill set like
that will also help you with fundraising, with communicating
with making the projections. I just talk the language that we
see to understand better. For me like that was a bit of a
eye opening thing when I was in that measure backed company that
yeah people find that way very important.
They talk a lot about that because like it's very hard to
reason about how are we going to build this, this way or that way
for people that are bringing the money and they're thinking about
the business like loan term. So in that sense, product
management experience is much more relevant, which I think
it's cool that you're doing this.
I'm trying it and I feel like, I mean, this podcast has gone on
for three years. I've worked on my communication
and I feel like I have the fruits now of that labour in the
conversation I have with stakeholders.
Like I can see and they tell me like it's very, it's crystal
clear and it might not have been clear or sometimes I don't have
it clear and when I do, it just clicks and I'm able to
communicate that as well. And that's really cool to see.
But I also know from the conversations you and I have
had, I don't have the same depth that you have when it comes to
the IC role. I mean just by looking at number
of years of expertise, you're definitely ahead of that.
And I'm very curious how you find that depth or how how you
continuously challenge yourself to kind of find new, find new
challenges there? I guess mainly like crippling
impulsive syndrome, just like always there.
And partially as I like. I feel like now the time I spent
in the industrial starts to work against me because like whatever
I was doing, I think already five years plus, like 7 years
plus is a bit irrelevant. People don't really don't work
like that anymore, which is fine.
But at the same time, somehow by doing this over and over again
you become much more brave and to like jump into any new field
right away and you will feel comfortable there.
Like I know to give you an example, I happened to work as a
data scientist for some time in my past and back when I did it,
it was for this attack start up here in Netherlands and
Amsterdam, essentially what we were doing.
We were listening to the Internet traffic of the whole
like country because technical drought.
When you open a web page or any other page on the Internet you
sometimes see ads right on the left, right like if you open
that don't mark plots it will be ads all over the place.
The way those ads are populated, whenever the page is requested
the request goes from the server to the what is called exchange
and over the open RTB protocol which stands for Open real time
bidding to with like stamp of your personal.
Well personal with your stamp of your data.
So that people that are connected to exchange can make
an educated guess whether to bid or not bid or that ad on that ad
spot placements. And then they'll like say like
OK I'm gonna pay it like 10 micros, which is like 1
thousandths of a dollar or a cent or if I got but like there
is little amount but then the highest bid wins and that bidder
pays the second bit. So that's how it works.
But essentially it means anytime you open a a web page with any
ad, the request will go to the Exchange Server and people that
are trying to beat on that place, they can listen to that
traffic. So if you build a company and
connect the exchange, it can just like listen to all the web
pages being opened in the country.
So, and I think nowadays it's not the straightforward and way
less legal, but it was before GDPR.
But essentially we collected that traffic from the whole
country of the Netherlands, US and Russia.
And we then try to profile the traffic and understand how many
people are there behind particular IP address.
Like is it the household, is it the household, how many people
are living there or are there ages?
And you can also like deduce that also we would couple all
your devices together. We will say, OK, we think like
this is your laptop, this is your smart TV and this is your
phone. Because if you travel between
and this is your work laptop. Because if you travel between
your home network in Netherlands, you'll have a
dedicated IP address. And then it will say the same
device with the same device ID which is sent to this exchange
on another network from another IP address.
And then it's like, hey, it's you like when it's in the
morning you're there and the weekend you're there see this
device showing up there and during the work hours this
device shows up in this other network.
So it's you and you are one person and you're going to work
every day, you know that. Long story short using that we
try to optimize the way to run ad campaigns like to sell
sneakers or what not. But we are doing that way.
Before Google Big Query came to be about or like this company or
companies like Snowflake or Data bricks and they were using map
produce, good old map produce which appeared all that white
paper. But it was doing map produce and
you like literally bought EC2 instances from Amazon and you
deployed your Hadoop there and you ran to your data pipelines
on your private map produce. It took forever, was very slow,
was very expensive, was very painful to work with as well
because like map, produce has very straightforward logic.
You can map things one to one, or you can reduce them like
some, like a sequence of things into the results.
So in order to express your more complicated data pipelines, you
would use things like closure to do these calculations and map
them to the jobs that will run in this cluster.
So I did that and after that I stopped doing that and I went to
eBay and it's a very different type of work.
With a go we'll build a a back end solutions for well also ads,
but like on the server side like where we maintain the invention
and serve the traffic of people come to the website and then
Fast forward to nowadays and all this like LL lamps became like
all over the place. And I have to say like even if
you are not buying into the hype but you're an engineer, probably
have to interact with them one way or the OR the other and if
you don't understand them well it's going to play against you
or you like it will hold you back.
You wouldn't be able to advocate or talk about the same
complexity of products you're potentially can build with them,
especially if you're more like specialized in back end and
specialized in back end. So it's like, oh, OK, I think
I'll have to dive back into that field again and try to
understand the better. So yeah, I am now trying to see
how to build your own LM from scratch with the Python And
stuff. And I feel very out of my depth
because I haven't been doing anything like that for like ages
and ages and ages. And I start with the baby steps
with I think like almost anybody will be able to do, even if they
like, have like one year of experience of programming,
they'll probably be able to follow the same path.
Like maybe some of the math is a bit more complicated than it has
to be sometimes, but in reality it's all linear, linear algebra
and you had a university. Or if you spend half a year or
so starting it, you'll be fine. But I have no advantage over
anybody who started this same field like a year ago.
Maybe I'm more comfortable with, I don't know, my Vim and stuff
like that, but that's not a big advantage.
And the amount of time it will take me to get on up to speed,
as well as the same time as we'll take anybody at the
engineer with one or two years experience to get up to speed.
I I think you might be doing yourself this justice there
because the like the perspective and the history that you've
built up, you can leverage that in whatever new thing you pick
up. Like if I really pick up
something from scratch, I've never done that.
If I've picked up many things from scratch and I've never done
that, you get better at actually the comfort zone, how to break
it down, where to start going through those steps.
And especially when I did back in engineering, like I I would
pair program and this person would talk me through
everything. And after I did it, I was like,
well, I have no clue what I actually did.
But now we we achieved this, so I felt good.
And then at some point you get to this mode of doing it
yourself and doing it more often.
And in the beginning I strolled, I was like OK, where do I start?
And then you learn to step back and not actually immediately
jump into it, but theoretically break it down your head or make
it small or actually start in the 1st place and don't go into
analysis paralysis like those things I feel like help me pick
up new things faster. But you're right.
If there's a new thing like LLMS and you don't actually know how
it works, and that's the route you want to go with regards to
education, then yeah. If no one has ever done that
from an education standpoint, you're all the same.
Yeah, yeah. Maybe it's true.
Maybe you'll become like very comfortable with getting out of
the comfort zone and just like doing, you don't dwell around
you just like, OK, I'm going to do it.
I'm going to go right in. And I'm not doing that, mostly
because I don't know if I need it and I'm not sure if I care
enough to actually figure out how it works.
You don't care about other labs? Come.
On like I I like using them, but do I really want to know how I
would make my own model or do I want to make something out of
the models that exist that's for me the difference.
It annoys me that I don't fully understand how they function
through and through. I can see that every time I'm
like looking at the Pi. So try and do this like this
prompt engineering. I'm like I feel so annoyed that
I don't understand how it works inside.
Yeah, like I'm, I'm curious, but to be effective, let's say in a
product where we have to have something that analyzes APDF and
then spits out based on the contents of the PDF, which might
be like 300 pages, the right answer based on the question
that you have. I I would, I think be able to
build that without knowing what the model actually does to a
certain degree. And sure, I would have to go in
depth to some point to get it done, but I think I could
execute. I might not understand the full
thing and I'm not sure if I need to, but sometimes I just I don't
understand or I don't want to understand everything below the
surface and that's definitely different from you and I.
Yeah. I kind of do like, I'm like, I
deny, I I don't believe that magic exists.
So whenever it feels like magic, I'm like, yeah, no, I'm going to
find out what's the trick. Yeah, yeah.
Like, yeah. And I think that's, I mean
that's probably also why I initially said I think you have
a a deeper path on the IC Rd. than me so far because I've
always had OK, what do I need to do, how do I execute And sure I
go deep in in certain degrees like I'm going to give a go
fundamentals training that's more on a language level and I
need that knowledge to give the training.
So I I got the knowledge and I'm still not there, like I still
can go deeper probably. So I execute based on what I
need to do and also just on interest, maybe LLMS would have
interested me and then I would go down that path.
But for some reason it just doesn't that much.
And for you I feel like you need to know a lot, but I do think
it's an interesting case. A lot of people will want to be
productive or will want to know and I've seen let's say
variations in how deep people want to go with regards to
certain subjects. A back end engineer might go
really deep into back end engineering and then all of a
sudden cloud pops up and they want to be a Google cloud expert
as well when it comes to the infrastructure and how to most
optimize whatever you have that is running.
And I don't think there's a bad path there as well.
I somehow I think focus around disciplines around back in
engineering predominantly that to me it always felt and still
does that in a in a grown business.
That's the place where you can get the most impact as an
engineer because you kind of control the things tied
together. You work with the scale as well,
yeah. I feel like about 10 years ago
that you could get a really strong advantage if your UI and
UX were like top notch. OK.
But, but now, yeah, everybody's UI and UX is top notch.
It's like just became the new normal.
And you don't surprise anybody with that.
And you can't get a huge outsize impact through being good at
that. That's interesting.
But it's my subjective feeling. Well at the back end stand you
always things that will have the scale.
They will probably have a have a back end solution at some point.
Yeah, that's interesting. For me the like I I have done a
little bit of front end. In the end it ended up being
two, 2 1/2 years and I now really appreciate people that
can do that well. And I I do agree.
Let's say I don't know if it's the barrier of entry, but there
are a lot of front end engineers and the people that are really
good, like I appreciate that because they know from history
everything with regards to JavaScript or a lot of things
that make them more productive. And they're very, very good at
classifying when they need what with regards to requirements or
if they actually don't need it. And I'm not sure if that's a
front end specific skill or if that's just good engineering.
I think it's just, yeah, good engineering altogether.
But I I feel like there's a whole new class of front end
engineers. Like they know how the browser
works, like what kind of threads run, what threads will deadlock
or will be too slow on how to access the internal storage and
optimize that. Or they will start writing Rust
and compound things into Avastin and then tie this together with
their main application. And that's like a whole new
depth in the front end development like it's.
Yeah, that's new. That's like, that's super new.
And it's also like super hardcore, you know?
You like sometimes there's like deep into the brain of Rapid or
something like, whoa. Yeah, It's getting depth.
Like it's not comparable I think to what we had five to 10 years
ago. It's getting more and more depth
to a point where I'm like, OK, they're like, OK, you need less
infrastructure. Oh, you might, you might not
even need a back end. Oh, we do everything on the
front end. Like it's some patterns There
are really funny to see. Yeah.
But I want to touch on interviewing as well because you
mentioned you, you started at that CTO position very much
hands on and you grow you, you've grown the team then too
said about 20 people and probably in your career you've
been very involved in hiring as well.
In our intro call, we touched on lead code and I told you in the
Reddit communities that I'm in and also on Twitter, people hate
leak code. At least that's kind of the
general mindset. What do you think about lead
code? I love lead code.
Moreover, I wish there was more of it, like everywhere.
If anything, I think companies that don't ask lead cause
questions, if they could, they would have like they just don't
get the people that will be able to pass those interviews.
OK, I'll try to break down why people use lead code interviews
from the first principles. Like or like you have an
interview process, you have a person in front of you, you want
them to solve technical solutions for you in the future
and now you want to hire them for now.
But probably you plan to grow as a company, so you also want to
see them to be able to grow and like navigate for the complexity
that's going to appear as a company.
You have some domain, whatever that is.
I don't know, maybe it will build marketplaces, maybe
building construction or what not.
Or maybe you are selling luxury goods different or like you
build something like mural, you have some domain which as an
engineer you'll have to understand better and better.
Maybe you're in Texas so you'll have to understand the main of
Texas and you all should be able to negate that.
How can I verify that you are capable to acquire a knowledge
in some domain and then operate with that complexity within it?
Like well, I need some domain that we all share that I can
assess and then can reason about.
Because like if you come to a company that builds, I know
factories, it's unreasonable to expect you to have any domain
knowledge about that field and you wouldn't be able to utilize
it. So you want to have a shared
field, discrete analysis, all particular like algorithms and
stuff like that, that is more or less the shared field for all
sorts of engineers like you all use it one way or the other.
So it's a very democratic to ask things in this field because
like it's quite OK to expect you to know that field.
Like it's not a brand new field for you.
So you are able to tap into a big pool of people that are
coming to join the company to like expand your incoming funnel
first Like people that are able to come in because you for
example, you'll be asking them hey can you please build this in
Turbo C because we use it on that microcontroller and the
task is that the light switch go up, up and down like.
You have to figure that out. No.
Like, it is. Like, it actually this micro or
this microcontroller Turbo C like when was the last time
anybody used it? God knows it's unreasonable to
expect you to have that domain. And like, if you'll be like,
yeah, but no. But we're going to have like
questions like that, like you're coming in front of people able
to like even walk into the door. It can be a very tiny,
nonexistent almost. So you shoot yourself in the
foot. So that's already where the code
helps because it's a common shared domain.
Lingua Franco then, Yeah. And then you are given some
problem and you want to see how the person.
It's not that you will optimally solve the question, it's more
like that you will be able to take the interview with you on
the journey of solving the problem.
Like you kind of first want to clarify that you understood the
problem correctly. You want to ask her around to
understand what other ambiguities were there.
That one mentioned on my interview forgot to tell you or
didn't tell you on purpose. So you understand like, OK,
what's the scope of the problem? You can scope the problem.
Then you can assume, OK, I have like 45 minutes to address it.
Like at what level of depth can I address it in this time at
like surface level, but that's fine.
And then you try to work out this plan and sell it to the
interview. OK.
I think I'm going to use Brett BFS to walk around this graph
and then I'm going to find the shortest path and then going to
do something with a solution. And I think it'll have like
roughly complexity and like and take some resources and like,
yeah, yeah, OK, like this seems fine.
Then maybe they will correct you.
And then they want to say that you OK, you size the problem,
you solve the solution and then they want to to see you execute
on it And you just like, I don't know, write down 10/15/20 lines
of code and then the problem is like solved altogether.
So you have been like dragged through all the things you'll be
doing as a engineer which will take you like in a month
probably, but like in the microcodes as a lead code task,
which is nothing wrong with that.
Like all the things that people want you to understand, space
and time complexity of the problems like those do show up
in your work at short senior levels.
Like once you especially if you're in the in the back end
but also in the front end like it's a big problem if you have,
I don't know, N + 1 queries. Like it's like when you're
querying something database in the loop, they're going to kill
the performance. It's going to be horrible.
It's not rocket science to go from like yeah let me to just
like make one call bash everything else.
But like just so you understand where do you create complexity
and how do you create it where you create complexity in space
and time. It does help you a lot to build
better solutions that scale better and that are easy to
maintain and that are cheaper. And I do feel like that like a
feel for this space-time complexity and algorithms
transfers really well to build and just seeing complexity and I
don't know in software they should build and wells like in
life. I don't know how you lay in
bricks in your apartments. I think mainly due to your
experience, you see how it translates and a lot of the
frustration where I see it is maybe idea earlier in career,
but even with senior engineers, they don't see where it
translates. And then I get it because if you
don't see where it translates, you're like, OK, I have to learn
this trick specifically and when I land the job then I'm doing
completely different things. But I think there are places
where you would see it, or at least you have to think about
it. I think the disconnect happens
mainly at like entry levels, like at junior or medium.
Medium positions you'll probably be doing like very straight or
fault things. You'll be trying to send how
things are tied together, how they work together.
You'll be doing like. Just bricklaying basically the
software and yeah then doesn't translate but not handle skills
will hold you back from being able to grow for their career.
And ideally, ideally, companies don't want to hire somebody that
will like reach their ceiling at the media level because it's a
bit of a waste money. It takes quite a lot of time to
hire a person, to educate them, to give them the company.
And it's nice if you're not like this person has further
potential to grow further and further and further if they want
to, because you want to be able to be able to grow if the
business grows altogether. So it's much better to hire
people that you know, OK. That person will have a
potential to grow into high complexity and probably they'll
also will do that fast because of this exposure to late code
and stuff like that. What I don't understand like
people complain like yeah, it's useless.
It doesn't take a huge effort to become better at the code
problems. Like there are just books
written like Grokken the Code and interview stuff like that by
these people from Google. This late code itself, it has
like I know 2000 problems altogether.
Like 400 of them are easy and they're like basically trivial.
It's more like can you altogether write a four loop at
that level? But if you saw all of them, then
you'll feel much more comfortable to do like medium
level. And if you solve like 2 or 300
of medium level, you can then tap into some of the hard ones.
All in all from being able to write basic code to be OK,
delete code probably it takes half a year.
If you just like do it a bit every day, every day, spend half
an hour so you have like half your investment and then you're
able to go into any tech company to come join them.
Almost. It seems like rather good deal,
like I don't know where else you have to study for half a year
with some focus and then being able to tap into good employment
opportunities. You don't you can start like
medicine for half a year and then go do something like
nothing and work years can take like 8 years plus absolutely
like. So what's the problem there
like? I don't know, man.
Half a year and bam, all the opportunities can work almost in
any country you want as well. And if you speak English, I'm
like. Yeah.
Seems like a good deal. I don't know.
I struggle to see how it's how are you on the bad side of this
equation? You're.
Slowly convincing me like I was. I was in the camp of.
And it's also because I'm not great at it.
Like if I were to do a hard exercise right now, I could
probably not do it. I've done a few here and there
and also to prepare for interviews.
And it is effort, effort that I don't know if I want to spend,
but I can do it. I'm sure.
I just have to bite the bullet and do it.
That's the thing I do like this mantra and also transitioning
from the interview that I see them do something more, let's
say still standard, where we can still have the discussion where
it still has some of the complexity, but it's more
related to what you would actually do.
Let's say, OK, we're in the e-commerce domain, or even if
not, e-commerce is actually pretty standardized nowadays.
In any case, get an API, tie it to a database, ask for an order,
see if it goes through based on inventory, things like that.
That's the interview style that I like as well, because then
we're talking about APIs and not necessarily complexity and
isolation, because I can still be, like you said, do the effort
of half a year, be really good at complexity and isolation, and
then make the wrong decision on where to implement what.
That's something that's harder to challenge with regards to
specific algorithmic, let's say, exercises.
Yeah, but you will make errors. But also like there's others
topically touched that's more like system design interview
rather than coding, right? Yeah, that's fine Do.
They go hand in hand. Do they go hand in hand, do you
think? Well, usually those are two
different interviews, like, and they partially test similar
subjects as well. Like, especially in the system
design at high positions, you will have to think about
problems of scaling quite a lot and you have to think about like
functional, functional requirements and those things
and understanding of complexity will help you quite a lot there
because, yeah, it helps. Like, back to your question,
when you say like, if you try to solve a hard, difficult problem,
it's hard. Oh yeah.
I mean, if you go to the gym and you put like 200 kilograms on
the bar and try to lift it, it's going to be hard.
If you'll put 50 kilograms and lift it, you're probably able to
do that for like 10 times. You do that for half a year
you'll be able to put like 75 kilograms of that bar and
another well probably yeah no how long.
But at some point you will get over the 100 and you'll be like
OK, this is approachable like it's the same thing of going to
the for the hard it could problem that's trying to like
lift 200 kilogram bar from the ground up while not ever going
to the gym. Like it's a odd expectation that
you're able to do that so that you would feel comfortable doing
that. Of course not like it's it's
ridiculous, like your brain is also sort of a a muscle you can
train it, your cognitive abilities.
And that's also how I feel like sometimes when you solve those
little problems like the the head hurts a little, you know,
it's like. Absolutely.
This gun together and trying to draw it out and read the
solution and like. I still don't get it.
And it's just like, it's painful almost sometimes.
But then once you go through the pain and you understood it once,
all of a sudden like, Oh yeah, that's approachable.
And next time you're like, OK, this was actually how did not,
how did I not get it earlier? So it's a very similar process.
So just like, train your cognitive abilities to see those
things. Yeah, yeah, yeah, it might be
then my so I've I've never gone deep with regards to Lika, but I
feel very effective. The parts were throughout my
career. Where I didn't feel as effective
as I wanted to was where I would either lack fundamental
knowledge or lack depth. So I would I would feel
effective or think something and think of how to do it, and then
all of a sudden I would get stuck or be like, why did that
take longer than I expected? Then I would realize that's
actually either fundamental knowledge or depth that I was
missing. But I would do that
continuously, and I've never actually done this proactively
because I I do it reactively based on whatever I need to do
basically. And I feel like the lead code
approach is more proactive if you compare it, if you combine
that then with system design, if you can both do both really
well. You're just a really senior
engineer I feel like or an individual contributor in that
way, but also senior. And that's, that's the part
maybe which is underestimated or at least where I would
underestimate it because I expect, I expect to do what I do
now or at least in the most sense like you mentioned, we
don't really do complexity all the time with decode.
It's complexity and in isolation.
Yeah, yeah. So it's a perfect way to train.
You almost can like speed run your own career developments if
you get better at the, yeah, lead code and system design,
because you'll be able to tackle bigger challenges faster.
Yeah, like it's not gonna take you five years to grow that
path. It can take you like 2 pretty
good I think. Yeah, that's what I love about
what you said that it's like it does sound like a cheat, at
least how you laid it out. And I never viewed it like that.
I did see it as a hurdle, to be honest.
I was in the camp of, OK, why? And in reality it's it's there,
but it's not as much there. And it's just this hurdle that
you have to pass. And I still believe that, but I
also believe that you build really good fundamental
knowledge if you're good at it, or at least if you pass the bar,
let's say. Try to present like the other
camp, like people that think it's useless.
I don't think it's useless. I just think it's not
represented enough of what you would do on a day-to-day.
Oh. For sure.
That's that's what I asked this. Like, yeah.
Like moreover I I know a friend of a friend who was he was very
good at lift coding and he just like spent lots of I think he
sold like 75 to 80% by the time he was still in university.
Like he was spent a lot of time on just lift coding, nothing
else. He was doing computer science
and then I think he got himself a junior position at Amazon or
Facebook and Facebook. Good for him.
And he was like, absolutely useless.
Like, he just wouldn't be able to do anything.
Like he literally couldn't write any code altogether.
He better than you. HTML.
Like he was only good at lead code in solid puzzles.
So like, he got in and then he had like a very frustrating,
like year and a half or two. And after that he was kind of
like. Yeah, I'm out.
It's all called peeped out, like on the performance improvement
plan. Oh, wow.
Oh yeah. Because, like, he just couldn't
deliver anything, even on like very basic level and struggle
with everything else apart from the coding.
So you can also do that if that's your plan.
Please don't. It's a bad idea.
You're not going to be happy. You're going to feel pretty
miserable even if you're going to get in.
Yeah. So yeah, what?
Will be a good balance then, because I get this question a
lot as well, but that's more on the soft skills side.
If we stick to the technical lead, code is part of it.
You mentioned system design as well, but what makes a really
good, let's say senior engineer or even beyond?
Well, I mean. I know it's a broad one.
That's a very like, open question, and I don't feel like
the solution per SE license in lead code or system design,
although there's all like for lead code.
I think they have like a list of these interview prep questions.
They're like 150 problems. Just solve those, you'll be
fine. And they also like gradually go
up from like easy to hard. And like if you're also trying
to solve a problem, you spend 45 minutes on it, You still have
nothing in your head as to how you can approach it and nothing
works. Look at the solutions like don't
fight further, like if it's like exercise you try to take it
doesn't work. You set the solution.
You then implemented the blind without looking at the solution.
The learning process already happens and you spent like 2
hours instead of spending the whole day on the problem like
out of those 150 or how how many they have for the the interview
course they have out of that. You're now getting it much
better. If you will start enjoying it,
sure continue. But it's not kind of the the
point of dimension turns around there.
Like it's not going to get better For the system design,
yeah, there are lots of different courses and system
design is also very different for back end and front end
engineers and data scientists. I think I have made the exposure
to back end part of that. I have no idea how do people do
system design on the front end. I can guess, but it's going to
be rather generic. Guess I'd rather not share it,
but I think it would even. What makes people senile
together is being able to navigate ambiguity and be able
to solve for business problems. And it's also like how people
are going to most oftenly evaluate your performance.
Like if you are trying to build the best architecture for every
problem you're trying to solve, it's not going to be very useful
because it's going to be at times or architected.
Maybe it will going to look nice, but the level complexity
at which you will be operating will not justify the level
complexity of architecture. Maybe it's going to be very bad
the book and look like you want from the like they want in clean
code, but it's not going to yield business outcomes.
So you ideally want to holistically, forgive me for
this word, it's like been overused a lot.
But you want to holistically understand the business problem
and the way you can outsize your impact.
Like if you talk with the business people or people on the
front lines of product, people like, hey, what are we actually
trying to solve for our customer, You'll be like, oh,
maybe you don't even need to write anything.
You can just like do it like this and it's going to work and
then we'll get some learnings. And if you want to double down
on that, then we'll have to scale it and spend two months or
4 sprints to implement it. But otherwise we can acquire
this early learnings in some other way.
So almost like if you can hack your way towards the learnings
early, like that's the best. And then you continuously like
have to play both heads. You're trying to hack things
where it matters or where it doesn't matter that you hack
them, but you want to get the learnings.
But you want to do things in a more sustainable way where you
think it matters. And there seems to be a business
buy in and there's going to be your road map for the next
three, 4-5 years and potentially you want to be able to build up
on that later. So like there's no like 1 clear
outcome. It's definitely not just coding
or like not being like just like your podcast beyond coding.
Like I do think that people become senior when they will go
beyond coding. OK, like, yeah, because it's
gonna. Be my new It's gonna be my new
tagline. I think it's really good.
I yeah, I can absolutely, absolutely subscribe to that.
That's good. I very interesting because
something you mentioned with regards to navigating ambiguity.
I had a personal product manager, very senior from
Google, has done engineering management also came from an
engineering background and I asked him now that I've done
this product management like that was very early on in my
switch, let's say what makes for really good product management,
product manager. And he said navigating ambiguity
as one of the first things and that translates there because if
you're really good at that from the engineering side, I think
you need it also on the product side.
And maybe just in general being more comfortable in the
ambiguous and being able to solve anything whether that's on
the technical side or more so from the stakeholder side with
regards to domains or even the political landscape of a
company. I think that makes for a really
good contributor, doesn't matter if it's on the product side or
more so as an IC rule. That's a very interesting
insight. I feel like you just broaden the
amount of people you're able to talk to in the company.
Like if you're just not getting coding, well, you can talk to
the people that define the particular problem that they
wanted to be solved and the code.
But if you're able to go well beyond that, outside of that,
you're able to talk together with your product manager to
help him to navigate the ambiguity that he's facing from
his customers. And you can just like see, OK,
how to like hustled together with him or her to have, yeah,
product outcomes. If you're going go even further
beyond that and go to sales people or somebody who's around
the company, it's also great. And that only makes it more and
more important and impactful in that particular company.
Yeah. And I feel like that is a skill
you can develop and it's very, let's say, isolated and more so
scoped. I think from the engineering
side, because you know where something is unknown, let's say
because you're like, OK, we don't know that.
We have to explore that. And you dive into something new,
specifically scoped to something technical pretty often based on
a domain or based on a new organization or based on a
challenge at hand, whether that's scale or just ramping up
as fast as possible different challenges.
And then if you were to, if I were to start on the product
side, I would not have any experience dealing with
ambiguity. I'd be like, OK, this person
says XY and ZI don't really have any history.
Yes, no, maybe. So I have no clue and I feel
like I have a better, let's say gut feeling or at least history
or perspective to fall back on to be like, OK, no, I actually
think this, or I can actually confidently say no to some
things implementation wise or even a requirement wise.
That's very interesting. I'm happy it does translate
though, because it means that I can have a lot of fun in
different roles with kind of a life skill in dealing with
ambiguity. Do you deal with ambiguity like
also beyond the check or where have you found that as well?
Well, yeah, fortunately. So I decided it's a good idea to
well, by a pardon, it was a good idea.
But we also decided to, together with my girlfriend, that it's a
good idea to renovate it ourselves.
That's a good idea and renovating things.
But I still, yeah, slephil, it's a good idea.
And I also found this journey to be rather pleasant.
Painful because some of it's just like very exhausting, but
also pleasant. But you constantly trying to fit
solutions to problems that you have in front of you and then
like it's up to you and your ethics.
Are you gonna go for a better solution?
Are you gonna cut corners? But also like if you're doing
this for yourself. It's gonna impact.
Your your own place like you are the end customer, so you're like
you feel the full cycle 'cause when you do it for something
else, but else probably you would have slightly different
guiding principles like I should make this economically viable
and when you did it for yourself, like no, I should make
it nice. You want the full blown suite.
Yeah, it also exposes you yourself to your own character
and your character flows. Do you?
Because this is what I see from the product side with
stakeholders. People love coming up with ideas
and solutions and I'm trying to make sure that we start simple,
we expand and we we basically build what we know now and are
flexible for the future. But the house you can't do that
as much. So you have to you have to
decide how iterative you want to be.
Yeah, I don't fully agree with that idea that you want to be
flexible for the future, to be honest.
Like, I mean there's like another softly contrarian point.
You don't know that future's going to come, like how far in
future they want to look like, should be, should survive one to
three years. I feel like everything above a
year, a year and a half for an early company, which doesn't
make sense, like the world's going to look very different in
that time. The people you're going to be
working with also going to be very different.
If a company is itself one or two or three years old,
everything you create right now will be torn to pieces a year
later or maybe two years later. Then I think we're saying the
same thing, but maybe I phrased it differently because I want to
be flexible enough to not lock myself in, let's say based on
decisions for the future. What I've seen is that people
love future proofing things and I can't future proof anything
because I don't know the future. Oh yeah, yeah, yeah.
So and then we are saying the same things, but what about the
house situation then? Because that's different.
Oh, the house? Well, I do.
We do it like slightly more modular approaches to
constructing the house. Like, unlike the relic
construction, we built almost everything in a way that you can
maintain it. I don't know.
How to come up with the simplest example is like you're building
a bathroom and you wanna have a bathtub.
Like, how do people normally place a bathtub like this
bathroom? Like this.
How call them like black walls, like not finished walls without
tiles, just like raw blocks of no concrete and bricks and
whatnot. People put the bathtub and then
they build the bathroom around it.
Well, this one went to do it, but then if for whatever reason
you want to change the bathroom, you want to get under it, you
want to remove it, put the shower there instead of what
else. You kind of have to fully
deconstruct that corner and you are with this like big open
space where things don't look very nice and it's not very
usable. The way we decided to put this
bathroom is so it feels like build the whole space and tiled
it and then install the bathroom and then we build the thing
around it which covers it. So if whatever the reason, we
want to either change the bathroom or they remove it and
put the showers in the shower there instead, you can do that
without much of A further investment or crazy mode of
efforts. And that's the modular.
Part and the same like with all the piping or the electricity
where you can access it, almost everything is built in a way
that you can maintain it. You can get to the things
nothing is like built in and then they conclude this port on
top and then you can never touch it.
It does require more effort and more time, but at the same time,
somehow it made me feel much more comfortable this house in
the future and how I'll be living there, yeah.
It's gonna be very fulfilling when you get to a point where.
Not to brag, it took us almost two years now and I think we are
about the finish line. That's chunky, but like 2 years.
Oh yeah. But it's like classical software
development project, Like in the beginning we thought like, yeah,
probably like 6 months to nine months we'll be done.
Optimistic. And then it's like, yeah, OK,
OK. And then at some point you like
to throw out the process field with us like.
So when do you think you're gonna move in?
And like you're like, yeah, maybe then I think about half
year later to seven months we stopped answering that question.
So like you're just enjoying the process.
We won't take our time. And basically we also
restructured our process that we didn't push for any deadline
anymore. But try to restructure this
process as just something part of our life and we will learn to
enjoy it rather than to be very thorough about it and like be
whiny about it or be annoyed about it and that was not very
economically viable, but make the journey much more pleasant
and. Sounds like a lot of learnings
in there. Managing your own expectations
also exactly and not setting deadlines.
That's really funny because there's a lot of similarities
for product development. Very much is also like selling
to your customer. Like to my girlfriend.
Yeah, we also have different opinions about how to do things.
Oh yeah, quite some politics in there.
As a as a final question and I I was getting to this but it might
be when you've finished the house you mentioned you have
this kind of entrepreneurial drive or at least also kind of
aim for the future to build something from zero to 1, be
there more hands on and then make it scale as well.
Why? Why hasn't started yet?
And I love this question because people usually ask me and I hate
the question. Well, I don't hate it.
I did and just like all the previous that it takes failed
like I this sound like a tensor, which were I guess not as
serious enough from rather early age.
We built this recommendation engine in 2010.
It would recommend movies from a big graph which will then allow
you to do horizontal recommendations like from the
Taste in movies. We'll be able to recommend you
the type of music you would love to listen or the type of cafe
you'd want to go because you would try to like break down the
movies into like this cloud of tags, make a graph out of that,
and then break out a cafe also in a cloud of tags like I don't
know. How was we?
You mentioned we. It's so me and my friend back
then, two of us sort of almost fresh out of university.
We were building that and we built for quite some time.
Go to some prototype, applied to Y Combinator.
They didn't take us in, but I guess we didn't look serious
enough but didn't push. Had enough, I don't know.
And yeah, and then somehow then we got into fight and the thing
kind of fell up, fell apart all the time.
I then joined a few years later after working at some other
companies, I joined that at tech startup, the one I talked about
where we profiled the Internet traffic.
I was basically the 2nd engineer and the 4th personal together.
So there was like CTOCEO another engineer and I was the 4th
engineer and we're building that product and it was getting some
traction, but like wasn't full of product market fit and after
two years we didn't get enough. We didn't have enough funds to
continue like that and didn't have money to pay me.
I didn't didn't money to leave and stuff like that And then I
joined eBay because I was like I had to do something stability
but I was like hoping to like because my in my ideal world
back then I would just double down on building that and this
early ventures. I then joined this another
venture backed thing with luxury watches where we built vertical
marketplace and my general desire was also to try to
continue building that as an independent venture going
forward. And even while doing that we
built this iOS and Android app which is a marketplace for
fitness trainers. You could like create your own
program submitted to this app and then people will be able to
sign up to use a personal trainer and yeah follow your
access routine. But since I was doing this with
my friend who's also an engineer like he back then I think still
worked with Google. Now he works on another startup.
We were two engineers and we built very good solution.
We published through the App Store to the Android store.
But like we had like 0 hassle, like we understood earth and we
didn't do it to do, but like we just didn't do it.
Because like for me it's like it's hard to explain the level
of how good I am. Am I at sabotaging myself at not
doing that? OK.
And I found myself continuously with, I guess it's kind of
something I learned about myself that I do need like a hustler in
the venture I. What do you mean with Hustler
then? Like actually because it sounds
like you you had the product and I'm not sure where it fell, fell
flat. Hustler is like continuously
talking to your product manager, like somebody will continue to
talk to the end customers will be very patient and understand
them, translating them their requires and asks to well the
building team. And like, yeah, that part
because I don't find it somehow for myself as engaging and I
don't do it very well. But once with presenter, with
the challenge, I can hack the solution which will work going
from like 0 to one and have the business outcome.
But like that continuous like business drive, I don't have
that part and I was thinking about myself maybe I have it and
all the years I think like I probably don't.
And by this time I'm absolutely ready to like fully have my end
be like, yeah, I don't and it's fine.
I'm going to do other things. I just need to partner up with
part of that will cover that part.
And like even right now at Miro I find myself quite often
partner up with people that's well they are doing this
ventures inside of the company but like they they do like takes
at new complicated developments in the products either focus on
customers or for the internal customers being engineers.
And I really like to support the thrive and be like with an
execution and the product or something that will do that, but
I'm not as good at like a front line of that.
So that's also why I altogether think that probably over the
period of time one way or another I will find myself in a
similar position where I will be taking another go at more
independent venture building maybe within mural maybe outside
I don't know, but probably doing the same function of like
building things. That's why I feel very
comfortable staying in the IC position because yeah, I just
find whatever the challenge I see like when it's people
struggle to make things happen, they know what they want, they
head by end, they do the other part of the equation on the
product business side and they need to make this, this happen
and they struggle with that because that's where I think I
get lots of joy in. I say this like lead code, hard
problem you know. The hardest there?
Is and I and it's fun and I really enjoy it.
I I thrive in that. That's cool man.
Coming back to the idea of like whether you want to make catch
up on the skills you don't have and make them be stronger or
like double down on the skills you are a bit better at.
I feel by this time a couple of doubling down skills I do have
and like be at peace with the things that I am just bad at and
I'm not able to execute well. Yeah, that's really cool, man.
I love that perspective. And even when you say you're
you're bad at it, I do think they're to a point adequate
because I don't think you can go completely without.
Otherwise you wouldn't be able to recognize the really good
skill on the other side of the people that you admire and want
to support in that way or that you need kind of as a Co
venture. It's still open to question if I
can do that right? Yeah, yeah.
That's fair. That's fair.
Time will tell, but even if all getting failed, I find myself by
this time I'm likely enough to in a place where I find
interesting challenges and I can solve them.
I'm ready for also other challenges, but I do enjoy what
I do continuously. I don't have to like, Oh no,
another day it worked so horrible.
Like, I love going to the office and working on things.
That's the best. And doesn't mean I wouldn't
maybe mind doing something. I love complexity, but also I
don't mind just working like I'm not like oh, I want to like make
1,000,000 bucks or 10 million there like there a few money.
Unicorns. And then be like do nothing and
just like chill and like, no, I probably between I'll be
building something one way or another, so it's fine.
Cool man. I I really enjoyed this
conversation. Kind of an insight in your mind
discussing what it means to be senior engineer as well as this
little topic of lead code which I always think is interesting.
Is there anything you still want to share before we round off?
No. I always throw this.
Don't worry, that's. Like this question?
It's not like what do you want to share?
I think I'm a good ticket, but I really enjoyed our chat as well.
It was very nice and thank you for inviting me on.
Cool. Thank you as well.
Then I'm going to round it off. Check out Area Socials in the
description below. Reach out to them.
Let them know you came from our show.
And with that being said, thanks again for listening.
We'll see you on the next one.