Hiring software developers: Assessing the true seniority | The Dev is in the Details #2

‍

In this episode, we talk about personal growth in the software development industry. We will discuss the hiring process, including:

• Common pitfalls and tips
• The relationship between seniority and maturity
• How to gain clarity on the career path you want to follow.
• How to grow professionally and as an individual in the software development space.

If you would like to be always up to date with the Dev is in the Details subscribe to notifications!

Episode transcript

Pedro: Okay, Lucas. So the first question I would like to ask you is something that some people might consider differently in different situations or maybe in different roles, but what does seniority mean to you?

Lukasz: Seniority is one of those hot topics when it comes to recruitment, right? People use those flashy labels, right? And also it gets multiplied by the market where you have people who help with hiring, where they try to come up with a really flashy advertisement, “ninjas” and whatnot, senior Ninja developers and so on. But to me, there is a distinction between the amount of actual expertise and time spent on something, growing that expertise, especially with a focus on a single topic – and more about that in a sec maybe – versus the maturity of a person that we're talking about. When I look at the applications, I am evaluating obviously years, that's important, but that's 40% of the story. Another 20% of the story is consistency. So if someone is a Java developer for a year, a Ruby developer for a year, a Node.js developer for a year, and then another developer, Angular.js, and maybe iOS developer for another year. So do they have five years of experience? Or do they have one year of experience and five different specialties? And this doesn't disqualify them right away, but I want to really find out about the motivation of that individual to jump the stacks and path so much. While, if I see someone with five years in a designated topic, then I would right away feel, OK, they can teach other people. They had five years of exposure to different problems in different environments within the same technology. Their level of expertise is going to be much higher than someone who just spent that time, maybe even doing the same thing five times, but in a different stacks, simply because it exposes them to more challenges.

P: Do you think the selection of different stocks or the progression could be a sign of how mature the person is in terms of... I started off doing X and then I realized that it would be better for my career path to be working with this other technology or I noticed that this technology was growing in terms of adoption and it would be better for me and I would be able to have a bigger impact, or I'll be able to become a better programmer if I change the focus. I think this maybe could be a hint of where the person is in terms of maturity also, right?

L: Yeah, totally. I like to think that there are two extremes in this. One is obviously you can stay for too long in a technology which becomes irrelevant. That's one extreme and the other extreme on the other end is you go into every new flashy technology that just pops up. Somewhere in the middle there, there is consistent storytelling and justified by a transition from one technology to another as a natural development of the interests of that individual. Just to give you an idea from my past when Ruby on Rails was really popular in 2016, what has happened is people – a lot of people in the Ruby on Rails community – naturally started searching for the next thing that they could develop their skills into, right? However, and by the way, it was functional programming at that time that everyone was hyped about functional programming and Scala and Erlang and a bunch of other things came up on people's radar. And it makes sense in the consistency of the story. If I look at the CV, for instance, or a LinkedIn profile, and I see that someone was a PHP developer for web development for a couple of years, and then they moved to Rails and they stayed there for a couple of years. That's very consistent, it’s a very unified experience for that person in terms of what they were exposed to, what problems they were solving, what systems they were building, even abstracting from an actual market in which they were working, whatever they were working on. And then they moved to, let's say, Scala to do web development to help them build applications which are more real time, more able to handle more traffic on their own to scale not by using databases, but maybe queuing systems. I see very interesting storytelling on how these people think, what their interests are. Where is their curiosity in how the systems are built? Yeah, does that answer your question?

P: Yeah, for sure. It was also like personal curiosity because I'm not very... I'm not being a developer myself. I was curious to understand how these technologies sometimes connect with one another and form this storytelling, as you mentioned. That's quite interesting. But then, of course, it depends on the different levels that the person is in their career. If they are just starting out or if they already are more experienced as a professional. I know there are different scales, let's say, or levels of roles that you can have as a software developer. So maybe you can tell us a bit about that, like where the person starts as an intern or trainee and the progression they can expect throughout their career.

