Hi everyone, my name is Patrick Akio, and if you're interested in the skills that transfer as software engineer throughout your career, this episode is for you. We touch on the skills that pay dividends, the interviewing process and how you can see those, as well as what hard skills to focus on learning new languages and personal growth. Joining me today, friend of the show, Carlos Calthbaum. Our second conversation and honestly, first one was my favorite. This one might be better, so
enjoy. I've heard people play around with F# in like Advent of Code and stuff like that, which is like the perfect perfect opportunity to try out a new language and solve problems. Yes, and I have heard people be quite fond of it. Yeah, yeah, yeah. It's beautiful. I'm not sure if it has found its footing, like I don't see F# developers being hired. No, I think it's the functional thing. It is so far away from what people expect with curly brace languages or or C like languages.
It is not easy to make that that step into the functional programming. While F# of course you can do most of the things that you can do in C# a little bit differently. So the step is not that big with F#, but it's still quite a fundamental change in the way you think. And I don't think that a lot of people are either willing or I don't want to say able every. I think everybody's able to do it.
But it is such a different way of thinking that it's going to be hard to make that switch if you're not forced to make that switch. Yeah. So there's a big ramp up. Yes. Interesting. How do you go about picking up a new language in any case? Because I it's not something I do often or look forward to. Because I I like being effective with what I do and starting from scratch. It's not something I like. So I think there are a couple of skills when we work in software that are transferable.
I always try to split that into transferable things. When when you switch complete career or or when you switch a job with a different language and learning a new language is mostly about hubris. Just at least that's the way I do it. I just assume that I know what I'm doing. Oh, OK. And every time something doesn't work out or I make a mistake, it
is not my fault. And just having that mindset of just doing it and not even giving yourself the chance to say, OK, this is going to fail or I can go back. It's it's like that, that famous expression that you, you burn your boats if you burn the boat. So if you cannot go back, then the only way is forward, and I think that's the way to learn a new language. Interesting with when you have to execute them within this new language. Do you relate to a specific other language?
Like is it one or is it many for you? For me, it's many, many. Yes. OK, so the first language I learned was Pascal and then some Basic and then some Visual Basic. Then I went to C#, Java, JavaScript, Haskell, F#, and as soon as you hit those those languages, then it really doesn't matter anymore. Makes sense. So, oh, I forgot to see. So that's one of the most fundamental things I've learned and that I've carried throughout all of the other languages. In C, you actually think about
how you lay out your memory. And even if you're working in Java or in C#, just having that that state of mind where you think about how your data is structured in memory and just trying to optimize that a little bit. So don't go full optimization because that will. It's not worth it. It's not worth it, or at least not not often, but just knowing how the data is laid out in memory changes the way you program.
Interesting. See this is very inspiring for me and it's especially a thought process because I I haven't done that. Like I've never programmed in C, I looked at it, I was like Nah, probably not. For me it's because I grew up with Go, specifically Python And university. Things that are simple.
I think at least that's just my perspective and I don't know the benefits and I won't try it out, I think until I realize what the benefits will be. And as long as I am effective and still have a good fundamental understanding, then I can continue to be effective. So I don't actually go back and try up, pick up a new language or shift perspectives. Yeah, it's kind of weird because I feel like I'm anchored, but I don't want to get out of this. Yeah, yeah.
I equated a little bit with being like a Carpenter. You can make beautiful chairs, but you also have some carpenters who actually know how a hammer is built. Yeah. And how those tools function and, and why they function that way. So I learned that by building compilers. And as soon as you build a compiler, you start thinking, OK, if I have a little bit of data that I want to pass into a function, how am I going to represent that?
Yeah. And so you, you, you get into the situation where you try just storing it into a standard dictionary like key values. And then the key is like your variable name and it, but what happens if you have multiple variables? So then you put dictionaries as a value in your dictionary. And now you're just creating a stack, right? A very, very inefficient stack, but you're just creating a stack.
And by doing that, I learned a lot more about how these programming languages or especially these frameworks that the programming language is basically compiled to why certain choices were made. So reference counting, for example, I don't know if you know the term. If you have if you're doing C# for example, and you have an object on your heap, there is some sort of reference counting happening to that object in the heap.
And when there are no more references to that object, the garbage collection collector cleans it up. Yeah. So it first it tries to clean it up, then it goes to different generation and then tries again and tries again. And then at a certain point even your garbage collector goes, OK, I can't help you here, but those are those phases of garbage collection with pointers to certain. I don't know if we're going to ET technical, but these are these are things that are really
fundamental. And if you don't know how it works, you're just using it. And then at a certain point in your career, you need to open a profiler and you go, what is this unmanaged data in my application and how can I reduce it? And that fundamentally changes or has changed the way I write code. And I've noticed that that is transferable to every language I
use. Interesting when you, when you and I had the conversation, I think it must have been at least a year, maybe a year and a half ago. I know you made a pivot in career with regards to a domain, started out in the gaming industry. I I love the gaming industry from a surface, from a user perspective, but I know there's a lot of nitty gritty that goes behind the scenes. Basically, how was that
transition for you? Because you shifted into a new industry, probably new way of working, I'm not sure new technology or new learning, but the product was definitely different. You've never built a game before. Yeah, that's true. It is exciting. It is really weird. It's like a year ago I described it as seeing the world in colour for the first time. Oh. Really. Yeah, that's good.
Yeah. So what the one of the problems I've always had with with enterprise software is the inability to fundamentally do something. So you you get into a company, they assume that you're using some kind of cloud and then they talk about micro services, which means, I don't know, Lambdas or Azure Functions or something like that. And then they talk about databases which are hosted in the cloud, which scale automatically so you don't have to worry about anything.
And it, and then you get into these these patterns that might work for an enterprise, but you don't go back to first principles. And with, with a game studio, especially the MMO that we're building, you want to have as many people on the same server because you can imagine that if you pay €20 for a game and you have a game server that can host 1000 players, you'll have like 20,000. And how long can you keep that server in the air for that
money? Yeah. So having more players on a server, having your server be more efficient, those things actually are extremely important again. And then you, if you combine that with things like latency and I need to be very careful because latency experts are extremely, how do you call that? Like Adamant. Yeah, on, on, on what? So with latency, I mean the round trip, so getting data in your server and getting it back, you're, you're talking about 30
milliseconds, 20 milliseconds. And that world needs to update in 20 or 30 maximum of 50 milliseconds in order to have a smooth experience. So you're in this situation where you have high concurrency, high performance. Yeah, which is amazing to be working in, but it it it does, it does require you to think about building software from first principles instead of just grabbing tools off the shelf and then shoving it together into a product.
I I really wonder if I would like that because sometimes in I work in enterprise software, I'm not a bank, not doing software engineering, but product management, which is a whole different ball game. But in any case, when I look at my past experience, we would talk about performance latency and in the end it wouldn't really matter, right?
We were either building an internal piece of software or we would build it for small subset of users and we could test what the impact was or we could AB test different solutions. In the end, it didn't need to be that high performance, right? I don't think a lot of software actually the majority of software needs to be that high performing only when we're talking about very nice specific parts of software or industries
in that case. So then having that shift in mindset is a completely different way of working how I'm imagining it. Yeah. How was that for you? Because did you have experience with that high performance mindset with regards to software before or was this the first stab at it? Had a little bit of experience. One of my hobbies is building compilers and you want a compiler to run extremely fast.
So I had some experience with that, but not on the scale of building an MMORPG, but that there was one interesting thing that you said with enterprise software doesn't need that type of performance. One of the things I've been thinking about for a very, very long time now, I think it's 2345 years, is if you look back at around 2000, 2002, 2003, four, when all of those big MMORP GS were coming out.
So for example, World of Warcraft, that was an insanely large world running on 2 gigabytes of memory on your PC, with servers that can serve literally hundreds of thousands of players. And if you look at the products that are being built right now, I have the feeling that they are not as performant or as great as they were. So I think we are losing a lot of knowledge.
I think that the tools that we have, maybe even the power of the PCs that we're using, are forcing us to write software in a different way, which is inherently less performant. And I am I, so I don't know how to formulate this problem yet, but I think there are some skills that people had back in the day that they don't have now. And I think there are a lot of assumptions that we have right now that we didn't have back in the day, which result in
different software. I I I think I agree but I can also think of a different angle because speed is way different than it used to be and it matters more especially in the game industry. You can have a one day one release if it's a virtual thing that you download software related on your PS5 or whatever, or you actually buy the chip or the disc and you put it in. You will have a patch, probably day one because stuff will not be finished.
And you'll have a patch the first week and probably the second week. And then from there on monthly updates, fixing different glitches or out of bound clips or whatever because things are not finished, finished. We can do that. So we do and we don't have to optimise for performance. We optimise for speed because we want to outpace our competitors. I feel like that's the mindset.
I'm not sure if people are unable, maybe because it's grown we become unable to make really performance software in that way. But I feel like speed is the most crucial differentiating factor and I'm not sure if it's helping us or hurting us. And also not sure if we're achieving the speed that we want to achieve if I switch back to enterprise software, for example, just building a simple customer portal takes too long now I think it has too many.
I don't know. I don't want to over generalize because normally when you say something can be built by one person or by, by team of five, then there's always this counter example. So I don't want to over generalize, but I do think that we have too many developers at companies and we don't let those developers do a lot of different things. So I, I think specializations that we're having might be hurting us a little bit more than necessary. So when I started about 21 years
ago, we did everything. We built the front end, we built the back end, we build everything and we were building ERP systems. So we build an actual ERP system including invoicing, billing, stock, warehouse management, all of those components in the ERP system. We built that in 1 1/2 years with two, two people and the software was in production, used by the customer.
Customer was happy and I'm not saying that we were good because none of us had the experience of building a system, but we had management which really understood the process of how to build software and could help us with every step to build the best software that we could. And, and now 20 years later, when I walking in a company or, or maybe consulting or maybe helping or just having some observations about the company, I usually see multiple teams working on a very small piece of
the software. And maybe it's because they only focus on that little part, but the little part never gets finished. And so I think there is some wisdom in knowing when to put your pen down and when to stop adding scope to the problem that you're working on. So a little bit of discipline in how you get the job done. Yeah, I wonder if it because I'd never worked at a bank before, but now I realise that a lot of the processes that bigger organisations have is all risk management.
Basically, there's a process in place for you to bring something crucial to production, which makes the release process slower. But in the end, they're making sure that whatever impact that has on production, it's not going to hurt anyone's image, it's not going to hurt the business. There's no leak of information or data breach. Security is all there, all with regards to risk management. Those processes are there.
And for me it makes sense when I thought about it because in a start up you don't usually have many processes, right? Processes have to form. You can go really fast because indeed you'll probably be there, one of the few people doing a lot of things basically. Then the generalist skill and getting stuff out to production fast really matters. And then when you go more enterprise, more numerous amounts of people, more teams, that's where risk really becomes
a factor. And that's where processes kind of accommodate for that risk. Teams become part of this huge Organism and they only work and tweak a small part of it, and when they don't actually finish, it's not that big of a risk. So that's not that big of an impact and it's a sad reality. Yeah, Yeah, it's, it's a sad reality.
It is also, I think, unavoidable as software becomes more and more important in our daily lives and more and more companies are fully dependent on the software they're both using and creating. I think that risk management has changed the way we organise our companies, how we look at engineering efforts, how we structure everything. So one of the one example that I always bring up is open office spaces. I don't know a single engineer who enjoys Openoffice spaces. Still we have them.
So why is that? Are we, is it, is it more important to force a sort of a style on the organization then empowering engineers? Where is that balance? And I see that balance going different directions. And it used to be very specific, right? You had a few engineers, they had a small office. They either by themselves or 2-3, maybe four people, a bit like like academia right now. And they just sit there.
They built their stuff. And in a week they go out and they say, hey, can somebody look at my stuff? Yeah, I built something. Exactly. And now we have all of these processes in place and we try to force ways of working like at our company we have three-week
sprints. I don't care if your team doesn't isn't as performant in three-week sprints because we as a company have it. And so there are, there are so many, sorry, there are so many different forces working on the engineers right now through these companies that I think we need to empower engineers more. I think so too, actually.
I don't know what triggered this, but I was thinking lately more and more with regards to my own career, my own personal development, and for me, I see a few avenues. I already switched, switched on paper to product management at the beginning of this year. It's something I always wanted to try out, see if I can be effective in that role, if it's going to be fun, what I miss from software engineering in the first place. So that was always 1 angle and
I'm trying that out. I'm really enjoying it, but I missed the software part of it. Then the second two would be one engineering manager and two developer advocacy engineering manager. Partially, I have some of the responsibilities here at Sebia. Being responsible for a group of people with regards to personal growth, development, happiness, and that role might be growing in responsibilities.
And then developer advocacy, being close to users, understanding customer needs, relaying that and collaborating with development teams and educating most likely an audience that is developers on how to use whatever product we have seems very interesting and I think I could leverage the skills that I've gained on this podcast.
For me, transitioning to a different role is always going to be scary, and I'm wondering based on the skills that I've gained on this podcast, I now have new doors that open for me. But especially with your technical depth in, you just explained the numerous amounts of languages that you've owned or at least dabbled with. What skills would be transferable for software engineers in the first place? That's a great question, but let me ask a a, a, a follow up
question first. Yeah. So when you talk about engineering managers or wanting to become an engineering manager, what is the part of that role that really entices you? That's a great question. I think I love working with people and I am probably this is a part of an impossible syndrome, but I don't see myself becoming a person that has a really great technical depth to a level where they are comfortable leading projects and making those decisions on the
more technical people. I usually rely on people around me to help form those decisions. So then the part of the engineering manager, I do see that with bigger organizations, your engineering capacity is more crucial. So if you can make happier engineers or more productive engineers, start thinking of measuring and making more effective, not from a cost cutting perspective or from an end of year performance standpoint, but genuinely making sure people are actually happy, right?
Removing some of those processes or boundaries, being responsible for that, I think I could do that. I think I would like that. Would I like that full time? I'm not sure. So that's kind of where I see engineering management in helping people kind of get the most out of themselves and then also getting the most out of
teams in the organization. Yeah, I think that's that's that's, that's beautiful because there you already hook into those skills that you need to develop and that you can that you can carry over these multiple roles. For example, I think empathy is one of the biggest things that I heard in that answer. Make engineers happy and not in an end of year type of way, but just build an environment where people are happy and through that happiness are productive.
A lot of the research points that way as well. So happy people collaborate better and when they collaborate better, they perform better. Everybody has this, this memory of a team they were in that just worked. Maybe different people, but it just worked clicked. That's I think that's basically where empathy comes in.
And I'm not talking about empathy as the moral philosophy type of thing, but really the practice of empathy, trying to get into the headspace of somebody else, like you're doing in a podcast, asking the correct questions. If you are missing something either in the conversation or in in how somebody approaches their work. How can you get to an, to A, to an understanding together while keeping somebody? Yeah, while, while, while.
It's like not losing them, basically having them still on board and be happy with the outcome. Yeah, and sometimes that's not possible. So you need to have some form of boundaries that you do not want to cross. But it's mostly about how do you collaborate with people while keeping them in their worth. And I think those are skills that this podcast especially teaches you and that you can transfer immediately to
management positions. That's what I've seen in kind of the product management role because there I have multiple stakeholders, multiple needs and in the end decisions have to be made. We can't please everyone and that's what I'm trying to figure out how to do now. And it it's more of a gut feeling like if I were to explain my thought process or how I do it, it's really hard to do that. But then in the end, I just act based on what I think is right and hopefully people are happy.
I don't know to be sure 100% it looks to be the case. And I think that has a lot to do with providing clarity as part of that role. I think in any more type of leadership role, even if you're not a leadership on, on paper, if you don't have any of those responsibilities, someone that communicates clearly, provides clarity, removes ambiguity and
make sure we can move forward. I think that's always something I've appreciated in others and something people have said they appreciate in me. Yeah. I think that also comes from if you're building software from a, from a technical foundation, you don't have to be an expert in everything. So I am not an expert in building games. I have some expertise in building high performance software. I have some expertise in building AP is and interfaces.
And I, I have, I have some expertise on a lot of different areas which I can use to have a conversation with people who are actual experts. And I think that's the most important part of being in a leadership position, because you can understand somebody better if you have at least some fundamental knowledge about what they're doing. Also be able to, to challenge decisions. It's also important why are you doing something? You don't have to say it's bad or it's wrong, but can you
defend? Do you, have you looked at different things that you can also try? Or is this the first thing that came to mind? Have you, do you doubt some of your decisions? And all of that comes down to slowing down the process and slowing down the process and maybe sometimes removing a lot of parts of that process, I think is critical in building good software. That's interesting.
I usually ask those questions and it's from genuine curiosity because I want to understand and then when I see people that don't want to understand, they don't ask usually the same questions. And then if I don't or I have the feeling that I should not, and things turn out different because we have that unclarity because we didn't ask those questions, then usually it comes to bite us in the ass. I don't know if people do it consciously. I always thought it was from a point of curiosity.
But you can use it as an effective tool, I'm realizing. It is, it is. It is a form of discipline. So every role, I think, has its own set of disciplines to make you effective in that role. So as a programmer, you might do TDD, or you might refactor your code, or you might do some things in order to make everything better. It takes time. Sometimes you don't want to do it, but you know that if you don't do it, the results are going to be less. The same goes for management.
So maybe you wake up and you don't want to go into that meeting room with that person and you don't want to spend time or you don't want to try and, and, and get into their headspace and, and be empathetic. But that's where the discipline comes in, asking those questions. That's where your discipline comes in. And that's also a very good transferable skill. You have to be, you have to be able to reflect on choices you've made.
So that means your choices need to be conscious because if they're not conscious, you cannot reflect. And you need to be willing to say to yourself, hey, that was the wrong choice. Let me try something else. And by continuously self assessing, listening to people, being empathetic, being open to change and open for different ideas, I think you can exceed in almost every role. Interesting when you said be conscious about your decisions,
otherwise it's hard to reflect. I'm not sure what the specifics were, but I was thinking I I usually choose based on this gut feeling that I have, right. I have theoretical background. It's not perfect. I think it's always something to improve. Sometimes I think it's lacking in certain areas, I mean, especially now in this new product role. So I I rely a lot on the experience I've built up through engineering. That's where a lot of the decision making comes out.
But I don't weigh out the options. I usually go with my gut and it's very much based on that gut, how decisions get made. In the end, I can reflect and I can't think of other options that we could have taken, the pros and cons that. But I do that. I don't do that proactively. I do that reflectively, yeah. That's for me, that's where journaling comes in.
So if you start journaling, if you start writing down at the end of the day, what happened that day, what decisions you made, why you made them, you can always reflect by reading it back. So I think journaling is one of those skills that almost everybody should at least try. Interesting. If you don't like it, you don't like it. If it's not for you, it's not for you. But it is something that can
potentially help you a lot. Do you do that pen and paper like old school style or do you type away? I do pen and paper. Yeah, I have everything, pen and paper. I try to do as much as I can on pen and paper. I This might sound silly, but I lose things when I do it digitally. Oh, OK. So I lose documents when I switch P CS, I lose stuff. I don't have everything in a git repository, right? And when I do in pen and paper, I just have a shelf with all kinds of books.
You know where it is. I know where it is, or at least I can find it. The the same goes for for password managers. I don't use a digital password manager, I use a book. Oh OK, I write everything down. Yeah, nice. That's very interesting. I was thinking when we were discussing these transferable skills, empathy was the first one you mentioned being or actually challenging decisions and understanding why clearly and providing that clarity was the second one.
And the third one, I actually forgot. What was the third one you mentioned? Just hard skills. Just hard skills. Yeah. Indeed. When we're talking about transferable skills as well as then how to assess people that are new either within your team or within your company, how do you make sure that those skills are there? Because I can understand from a personal development standpoint, I would focus on these skills because those, I'm assuming, would pay dividends.
But then you would also need to assess what those skills are, and they are different from actual concrete hard skills, what we usually assess. Yeah. I do that a lot in interviews. So in an interview I look for self reflection and I look for empathy. And those are two very critical things. I can't if, if, if there's, if people are smart enough, you can teach them anything. So I, I, I look for fundamental knowledge, I look for empathy and I look for self reflection.
So in an interview, if somebody tells me a little bit about things that didn't go well, that's like, aha, that's cool. If they reply on A to me on something I said during the interview, aha, people are listening. And if you have those two skills, I can teach you how to write code. That's not a problem. That's just takes time. But it's about those, those other fundamental things are things that you cannot you. You can train them, but if you don't have them, it's very hard
to learn them. That's what I was thinking, yeah. Yeah, the training part, I mean, it's, it's a hard path, right? Because I, I would assume, and this is also what I assumed early on, that hard skills are going to make the biggest difference. I have seen engineers very good at hard skills consciously neglect things like empathy and say it doesn't matter at the end of the day, because if we can't execute, if we're not fast enough, it's going to die anyway.
The software that we're building or we're going to get outpaced. And I feel like a balance is needed, but then I this black and white, you have it, you don't have it, or you choose actually not to care about it at all. It never suited well with me. I always thought that was a bit odd. But then those people, or at least that one person that I have in the back of my head was incredibly effective. And I really looked up to that person with regards to their technical excellence.
So then to argue that no, you also need to do this while I was really admiring what they were executing on is like a hard path. Yeah. And that is that is also that's one of the toughest decisions you'll have to make if you ever go into that management or leadership role is sometimes you have somebody who is really good at the hard skills, but is completely wrong for the company. And just letting somebody go like that is a very difficult thing to do.
It is nerve racking. It is very difficult to explain to stakeholders and other other leadership. It'll be frowned upon for sure. Yes, but it is sometimes extremely necessary to do. And I think that if you think about the end goal of what you're trying to achieve with everybody, then it is no longer about a single individual.
And as soon as you get into a situation where it's no longer about a single individual, then you will get things like reflection and empathy because you're trying to work together. You know, another great signal is if somebody is tired, does the rest of the team stand up for that person? Do they help them with a job or do they stay, Hey, go home, go sleep, do whatever you need, right?
Are you working together and spotting that from a leadership perspective and then stimulating it and making people conscious that those decisions are the right decisions to take even in crunch time? Yeah, That's, that's the, that's the fun. That's the. Magic. Yeah, yeah, yeah. I do think that when things are easy, things are smooth sailing. Probably a lot of people are happy because you don't have to
disappoint a lot of people. There's more resources, sometimes more time, even when things get hard and tough for me, then the leadership positions are interesting because then you have to make some tough choices and also be responsible. It's definitely going to be stressful, but from a learning perspective, I feel like that's where you'll learn the most. Yeah, yeah. It's like it is with everything, right?
If you the the learning is in the failure, the learning is not in when things go well you or that's not 100% true, but it's it's kind of close. It's one of those problems I have with a lot of tutorials on YouTube. So if you see the end result, you might see an 8 minute video on how to do something. What you don't see is the the three or four days of preparation and failure before they get to a clip of eight minutes where they show you how to do something. And I think the learning is in
that that previous part. It's also why I like things like podcasts, especially long form podcasts. They give you a chance to express things that might not be popular or contrarian or and then have a conversation about it instead of being a, a clip where you only see a response or
only see the conclusion. And I think with programming and with coding and with engineering in general, and with building a a company and building an organization, those moments when you fail and how you recover from that failure, that is where the learning is in. Sometimes you see people who've been in the company for 20 or 30 years say, Oh yeah, we've
already tried that. And that's the flip side of going through that process and learning is you can become jaded or not want to try something again. But as soon as a management team you can, you can try and mitigate that. You can mitigate the fact that somebody who's been at the company for 30 years goes, oh, we've tried that. That's not going to work. And you combine that with the with the just the discipline of trying and trying new things and reflecting whether or not
they're working correctly. That's where you build a very tight knit group. You build a group of people who will work hard, who will enjoy working, who will enjoy each other's company. And I think that's the road forward. Yeah, I, I love listening and learning from people's failures. I I'm not doing it to prevent my own, but just to build perspective. Then on the flip side, these 8 minute videos where it's like digestible content on how to do the thing and do it right in the
right way. That is also sometimes what I'm looking for because if I'm going on YouTube, I'm looking for solutions or looking for execution there. I'm less interested in the failure part of things, and that's where it becomes very personal those days leading up to that video in preparing and making sure that the flow of information is digestible. The actually what I'm typing is perfect because I want it to be perfect because that's the type
of videos I want to create. That's really different. That's also from an audience perspective where I'm less interested in the failures. That's where they become more
personal. But that doesn't help with regards to this feeling of imposter syndrome where then the content that you see looks excellent, looks fluent, and then you do it yourself and you make mistakes or you have to remember, you have to Google. And I feel like that bleeds into interview processes as well because that's what you then are sometimes even expected to do so before you even talk to a human.
You mentioned how I measure those more transferable skills are in an interview, but most of the interview processes that I've seen don't even allow for that unless you pass the very minimal hard part that they have and just either do a data case or do a lead code exercise. And it really cuts out a lot of the people immediately. I'm not a fan of lead code. I am a fan of showing me a hobby project you've made. I think lead code is way too trainable and hobby projects are
not hobby projects. Show passion and in a hobby project, I can actually ask, OK, you've, I see you've solved it this way. I know that you're not happy with it. Can you explain why? So there you have this, this, this back and forth and this you can, you can question the learning process that somebody took while building a, a hobby project. So for example, I, I like compilers. I build a architecture documentation tool.
So basically what you do is you you write your components in a sort of formal language and then you have interactions with these components which are all type checked and then it spits out real documentation. The number of times I restarted that project because I was stuck and could not continue 1020 times. If I were to show you the product right now, you would go, oh wow, you're good. And I know I'm not good very long. Time and effort. Time and effort, yeah, same with
gaming, right? I can I can build AMMORPG game server from scratch right now, but that does not tell you the full story, does not tell you how I came to the architecture that I'm using for an MMORPG game server. Yeah, exactly. So I like hobby projects. I can see your passions, I can see the failures, I can talk to you about the actual things that you have spent time on and I can go, OK, why? I see, I see a factory pattern there. Why would you use a factory?
You only have one connection to a database, right? Are you planning to move to multiple databases? Are you? Are you? What are you doing? Yeah, right. Exactly. And we can have a real conversation. Do you think companies don't do that part of the process with regards to hobby projects because people don't have them usually because leak code.
And I'm thinking of a conversation I had with Ida Pimentov, he works at Myro. He loves leak code, but he uses the same arguments as you do. He loves it because you can also train for it and it will make a difference in parts of the project. Not everything. System design is still a thing and that's what you'll mostly be doing when you're creating AP is or nowadays with enterprise software. But when it really matters, then lead code skills become true. Basically.
You won't do it 100% of the time, but that 2% you need it, you will have it. And that's the bar they also interview for, basically. Yeah, Yeah. The two questions I have about that. So the first one is what is the percentage of time you will be spending building out these algorithms in your real work? Yeah. If it is, let's say for, I'm just going to throw out a number. If it's more than 25%, yeah, test for it. Like do the lead code in the view if it is less than 5%.
Just don't do that because you're looking for a different type of engineer. If you want to hire somebody who knows how to build APIs. I want to see a project. I want to see what What type of endpoints have you created? What are the data models behind it? Have you thought about how to communicate with your server? And that is not something that a lead code exercise can teach you. That's true. If you want to do a binary search, sure, do it.
If that is going to be the bread and butter of the job, please ask about it. But I think you will get different type of people. You get less generalists, and I think a highly skilled generalist is. I need to be very, very careful here is preferable over somebody who is very deep into one specific topic. And there are 100 caveats here. So for example security, you want that person who is extremely skilled in security, but as general engineering on your engineering staff thingy
you want generalists. Yeah, that's the I, I didn't know this, but I agree with you. And it's especially now that I've seen consultancy go where there's a few things that are non negotiable, right. Security is one of them. So you will always have excellence in security. People that have that, they pay dividends basically because security will always be there. With new technologies, you have new security issues. People that know based on history and can relate to a new future.
Those are really valuable when it comes to cloud engineers. Someone that can very specifically set up a multi global region with regards to availability compared to an engineer that can do that probably for one region and can also build the software on top of it and can make sure it goes live and has numerous other skills. Yeah, when things are tough and you have a more cost cutting perspective, then you want a person that can do the whole chain, right? They can execute.
If I have a cloud engineer that only does the infra, that means I might need even two of them because then what if one it's on holiday? And then also the people that create the software, I need two of them because what if one first it's on holiday, 4 versus 2 is then the equation you have. And then there's even more in that whole chain of delivering software that you can have the same kind of comparison towards.
So I agree with that. I don't know if that was always kind of a differentiating factor in how I made my career decisions. But back to interviewing, because there was something you mentioned that kind of triggered me how I've seen bigger, let's say the companies that people admire, the more start-ups, scale up environments, there's
big money in there as well. Specifically, their interview process is usually lead code, system design, and then like a culture fit more so towards the end, which I think is interesting here we do it differently. We do a culture fit, then we do a take home exercise. It's very much API based because a lot of the assignments that we have a lot need you to build AP is. And then we have the discussion based on the part of the project that you actually built. You get 8 hours for it.
You can do whatever technology, just make sure that it's deployed and we can have a conversation about it. That's our process. But this process of leak code and system design, I feel like that it is very specific to hire people that can do well at both of those. And they are very trainable, right?
If I spend a year doing Lee coding exercises 2 hours a day, I'm going to become really good at them just by having really good memory, doing pattern recognition, knowing what to use, and actually going through the motions. Same. I feel for system design. There's a lot of books out there that will go through a lot of the basics in the interview process that will teach you how to nail it, and then I can land that job.
But I've never looked forward to putting in the effort to actually do that, nor do I agree with that process. For you, what would be the ideal interview process? You already mentioned that delete code. Only when it's like a good slice of the work that you do will it always be tailored to a work that the organization does. That's a very good and difficult question to answer.
I think it depends. So when I'm specifically interviewing for a dev OPS engineering position, for example, I I know that there are not a lot of do it at home tasks that you can give. Also not a lot of hobby projects because if you have a large system, you have a few clusters, you need to put some firewalls in there. Nobody's going to pay a cloud provider just to have like a hobby project. So you talk about different things. You talk about.
OK, Do you, if they have a Raspberry Pi in in their home, how's that hooked up? What are you doing with that Raspberry Pi? Oh, do you have AVPN? Are you, do you have an ad blocker for your entire house? You know, right, You, you can start having conversations about things that actually matter to them. That's the first thing when it comes to hard skills. I do want to see some proof. So I do want to see some code. I do want to see you go through the process of writing some
code. I don't care about the actual answer. I care about how you write it. Are you, are you expressing yourself while writing the code or are you trying to remember the syntax? For example, pick a language you're comfortable in. I don't care and just start writing. And I want to see that process of writing. I want to see you refactor. I want to see you do things and and you can see that in 20 minutes. So those are things that I tend to focus on.
It is very hiring is difficult. So everybody has biases, Everybody has ways of looking at people seeing negative things or seeing things, patterns that they associate with negative. So I got this great advice from a manager I think six years ago. And that is in the first minute of the interview, you will have assumptions. So what you do during the interview is you try to challenge those assumptions. And so your interview becomes just a way to check your gut
feeling with that candidate. Sometimes I get somebody in there who know who immediately, you know, OK, He knows a lot about programming. Yeah. So you start challenging that. You'd start to find where the bottom is of their knowledge or or the top of their knowledge. However, whatever model you have in your head and, and the same thing goes with sometimes you see somebody and you, you go like, OK, I don't know if he's a good team player. So you start asking questions that way.
What is the type of team you would like to work on? What are negative situations you've been in? What is a situation that would force you to immediately quit? You start asking those types of questions. So your interview goes goes in into multiple directions, but when it really comes to these hard skills, the only way you can see that is by seeing how somebody does it. And maybe elite code exercise will be good then. I don't know. Because you're you're you're.
It's kind of on the spot, can be confronting as well. Yeah. And also there are a lot of things coming together. So if you, if you're trying to solve an algorithm that in my opinion has got almost nothing to do with your ability to write code. It is your ability to have a mental model of the problem and then express yourself in code. Writing an API, writing a server that's performant, or writing a server that can have a high concurrency. That is something that is just
pure engineering. You need to have gone through that process and you need to know how it works so that you're testing different things. I know I'm rambling, but it's I, it's a difficult question to answer. I. I feel like it is, I, I think it's interesting and it's become more interesting and I heard it was one of those IG update calls.
But there was a person I didn't expect that all of a sudden he busts out this inspiring speech and he says hiring is going to be the single most important thing that you do, right? A miss hire is going to be very costly. And that's why we need you in this process and we need your A game because we need to hire the right people.
And then I was like, man, like people, I've heard people talk about streamlining this interview process and then indeed the touchpoint making them as efficient as possible. And I'm like, I, I don't agree with that train of thought anymore. We need to be effective, but we also need to put in the time and effort to hire the right people. Right A wrong hires, especially in the Netherlands, you cannot
get rid of wrong hires. You have an in between period of two months probation and then that's about it. But then of all of a sudden true colours show half a year down the line. That's an issue basically, and it's a big one. And it will bleed into whatever team that person is working on. And it's not even from protecting your own team, but it's also protecting the person that comes in, right? They come in with a certain ambition and if reality turns out to be different, it's not
good fit for them. It's not good fit for both sides. And we have to prevent that. That's why I'm, I'm becoming maybe even a bit more disappointed where you have a conversation all the way at the end. It just feels odd to me. But then when I think of the amount of people that want to be software engineer, want to be in this tech field, there are a lot
of people's that want this. So there are a lot of applications, especially when the market's kind of in a, in a downtrend, which we might be in, we might be going up or down, I have no clue. But especially it's not the same as it was a couple of years ago. That's where you have one application that goes up, you might have 100 applicants and then efficiency still matters. Yeah. So let me ask a question if you have a very long interviews
cadence. So people have like 5 or 6 different interviews before they get a job offer. Yeah. Or versus you have one interview, let's say 1 1/2 hours. Now, I would love to see some statistics on whether or not the hire was correct. Me too. And I would also love to see some statistics on whether or not it is about the interviewer or about the hiring process to
get to the correct hire. And I would love to hear your opinion on as a, as a product manager, as an engineer, as somebody who has ambitions to go into a leadership position. Where do you think that if you're interviewing somebody, you can you can add this little extra that only you can add in order to get a good hire? Yeah, that's, I like that question a lot, actually. Some feedback I've gotten from people that have come to this podcast. Say something about your curiosity.
Maybe the way you ask questions or the way you actually drive the conversation just makes me open up and tell stories. And what I want to hear from someone is that's the questions I also ask when I'm actually interviewing and applying to a company is I want to hear something that they're proud of or something that they learned with regards to a mistake or
something like that. If they have a hard time actually articulating that, then it shows that they might not have the same passion that I'm looking for with regards to this, which might bleed into kind of lack of ownership. And I am making a lot of assumptions based on those questions. But when I tell you, tell me about the most fun you've had creating software, what type of team was it in? What was the setting?
What was the organization? Why was it that much fun that I'm expecting to someone to actually open up and I have to pull in the reins basically to, to stop them because that's what I want to see. Same with regards to failures, right? I think everyone knew I was in operations. I made the biggest mistake. I my phone went off. It was like impending doom, basically. I wanted to run away, but then I realized I cannot run away because they know me.
I did make this a mistake. It's obvious I have to actually face this. So that's the story I tell when it comes to kind of the biggest mistake I've made, especially in operations back then. I can tell many, many mistakes I make. I still make mistakes. I expect people to open up with regards to that and it does show kind of part of a vulnerability. But that would be the person I'd like to work with. I think I hire people that I
want to work with. And then the only thing I still think I have a long learning journey for is hiring people that are not too similar with regards to me because that's those questions are what I really enjoy asking and what I really enjoy doing. But not everyone might be like that. I've heard a really good advice from a colleague who's now an ex colleague, but he said I when I formed the team because he was part on an assignment of also
forming that team. Specifically, I would look for fundamentals that we all need to have with regards to ownership, with regards to communication, with regards to steal, hard skills to execute and then also traits that are different from me. I know for myself I'm not a good planner, so it would be really helpful if there's someone that actually is better at planning that I can rely on, right?
I might not be the best and actually more so sometimes taking the time and actually prioritizing things. I like prioritizing my own things because that's what I like doing. So that will be the priority. Sometimes if someone can objectively say, but we now or you now need to spend time and attention on this because of your role and because we need this, that can be very helpful for me. So that's something I will look
for. But that's more on a team building sense and then it still makes sense in interviewing. You can see from this long ramble, it's not an easy question, but that's. Yeah, genuinely, I like the conversations more so than the late code questions and the hard skills. Yeah, yeah, we do. I do recognize we need that. Yeah, I, it's so fun to see that. I was also rambling when I was trying to. Yeah, yeah.
To express myself in this, it is so incredibly hard because it's a combination of things you don't know that you need to express in the moment. And it's it's it's just extremely hard. Yeah. But I do think that hiring is important. It is difficult, but it's not as difficult as we all think it is. I think that a combination of gut feeling of having a a real
conversation with somebody. Just my advice is always don't hire somebody you cannot have a real conversation with because the, the there are too many variables left. That means a form of openness. Some people call that soft skills. I don't like the term soft skills. I think soft skills are just just a horrible term. But I, I, I'm a little bit weird that way. It's it's a Why would the term be soft? Why would the skill? Be delicate. Delicate touch.
Yeah, it's very old fashioned. Yeah, it's can you say what you want to say in a few sentences, Yes or no? That's a hard skill. Yeah, yeah, yeah, that's why I like the word clarity. Yeah, it's like, and I've really, I think I underestimated that like severely. What an mess it can be when there's no clarity basically and the person to provide that clarity also. That's what I'm looking for, someone that is patient. To be honest, I don't like impatience. I have less patience for impatience.
Basically people that are impatient are quick to judge when you were use words like you should know that or obviously like it makes people feel judged and they will be hesitant to add follow up questions to whatever conversation you have and they might be afraid to give that feedback right now. I've actually tried to write down my feedback and actually specifically go into the details of what people say and actually call them out for it and it's for me and I noticed it also
kind of hurts people. To a point where I wouldn't expect it. Someone that actually was kind of pulled back in with regards to reins and was said, OK, you already should know this, This is the point of the conversation. We already touched upon that when someone's actually asking a clarifying question. Just take the time and patience and explain it and explain it over and over, because in the end, we all have to collaborate. Yeah, Yeah. That's very good observation, a
very good advice. And we we don't do it enough. It's funny how difficult it is to say. I still don't know it when somebody's obviously impatient with you. Yeah. Right. I I don't have a problem with it because at a certain point, especially when people are impatient, I'm like, OK, there are two options. Either I am too stupid or you cannot explain it. You can choose the option. Either way, I'm going to keep asking the question. Yeah, yeah.
But you, me, I think that's where we're very similar. I feel like we're way more relaxed than some people. I do think, I mean, even in the cadence of this conversation, it's more laid back. I think you would have the same patience as I would. And I don't see that in everyone. And from their perspective, this is what I've heard. It's like, yeah, at some point do I make the decision that they genuinely don't get it? But it was, it's always the other person, right?
It's never looking inward and being like, oh, I need to explain it in a different way for this person for it to land. That's what I think It's like, no, I can probably improve and sure, let me see or let me experiment. But it's easier pointing fingers to someone else and that is also like more impactful with regards to that relationship then. Yeah. And I used to be a math teacher. So I've been a math teacher for a little while, a long time ago.
And that that what you're talking about right now is something you learn day one when you're teaching. Math. Yeah, that's what I would have imagined. It is. It is just no explanation will land with everybody. So you need to be able to take a problem and explain it in a different way and in a different way and in a different way and continue doing that because you don't have the option of just giving up on one of your students. If they come to you and ask you for help, you will help them.
Yeah. And I think that mindset is a great mindset to also have in the rest of your career. Yeah, absolutely. Yeah. I'd love this conversation. I must say, Carlos, this has been a blast. Skills that transfer as well as the insights on the interviewing process. I don't think it's going to be perfect. By the way, big disclaimer when I'm talking about patients, like I'm also not perfect, can have a cranky day and then just lose
patience like it happens. But I do think those are the skills we look or in interviews, as well as the skills you can focus on with the rest of your career. Yeah. Is there anything you still want to add before you round off? No, just that this is I I like having these types of conversations. Time flies. I don't know if other people are going to like it, and I'm not sure if I care, but I've had a really good time talking to you and I want to tell you that I
love watching the podcasts. Continue what you're doing. Thank you so much. And continue to have fun doing it I. I will try my best. That's always I I'm a person that really has a hard time taking compliments, receiving compliments. The only thing I can say I'll do my best and thank you so much. Great. Thank you so much for listening as well. Let us know what you thought in the comments section below. Leave a like if you'd liked and otherwise we'll see you in the next one.