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
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.