L: Right. That's a really great question because nowadays I see that a lot of people who go into programming, a lot of really great programmers come from a “non-programming” background, so to say. So, someone who didn't finish a college of mathematics, physics or general computer sciences, especially through pandemic and right before it, it was quite a thing to progress people's careers and start learning through coding as long as it was made for good reasons and people really loved problem-solving at that level, using code. It actually could provide better results in my experience than someone who finished computer science – especially in web development, I don't know about other areas. So, like a person starting as an intern or trainee, would be someone who just knows very little or nothing and they're looking for their thing. And you see that they understand that coding is 90% about reading someone else's code and your own code, and they're able to handle it frustration-wise and patience-wise. They're going to eventually progress to the junior position where what sets them apart is that the junior is able to get a job, okay? They still have a lot to learn, but they can get a job, they can get hired as a junior developer while a regular, senior or some other leader position will look after them. So then in my personal dictionary, because I feel like there's a lot of different ways you can mix this and what people call these levels of seniority, there's a regular developer, someone who does their job well and, for me, the main distinction is that they know the toolset. They already have some preference for which direction they want to go. They know how to formulate questions properly. They know how to help themselves by Googling, by using different tools like Stack Overflow. And they know how to propose solutions even for seniors to consider. They might be – but occasionally, depending also on character traits – correct or incorrect people for helping juniors as well. Then we have seniors, and these are people who should really shine in terms of setting trends. But here – we'll talk about this maybe in a sec, let me finish with the seniority first – there is an important aspect that they need to be open minded to listen to everyone from any position in the company. If they lose this, to me, this is not a sign of seniority. And what I meant before, when I said I'm going to get back to this, is I evaluate people by how senior they are within the technology stack or specifics of the coding problems that they are really good at versus (or compared to) their maturity as human beings. How much are they able to separate themselves from their code? That is a major question for me to distinguish between a regular and a senior developer. Someone else told me that someday as well: “You're not your code. Don't get upset when someone changes it. Don't get upset if your PR gets rejected. Learn from it. See what could have been done better.” And if you reach that point that you can disconnect your ego from your code, that's for me a sign of maturity. And you can then be open to listen to juniors presenting ideas which you may not even think of because of your own biases. And yes, you have a huge luggage of your own experience, of course, but it can also occasionally work against you because you will be biased. So that, for me, is seniority. It's only there when it's equally with maturity. And if I have amazing developers with dozens of years of experience under their belt, but they're single-players, so to say, and they always think that they do that best simply because of their experience, and they're not willing to open and grow and learn, they close themselves to the growth mindset, then they are not senior. And I would not consider them senior because, behind a senior, I should be able to structure a squad of a couple of people working together in any way, Agile or otherwise. But with this attitude, I can't expect that to happen. And further down the line, we have what I call the leadership path. So in different companies, this is called differently. But let's call it for the sake of this conversation, just a principal engineer who is someone who already enters a territory of becoming a slightly business-oriented person to better understand why these things happen the way they happen. And from there, it's interesting because I see people divert to product roles or various different roles in leadership where they manage multiple teams on a high level or they discuss things like system architecture, and then they become what is called an architect, which is a pure expertise-driven role with an understanding of the business requirements, but also expertise on how to connect the higher bits and pieces together into the entire system and also project your own experience towards it, in the sense that you can predict some scalability risks and trade-offs – especially trade-offs – in what this application or the code base will be able to do and what is it sacrificing to be able to do those things, because it's always a trade-off. Furthermore, or should I say in parallel, you have roles where you become a technical manager and maybe final at some point VP of Engineering, which is still quite technical, and above that, CTO of the organization. That is tremendously diluted label because, depending on who you talk to and if it's a three-person startup or 5,000 people company, it means completely different things. Everything in between as well, they mean completely different things. Yeah, those are the levels that I consider different seniorities on and how I label them personally. Obviously, there could be different things, people like different labels, different companies use different labels. Yeah, there's also a mix of different roles. There are programmers, front-end programmers who specialize very heavily in UI/UX, and they have Design skills. So of course, this is going to be its own unique path. Same with Products, same with Quality Assurance and different backgrounds – if they were Quality Assurance first or if they became Quality Assurance after being a developer. So there is obviously some variations of that as well, depending on how you actually structure the role per se. But for me, this is the basis for the discussion usually on the seniority and maturity level of an individual we're talking to.

