Senior Software Engineers and LeetCode With Ilya Pimenov

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.