P: I thought it was super interesting to think about how it's similar to what you would call “typically” creative activities or roles. I come from a Design and Marketing background, which is what you usually think about when you talk about creative work. But it's very similar, this idea of not getting attached to the solution you create. I think this idea of the seniority in such areas is the same as it is in software development. That's because software development it is also creative work, because you're creating something out of nowhere. You're trying to apply your knowledge into building something from scratch sometimes or improving something. There's a lot of different ways to achieve a certain outcome. It's not always going to be black and white, this is right, this is wrong. There are different ways to do it. It requires a level of being humble to accept that your idea might not be the best one. I guess getting comfortable with this process of being open to the possibility that you might not have the best idea, that you can always improve, that you're going to continue failing no matter how experienced you are, I guess this is what really increases the level of maturity of a person, and then eventually they become more senior, right? Like, dealing with the frustration.

L: Totally, yeah, dealing with the frustration and the constant change and the pressure of that change. And that things are never permanent because you code one functionality today and it evolves and maybe even it gets dropped a couple of releases later down the line because there were certain hopes for it, maybe there was even A/B testing done, which showed this is the direction we should go to, but at the end, the actual market verifies, right? And no customer wanted to use this extensively and we drop it. And we have tons of examples like that from the market, like the Google Reader or a bunch of other things which were simply not business-viable for the company, and they decided to drop it. And I could probably come up with a dozen others. But ultimately, it's important to understand, look, you solved the problem at that time knowing what you knew in the best possible way. But today, you would probably solve it different way, right? Or or you would even consider if it was the right problem to reconsider if it was the right problem to solve in first place, right? Because maybe we're not solving the right problem to start with. And that requires, I agree fully with you, 100% is humbleness. And I also look for that in people who I talk to for positions in various organizations, what I had a pleasure to recruit for.

P: Yeah. So this is an interesting segway into the question I wanted to ask about hard skills and soft skills, because it's one thing to be very good at one technology or being great at building applications or whatever, or even in the architecture, whatever technical aspect it is, it's just hard skills, easy to measure if the person is good or not, if they know their stuff or don't. But as you progress in the seniority scale, soft skills become more and more important. As we mentioned here, being humble, being willing to help others, willing to accept that, deal with different points of view, having a decent style of communication where you can talk to different people in different areas. How do you identify soft skills and how do you measure the seniority from the software aspect?

L: Yeah. So during the interview process, there's different stages, right? And different organizations do them differently. But ultimately, you can divide these stages into two types: one is the technical evaluation, where you could sit down over the code over the same laptop or remotely with screenshare and ask them about a bug in the code you just solved yourself this day. So are they able to notice it? Are they able to propose a solution? How do they argument the solution? This part already goes towards the other direction, we’re trying to test their skill, to estimate how are their soft skills, right? How defensive or how well they are able to build their arguments for certain ideas. And there is riddles that we do. So we test... You see, for example, I don't like to ask questions about specifics in the code that people would have to remember, because you can always google for these later on a daily basis. This is normal for people to check and check in a different piece in the code or how something was done before and just reuse that and move forward. But I want to see how they think on problem-solving. Are they happy with the first solution that they found? Do they find the problem ridiculous? Yeah, there's a very good book about this called “How would you move Mount Fuji?”, and it’s full of riddles. I believe it was written by some people from Microsoft in the 1990s. They were giving these riddles to people and asking them questions during interviews like, “How many Christmas trees are there in New York for Christmas?”, right? And that's it. That's all you got. And it's a conversation from there because it doesn't matter what the answer is, but how they think. Are they able to think about, is it purely a holiday thing? Or is it also a religion-driven? But does it mean that shops may not have Christmas trees where they present their inventory? What about public buildings? What about schools? And so on and so forth, right? So if you come up with that, you can come up with some crazy number, hundreds of millions, and it wouldn't matter because just showing how you trace this and whether it's relevant or not, it doesn't matter. But just showing how they think about it and how they arrive at next conclusion and next solution, next conclusion, how they iterate this process and how they stay hungry. Because if they just say, “Okay, can you tell me how many people is there in New York?” And I say, “Well, yeah, about nine million”. Okay, so let's assume half are going to have a Christmas tree because they follow the holiday/religious habit, right? And if that's the answer, that's not good enough. It's not about the number. It's just that they're just satisfied with the first possible answer. And this is also a sign of certain curiosity for dwelling deeper and growing as individual. I still consider that a mix, but I would still lean towards saying this is more a technical part. On the soft skills part, I like people who, on their own, take Gallup tests. There is a raise now on people coming in with CVs and they already have their Gallup tests on it with their top five, top three strengths, for instance. They could use any framework for that matter, but I just really like it. It shows me that they really want to grow also as an individual. Second of all, in those interviews, if I'm present, I usually ask about their value system for work. What does it mean to be committed? What does it mean to own certain things in the team or functionality wise in the project? What does it mean to be transparent and what feedback and how feedback should be structured? Also, I ask about their past experiences. Have you provided feedback, 360 or otherwise, to your colleagues? And when you do, how do you do this? And when you receive a negative feedback, what is your first reaction? I'm checking for the self-reflection, right? Is it present? And of course, it's an artificial environment, and the candidates focus on answers so they can prepare to this conversation. As such, if they proceed and they're happy with what they heard and we are happy with what they said in any setup that I've been to in the past and we vote them in as a team or as a committee that is running that recruitment, usually we give them a couple of weeks, a couple of months of a test period where we see how they actually act in the real environment. And both of these, so soft skill and hard skill situations are being evaluated constantly over the course of three months. And only after this they would stay with the organizations permanently, when we had an absolute certainty that they would not derail the team that they're working in from soft skill perspective, and then they wouldn't be slowing down the team's development because of dragging it down by not being able to deliver on topics. And of course, this is scaled up or down based on the seniority and maturity of theindividual. So the team would have slightly different expectations from a junior and senior, obviously. Well, not slightly, actually quite some different expectations from junior and senior in that matter.

P: Yeah, I guess when hiring, one of the challenges is also to be able to identify how close to reality what the person is saying really is, because in an interview environment, you're trying to look for the right answer and not necessarily show how you behave. Maybe the person doesn't even have the self-awareness to do that, because when you're angry, you don't realize how you are talking to the other person, how the other person is perceiving you, or when you're frustrated or whatever, or if you're giving feedback, you might think you're doing it in a way that you consider fine and just direct but polite, but the other person might feel attacked. I guess what I'm trying to say is that even no matter how good the interview is, it's always going to be after the interview, once the person is inside the organization, actually dealing with the situations, that you are going to be able to verify if what they said on the interview was reflecting their own behavior or not.

L: But there's also another side to it because there's a lot of focus on people who oversell themselves, right? They come across during the interview as really high-skilled individuals and high-expertise individuals, great soft skills and whatnot. And then only during the work, they come short of that and it turns out they're not who the team thought they are. And it happens, right? But there's also another scenario, which I call the pearl, the "hidden gem" or the "hidden pearl" scenario, when the individual is underselling themselves. I find it very interesting. I don't know if it's a culture thing as well. I see people from Central Europe are doing that a lot. I see people from various countries in South America doing that a lot. I think this is maybe different education systems which impose different level of confidence in people when they finish it. I don't know. I never really arrived at any decisive conclusion, but I see this a lot. In that case, I like to pull the candidate a little bit towards my narrative of like, "Hey, tell me the story about this work you've done here", to see if there's too much humbleness, right? Because they say "Oh, yeah, I solved this mathematical problem, and I don't consider it a big thing". And then, for instance, I know from experience that it would take me many, many days to solve this. So for me, it's actually quite impressive. So now the only question is, are they aware of this? Is this real humbleness? Through the conversation, what comes across is that, for instance, they have a lot of things they didn't even put on their LinkedIn, or they wrote some code that they're not proud of, so they didn't commit it, they didn't created a project on GitHub where I can actually check and verify it. But then they show me some code base which is really impressive which they work on on their spare time. And it's their pet project, so to say, even not for commercial use, but simply because they were interested in something. I see a lot of people playing with a Raspberry Pi or a lot of other things just to build a simple blinking light. Of course, commercially doesn't make sense because their time is worth so much more doing the job. But that curiosity, again, is a hidden gem because not everyone has it. And if you want to have a real engineering team which can dwell on really hard problems, having people who demonstrate this curiosity is amazing, right? That has always been my experience that I want to work with people like that, who remain hungry and try different things, even to try to solve the same problem in various technologies in parallel, but focus on the problem, not the technology, just because it's cool, right? Just to see how you would address it. There's a thin line here between wearing a mask and being a super humble, hidden genius, so to say, just unable to present oneself. And I find it very interesting because companies, when they hire, I think in the initial stage of CV scanning, so to say, you see people going and checking plus, minus on a specific checklist of items that the candidate should have. But one person can write dozens of things, and another person will summarize it with a single point. And it's important to not downplay this because usually this happens around junior and regular level, of course. But I have seen occasionally a senior who was also not able to sell themselves properly and it turned out to be a genius, turned out to be a real rockstar and also amazing team player and eventually became a leader. So it's important to recognize that and give credit where credit is due to these guys.

P: What are the common mistakes or pitfalls that you find when hiring and interviewing for these different levels of seniority? Are there some common mistakes that junior people tend to do when they are applying for a job that more senior people usually don't do?

L: If you consider seniority by years on the market, then the answer is no. They follow the same principles. But if you consider the seniority by maturity, then the answer is yes. So here's what I mean. There is a tendency for people to rush to the next level. It almost feels like a game and you are really and trying to level up your CV so you can say you're a senior. So I have seen people who had the first job when they were junior, and that was for a year, maybe even less, 9, 10 months. And then right after this, they started a second job for a year, maybe 14 months, and they say they're regular. And then they started the next job and they say "Oh, now I'm a senior" because it's my third job. So technically, after 14 plus 9 months, they are considering themselves senior simply because they really want that label because in their minds, it positions them better on the market, potentially also financially. But to tell you the truth, I think some of the better ones in terms of maturity do understand that. They also understand that rushing this cuts their wings for some of the really most interesting projects and the best companies out there. The market is currently in a slowdown, but I still think that in IT, there's always going to be space for everyone. It's just a matter of how much time someone invests in looking and what work they're looking for. Always, even in the downturn like that, like we're experiencing now at the time of recording this. But once you allow yourself to follow that path of that rapid seniority growth, I think there's a lot of examples. I had a lot of examples of: A, burnout; and B, a massive disappointment because at the end, they're not growing, right? So it yields a lot of frustration. And when I say not growing, I mean, would they allow themselves to listen to a regular when they're considering themselves a senior because they rushed through that label? Are they able to step down from the label measurement context, contests, and really consider what the best argument is? Are they able to put together that argument because of the rapid growth – I don't want to say fake because there are really good people out there who can do that growth in a couple of years, really, that I have also seen. It's rare, but it happens. But at the same time, do they allow themselves the space for growth? Because it's not a rat race. At the end of the day, I think working on any project or any problem collaboratively is more beneficial for the outcome of the project, but also for the group of people and every of those individuals independently. So this is number one, rushing through with levelling up. Number two is a sense of "the more, the better". So let's reconsider the same candidate across the three years, three projects, and they put 15 technologies. I'm an expert in just few things – a couple of things even, not even a few. And I know it takes a lot of time to build that expertise and to even stay current because even in that limited space, things can move forward really fast. So if someone claims that they know 15 different frameworks and some of them are even competing, you can't really work, I guess, most of the time, there are circumstances, of course. But you got .NET and you got Java and you got, I don't know, some Python thing. And one is in Azure, another one is in AWS, and another one is in Google, and all of that under one roof in one company in one year? Unlikely. Like, unlikely that they did that and unlikely that, even if they did that and those were actually three different teams or three different products, that you actually had a valuable learning experience there in that short period of time. It's possible, but it's unlikely. So I will dwell on it and I will ask about it in greater level of detail. And usually, my experience has been that people, they crumble and they are like "Okay, yeah, but I was doing this in parallel". I was like, What do you mean you were doing this in parallel? Four hours this and four hours that, so it's even half time, right? For three months. How does that look like? Then a couple of deeper questions, especially when they say they're... That's another thing, the third thing that I see to segway into it is sometimes CVs have what I call marking mechanisms. So they would say "Oh, I know SQL from zero to five, five out of five". Right? When I see CV like this, I'll get someone who is a SQL expert that wouldn't be me in the organization where I'm at. I would ask them to put together a nested query scenario for optimization, right? Because if someone says they're a five out of five, I expect them to know that and I expect them to know what the views are on materialized views and whatnot and why do we do that or why do you do normalized database. I really, really press on that because if someone is telling me they're an expert in this and everywhere else they put themselves four out of five, three out of five, then if I am able to challenge this five out of five, it really undermines the evaluation of that candidate in everything else. It's a little bit tough to do, really, because occasionally you get emotions in the candidate, which is not great and this is not what we all want. But if someone is so overly confident, I want to see what's behind that. And it turns out occasionally that I'm proven wrong – sorry, frequently – and the candidate is really a SQL genius, but sometimes it turns out they are really not. And then it projects badly on all of the other evaluations and things that they said, right? Because it's inflated. They build an image, which is not true. I see this a lot in people who consider themselves seniors.

P: It's like "fake it until you make it".

L: Yeah, I think there is a certain level of bias to it because if you were in, let's say, five years of experience and everywhere you use SQL, but everywhere you just do simple joins and simple SQL queries and a couple of inserts, it just doesn't make you an expert. It's like, you don't know what you don't know, right? I presume that in that knowledge base of their own, joins and selects and insert, they're really an expert. But they need to understand this is just scratching a surface of what the database can do for them. Then simply because they had no need or no interest, that's fine. They haven't got a chance to deep dive into this or even to check what other database systems there are and different storage types there are. But the point being is that, that's again a sign of lack of curiosity in that area. So saying "Hey, I'm really an expert in this" and then turning out that this is not their expertise or interest, is eye-opening for both parties. Yeah.

P: I totally get it.

L: So those are my top three picks, I would say. I'll be very careful with marking CVs and benchmarking oneself to any scale because it sends a... When you say five out of five or 10 out of 10, there's really not much space for you to say what else you can learn there. This is one of my favorite questions, by the way. So you're 10 out of 10 in SQL. Even if I don't ask the next question, I ask "What else is there to learn", "how current are you with the latest developments in different database engines", right?

P: Because a true expert will know what they don't know, right? They'll know where is the bleeding edge, what direction is that technology growing, where it's being applied.

L: That's one thing. But potentially, even if they don't know that, they understand that stuff is moving so fast that it's impossible to say that in any given point of time, they are expert in such a generic thing as SQL. I'll give you an example. If you have different versions of Java, and someone writes they're a Java expert, amazing, five out of five. But then in the last jobs, they only worked with Java 8 and Java 14. As far as I'm concerned, I think we're on Java 21 right now. Released in 2021. Then the question is, how current are you tracking what's in there? Why haven't you pushed for updating these older projects? Why haven't you pushed for more projects in the later technology if you're considering yourself to be so strong with it. This can be asked in any circumstances, in any version, simply because all of this stuff is undergoing development, just to allow yourself to think that you are an expert in function of time.

P: I guess some people would even prefer to be more targeting this career path of becoming an expert in one thing rather than trying to grow on the seniority part of the equation. The person might be interested in staying at the senior level and not becoming the more business-oriented leader. Maybe the person wants to continue working the execution side of things and not necessarily managing other people or dealing with the politics of having to deal with other leaders in other departments, stuff like that.

L: On one hand, I would say that as you grow, there are certain technologies or certain items on the CV that I would like to see. In other words, in my opinion, it's hardly possible to be a backend engineer and consider oneself a senior without any SQL knowledge. There are edge cases to this, as always. There's nuance because maybe they come from the five years of background working with document-based databases, and that's fine, right? But in overall storytelling, there has to be certain things, and they don't have to be at the same level of expertise, right? You can be an expert in building backend systems that scale infinitely, right? Horizontally, vertically, whatever, become an expert in infrastructure and still just do simple SQL queries. But that sends a signal that this person is independent, that if they receive a task or a feature to be built, they can do it comprehensively from the bottom up, whichever way. There's a thin line here between what I consider full stack because people have their biases. Someone who is really amazing with databases might not like CSS and someone who is really amazing with frontends might not like SQL, that's fine. But at the same time, I think that the CV has to tell a consistent story about the individual. And this is the path of expertise, an expert. And then there's this other part of your question where I felt you're asking more about, do you want to be more in a decision-making process and people interaction process where maybe you discuss the entire strategy. Maybe you even become a part of a hiring committee yourself when you decide on who joins the company and who leaves the company, even if there's underperformance. That is very tough and very hard for people to get into, right? Because we all like each other, but it's important to also offer honest and truthful feedback where someone is underperforming to help them grow one time, two times, three times depending on company policy. There's various things which then play with emotions, right? Of the individual, but also on the people they interact with. I think this is an entirely different game. I think this is the soft skill game, as you mentioned.

P: Yeah, exactly. That's what I meant, that you can have 30 years of experience. Let's say you started as a backend engineer. You can stay as a backend engineer for 30 years becoming an expert and continue in the technical side of things, or you can have 30 years of experience being a backend engineer and then slowly going more towards these management positions, executive positions. For example, a CTO with a backend background, he won't be involved in the day-to-day operations, technical side of things, as the very senior engineer is. He has to deal much more with the politics of the company or dealing with other departments. He or she has to be more... The soft skills are much more at play on their day-to-day activities, rather than the person who is just dealing with the computer and other technical-minded people all the time.

L: Yeah, totally. I agree.

P: Yet they both have the same, let's say, amount of experience, let's say. They have valuable experience that helps in their day-to-day lives. But one of them goes deep into the technical side and one of them goes up in the management side.

L: Totally. Hopefully there's not too much politics, right? That's what I was going to say there. But I hear you. Yeah, totally. Yeah. Do you ask me, just to confirm I got that right, do you ask me about what's the cut-off point? What is the progression from one to another?

P: No, it's just more of an observation that you can choose where your career path takes you. If you prefer to continue developing in terms of seniority, but still remain focused in the technical side, or you will have to necessarily develop more your soft skills if you want to grow in terms of the, let's say, the hierarchy of the organization, right?

L: Yeah, 100% with you now. What I have noticed, and maybe this could be qualified as one of the common pitfalls or common mistakes as well, frequently I see that people do not have an idea... They don't have an objective to end up in one or the other way. What usually happens is the circumstances in the given organization or team because someone departs, someone joins, there is some split or buyout or they join at the right time, they become that person. They're nominated to become that person either by the team or management or someone else. And it's okay as long as it turns out that they are really liking it and it's a good opportunity for them. I don't necessarily agree that expertise path has to always transition into leadership path. I think leadership, in my view, should be more about enabling people and coaching them to achieve certain things, especially mid-tier leadership, rather than telling them how to do things. Experts tend to be these people, you go to them for their expertise and maybe a moderation – even if they know the answer, a good expert would still moderate the conversation to hear all opinions and segue into the solution rather than tell it right away because you want the team to develop and dwell on the problem and every individual in the team and the problem independently. And as long as it's a planned path, that's wonderful. If someone is dedicated and committed to become that leader or that expert or whichever path they decide to take or even parallelize a little bit with Product or a little bit with Design, whatever is into their liking and whether they actually have a positive result, that's great. But I think it's more often than not a situation where a company needs someone in a specific role and they put them there with a temporary, interim assumption, turns out to be permanent, without a deadline moment where they can struggle or they will make their make it the best they can. But it could also be a completely different experience with a lot of stress and new things with different rules to the collaboration. For instance, upping up people from expertise in coding to suddenly becoming people who should talk with clients, right? This is obviously culture-dependent, culture and organization culture, because I feel that organizations who say it straight from the beginning during the interview process that "look, we are client-centric and you're going to be having this exposure to our clients" is also attracting a proper character to this organization, versus a transition where you have a very withdrawn group of people who solves very complex mathematical problems and they generate, let's say, it's a quant project for a traders desk, right? That is entirely different to say that you would now put those guys on the trading floor and start talking to all of these traders, which have a completely different level of communication. I think it's important, basically what I'm trying to say is to set your own path and have an idea at least for what your next step in the career is and maybe what the end goal in your career is. So it's less of, I'm a leaf in a river from one bank to another, whatever happens, but more controlled and more designed career development.

P: Yeah, and I guess that applies for all the stages. No matter if you're just starting out or if you are already in a, I don't know, senior or leadership position, being aware of where you are now and where you want to go next is, I guess, the constant exercise that needs to be done in order to have a fulfilling career path and continuing developing yourself, right?

L: I agree. And also having this helps you to make the right choices about the kind of environments and organizations who want to work with. For people who like it a little bit slower and stable, bigger companies, corporates, are better off than someone who likes to constantly be challenged and change their hat constantly, especially in the younger stage when they're still trying to piece things together and figure out who they want to be. It really helps them greatly to be in a startup, where there's so many things to get your hands dirty with to try and learn from. Totally.

P: Okay. Do you have any, let's say, final piece of advice for people who are in these different stages or maybe they're struggling with their career path, how to find their way or maybe how to find where they need to develop themselves? Or maybe you have suggestions of some book or some resources that has helped you or has helped other people around you?

‍L: Right. I feel that going to meet-ups is of a great help because I frequently had a vision of a role that I want to become. And when I came close or when I became that role and I got that role, I realized it's not what I imagine it's going to be. And if you go to conferences and meet-ups and you see people who are there, you may realize "okay, this is to my liking", or "this is not to my liking". "This is even better than I thought". "Okay, this is not as good as I thought". So that's number one, expose yourself to people who are already there. And this generally applies to a lot of different areas in life, I guess, even with hobbies and whatnot. When it comes to books, I think that really depends what interests people. But for me, on the engineering side, it was important to have a pet project, to have something which you're playing with in your free time. There's nothing wrong about watching some series or playing some games. But at some point, I felt the urge to be additionally creative and try things on the side. And maybe something even comes out of it, like you have your own spin-off or you have your own little product, which other people can use, or you become part of a community, open source community, and you develop these projects, which is also amazing, right? It doesn't always have to be commercial. For reputation, it's very important also, very beneficial to have that open source community exposure. Ultimately, it's a human interaction thing. Do more of that and you will see it will help you. It will be like a compass guiding you towards better visualized outcome that you can see for yourself at that stage of life because that's also a variable.