The Dev is in the Details
This podcast is about the world of Software Development in particular and technology in general. Here, you will find thoughtful discussions about tech leadership, AI, the future of technology, and success stories told by the people who made them happen. Your host is Lukasz Lazewski, a seasoned software engineer, tech leader, and entrepreneur.
The Dev is in the Details
Hiring software developers: Assessing the true seniority | The Dev is in the Details #2
► How to identify and nurture top software talent?
Join us as we tackle a pressing issue in the tech industry: the shift away from hiring oversold software developers with limited real skills. Discover how to find hidden gems—people who may not excel at self-presentation but have invaluable potential. Lukasz and Pedro also explore the necessity of skillset standardization for each role and the industry-wide challenges posed by its absence. Stay tuned for insights on reshaping hiring practices and embracing authentic talent in the dynamic realm of technology.
► In today’s episode:
- Software developers' hiring process, including common pitfalls and tips.
- The relationship between seniority and maturity.
- Assessing skill set fully and seeing through the presentation
- The importance of consistency and evaluating the professional journey
- Hard skills and soft skills required at different levels of seniority
► Decoding the timeline
00:00 | Seniority and Career Growth in Software
07:15 | Seniority Levels in Software Development
15:35 | Assessing Skills in Software Development
23:44 | Hiring and Interviewing Challenges and Pitfalls
31:22 | Evaluating Candidates' Expertise and Credibility
37:58 | Career Paths
***
The Dev is in the Details is a podcast where we talk about technology, business and their impacts on the world around us.
Łukasz Łażewski 👉 https://www.linkedin.com/in/lukasz-lazewski/
Write to us 👉 podcast@llinformatics.com
Hello and welcome to the Dev Is In the Details podcast. I'm Łukasz and I'm Pedro. Here we talk about technology, business and their impacts on the world around us.
Pedro:Let's go In. This episode we talk about personal growth in the software development industry.
Lukasz: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 and how to grow professionally and as an individual in the software development space.
Pedro:Okay, łukasz. So first question I would like to ask you is something that might some people might consider differently, in different situations or maybe in different roles. But what does seniority?
Lukasz:mean to you. 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 market, where you got people who help with hiring, where they try to come up with really flashy advertisements. You know, ninjas and whatnot, senior Ninja developers and so on. But to me there is a distinguish between amounts 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.
Lukasz:When I look at the applications, I am evaluating, you know, 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, nodejs developer for a year and then another kind of developer AngularJS and maybe iOS developer for another year, so do they have five years of experience or do they have one year of experience in 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 stocks and path so much, while if I see someone with five years in a designated topic, then I would you know right away feel okay, they can teach other people right? They had five years of exposure to different problems in different environments in within the same technology, so 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 stocks, simply because it exposes them to more challenges.
Pedro:Do you think the selection of different stacks or the progression could be a sign of how mature the person is in terms of? You know, 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, you know, 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.
Lukasz: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, but another one is also that's one extreme, and the other extreme, on the other end, is you go into every new flashy technology that just you know pops up and somewhere in the middle there there is a consistent story telling and, you know, justified by a transition from one technology to another as a natural development of interests of that individual. It's just to give you an idea from my past, when people were, when Rubio and Rails was, you know, was pretty popular in 2016, what has happened is people, naturally a lot of people in Rubio and Rails community started searching for a next thing that they could develop their skills into right.
Lukasz:However and, by the way, it was a functional programming at that time that everyone was hyped about functional programming and Scala and, you know, erlang and a bunch of other things came up on People's Raider.
Lukasz:And it makes sense in the consistency of the story. If I look at the CD, for instance, or a LinkedIn profile, and I see 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, very unified experience for that person in terms of what they were exposed to, what kind of problems they were solving, what kind of systems they were building, even abstracting from an actual market in which they were working like whatever what 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 database 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?
Pedro:Yeah, for sure it was also personal curiosity because 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. So 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 and 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 a trainee and the progression they can expect throughout their career.
Lukasz:Right. So 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 non-programming backgrounds. 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 we had a, it was quite a thing to progress people's careers and start learning the coding. As long as it was made for good reasons and people really loved trying, you know, problem solving at that level and 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 intern or trainee would be someone who just knows very little or nothing and they're looking for their thing. And if there's, like you see, that they understand that coding is 90% about reading someone else's code in your own code and they're able to handle it frustration-wise, right and patients-wise, they're gonna. They're gonna eventually progress to the junior position where what probably makes junior an intern, what sets them apart, is that junior is able to get a job. Okay, they still have to get a lot, lot to learn right, but they can get a job, they can get hired as a junior developer, where regular senior or some sort of other leadership leader position would look after them. But eventually, you know, this is what the distinguishment is at the end. Yeah, so then, in my personal dictionary because I feel like there's a lot of different ways how you can mix this and how people call these seniorities there's a regular developer, someone who does their job well, and for me, the main distinguishment is that they know this tool set. They already have some sort of you know reference for which direction they want to go. They know how to formulate the questions properly. They know how to help themselves by googling, by using different tools, you know 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 you know helping juniors as well.
Lukasz:Then we have seniors and these are guys who should really shine in terms of setting trends, but in here, like we'll talk about this maybe in a cyclet, 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 you know 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 that 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're really, really good at versus, or comparably to, maturity as a human beings. So how much you know are they able to put to separate themselves from their code? That is a major question for me.
Lukasz:To distinguish between regular and senior developer. I used to say you know, I someone else told me that someday as well You're not your code. You know, 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.
Lukasz:And if you, if you reach that point that you can disconnect from your, from your you know ego, from your code connections, so to say 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, huge luggage of your own experience, of course, which can also occasionally work against you because you will be biased. So that's for me seniority. It's only there when it's equally with maturity and if I have amazing developers with dozens of years of experience behind 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 a new and grow and learn, they close themselves for the growth mindset, then they're not senior and I would not consider them senior, because behind the senior I should be able to structure a squad of couple of people working together in any in any way, agile or otherwise. But with this kind of attitude I can't say that I'm not a senior.
Lukasz:I'm not a senior, I'm not a senior in any way agile or otherwise, but with this kind of attitude I can't expect that to happen. And further down the line we have what I call sort of leadership path. So in different companies this is called differently and I think that's the kind of this conversation just a principal engineer with 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, high level, or they discuss things as an architecture and then they become what is called an architect, which is pure, you know, expertise driven role, right with with understanding the business requirements, but it's expertise of how do you connect the higher, higher bits and pieces together into the entire system and also project your own experience towards it, in a sense that you can predict some risks in scalability risks and trade offs, especially trade offs in what this application or that code base will be able to do, or and what is it sacrificing for, for, for being able to do those things, because it's always a trade off. And furthermore, or should I say in parallel, you have roles where you become a technical manager and maybe finalize some point VP of engineering, which is still quite technical, and, above that, cto of the organization, and that is tremendously diluted.
Lukasz: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 thing, and everything in between as well, it means a completely different thing. So so, yeah, this, this is those are the levels that I consider different seniorities on and how I label them personally for my own sake. Obviously there's there could be different things. You know, people like different labels. Different companies use different labels. Yeah, there's also a mix of different roles. Their programmers, front end programmers, will specialize very heavily in UI, ux and they have a design skills. Of course, this is going to be its own unique path, same with products and with quality assurance and different background if they will quality assurance first or if they became quality assurance after being a developers. So 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 individual we're talking to.
Pedro:I thought it was super interesting to think about how it's similar to what you would call, maybe, typically creative activities or roles. I come from design and marketing background, so it's what you think about when you talk about. You know some 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 in it is in software development, and that's because in software development it is also very 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, and there's a lot of different ways to achieve a certain outcome and it's not always going to be, you know, black and white.
Pedro:This is right, this is wrong. There are different ways to do it. So it requires a level of being humble to accept that your idea might not be the best one and, 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 drives, increases the level of maturity of a person and then eventually they become more senior Right.
Lukasz:Like dealing with the frustration Totally. Yeah, dealing with the frustration and the constant change and the pressure of that change and that things are never you know, things are never a part of it, because you code one functionality today and it evolves and maybe, maybe even it gets robbed a couple of three leases later down the line. You know, because no one there were certain hopes for it. Maybe there was even a testing done which showed this is the direction we should go to, but at the end, at the end, 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 and like Google reader, right, or a bunch of other things which were simply not business viable, right for the company, and they decided to drop it.
Lukasz: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 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. So that and that requires I agree fully with you 100% is the humbleness and I also look into, look, look for that in people who I talk to, you know for positions in various organizations, what I had a pleasure to record for.
Pedro:Yeah. So this is an interesting segue into the question. I wanted to ask about the hard skills and soft skills, because it's one thing to be very good at one technology, or you know, I'm great at building applications or whatever or even in the architecture, you know, whatever technical aspect it is. It's just hard skill, easy, 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, the soft skills become more and more important, as we mentioned here being humble, being willing to help others, willing to accept that you know, deal with different points of view, Having a decent style of communication where you you can talk to different people in different areas. How do you identify the soft skills and how do you measure the seniority from the software aspect?
Lukasz:Yeah, so During the interview process there's different stages, right, and different organizations have been to did it differently. But ultimately you can divide these stages into two types. One is a technical evaluation, where you know you could sit down over the code Over the same laptop or remotely with screen share, and ask them about a bug in the code you just salt yourself this day. So are they able to notice it? Are they able to propose a solution? How do they argument the solution?
Lukasz:This part already goes towards the other, the other direction, to estimate how, how are their soft skills right, how defensive or how you know well, how well they are able to build their arguments for for certain, for certain idea. And then there's riddles that we do, so we test. You see, I, 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 you know, check in a different piece in the code or somehow some, how something was done before and Just reuse that and and and be, and be and move forward.
Lukasz:But I want to see how they think and problem-solving. Are they happy with the first solution that they found right? Are they Finding the problem ridiculous? You know, if you ask them the question, yeah, there's a very good book about this, called how to move Mount Fuji, and it's full of riddles, I believe. I believe it was written by some people from Microsoft town in 90s.
Lukasz:They were giving those riddles to people and asking them questions, like during interviews, like how many Christmas trees Is 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 celebratory you know it's a purely holiday thing or is it also a religion-driven? But does it mean that shops cannot have Christmas tree in in, you know, in their In, in, where they present their Inventory? What about public buildings? You know? What about schools? What about, and so on and so forth? Right? So if you come up with that, you can come up with some crazy number and 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 said, well, yeah, about 9 million. Okay, so let's assume Half. Or you know how? About gonna have a Christmas tree? Because they they follow the holiday slash Slush religious habit, right, and 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 it is also a sign of certain curiosity for for, yeah, for dwelling deeper and and growing as an individual. So that is, that is the. I still consider that a mix, but I would still lean towards saying this is more a technical part. On a on a soft skills part, I Like people who, on that, on their own, take Gallup test. There is a race now on On people coming in with CDs and they already have their Gallup test 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 shows me that they really, you know, want to grow all sense individual.
Lukasz:Second of all, in those interviews, if I'm present, I usually ask about value system For work. You know what does it mean to be committed? What doesn't mean to own Certain things in the team or or functionality wise in the project. What does it mean to be transparent? And how? What kind of feedback and how feedback should be structured?
Lukasz:Also, I asked about their past experiences. Have you provided feedback 360 or otherwise to your colleagues? And when you do, how do you do that? Do this right? And when you receive a negative feedback, what is your first reaction? Right? I'm checking for the self-reflection, right? This? Is it present? Right? And of course it's.
Lukasz:It's an artificial environment and the candidate is focused on, on answers. So they come prepared to do this kind of conversation as such, if they, you know, proceed and they're happy with what they heard and we are happy with what they said and any kind of setup that had been to in the past, and we vote them in as a team or as a committee. That that's, you know, 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 stay, they stay, they would stay with the organizations permanently when we, when we had an absolute certainty that they would not derail, you know, the team that they're working in from soft skill perspective, and then they wouldn't be dragged by, you know they wouldn't be slowing down the team in development because they will be dragging it down by not being able to deliver on topics.
Lukasz:Yeah, and of course, this is scaled up or down based on seniority and maturity of individuals. So I have slightly the team would have a slightly different expectations from a junior and senior, obviously Well, not slightly, actually quite quite some different expectations From from junior and senior in that matter.
Pedro:Yeah, I guess when hiring, one of the challenges is also to be able to identify how close to reality that that person, 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 you know 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 for you it's you know You're doing it in a, in a way that you consider Fine and you know direct, just direct, but polite, and the other person might feel attacked. And 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, you know, reflecting their, their, their own behavior or not right.
Lukasz:But there's also another side to it, because there's a lot of focus on people who Oversell themselves.
Lukasz:Right, they come across during the interview us really high skilled individuals and you know, high Expertise individuals, great self-skill and whatnot, and then only during the work they, they, you know, they come short of that and it turns out they're not who the team thought they are and it happens right.
Lukasz:But there's also another scenario, which I call the peril, the hidden jam or the hidden pearls scenario, when the individual is underselling themselves and I find it, I find it very interesting I don't know if it's a culture thing as well like I see people From Central Europe or trying that, you know, doing that a lot. I see people from Various countries in South America doing that a lot. I think this is, like, maybe different education systems impose different level of confidence in people when they, when they finish it, I don't know, I never, you know, really arrived at any decisive conclusion, but I see this a lot and in that case I I like to, you know, pull, pull the candidate a little bit towards my, my Narrative of like, hey, tell me, tell me the story about this work you've done here and see if there's Too much of humbleness, right? Because they say oh yeah, I solved this mathematical problem and.
Lukasz: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 did they, are they aware of this? Is this, is this real humbleness, right? And you, 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, you know, they don't have the the road, some code that they're not proud of, so they didn't commit it to. They didn't, you know, created a project in GitHub where I can actually check and verify it. But then they show me some code base which is really impressive, what they work on under spur time and and and you know, it's their, it's their pet project, it's their sidekicks out to say, even not for commercial use, but simply because they were interested in something I see a lot of people playing with, you know, a raspberry pi or a lot of other things, just to just to build a simple blink in light.
Lukasz:Of course, commercially doesn't make sense, because their time is worth so much more doing the job, but the curiosity again is a hidden gem, because there's. You know, not everyone has it. And if you want to have a really engineering team which can dwell on really hard problems, having people who demonstrate this kind of 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 but focus on the problem, not the technology, because it's cool, right, just to see how, how you would address it. That's, there's a thin line here between you know wearing your mask and being super humble, you know hidden genius, so to say, just unable to present yourself or oneself.
Lukasz:Yeah, 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 special, on a specific checklist of items that the candidate should have. But you know, 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 as senior, who was also not able to sell them properly and it turned out to be a genius, you know, turned out to be a really rock star and also amazing team player and eventually became a leader. So it's important to recognize that and, and, and you know, give credit where credit is due to these guys. Yeah.
Pedro: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 you know junior people tend to do when they are applying for a job that see more senior People usually don't do?
Lukasz: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. You know, it almost feels like a game and you're really grinding and trying to level up your CV so you can say you're a senior. So I've seen people who you know who had the first job when they were junior and that was for a year Maybe, maybe even less nine, ten months, and then right after this they started second job For a year, maybe, maybe 14 months, and they say they're regular. And then they started next job and they said, oh, now I'm senior Because it's my third job. So, technically, after 14 plus nine months, right, they are considering themselves senior simply because they really want that label, because, in their minds, positions them better on the market, potentially also financially. But to tell you the truth, I think I think some of the better ones in terms of maturity do understand that and they also understand that rushing this cuts their wings for some of the really most interesting projects and the best companies out there.
Lukasz:The market is currently in a you know slowdown, but I still think that in IT it's always gonna be, there's always gonna be a space for everyone, right? It's just a matter of how long, how much time someone invests in looking and what kind of work they're looking for always, even in the 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 the rapid, you know seniority growth I think there are there's a lot of examples I had a lot of examples of a burnout and be a massive disappointment because at the end they're not growing right. So it's 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 to that label, you know, are able to step down from the label measurement context contest and really consider what the best argument is? Are they able to put together that argument because of that rapid growth? You know, 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 that I have also seen. It's rare but it happens but at the same time to allow themselves a space for growth. And it's not a rat race. You know, at the end of a day, I think working on this collaboratively, on any project or any problem collaboratively is more beneficial for the outcome of this project but I think that's a good thing to do but also for the group of people and every of those individuals independently. So this is number one, rushing through with leveling up. Number two is a sense of the more the better. So, you know, let's reconsider the same candidate Across the three years, three projects, and they put 15 technologists.
Lukasz:And you know I'm an expert in just a few things, a couple of things even, and not few, and I know it takes a lot of time to build that expertise and to even stay current, because even in the 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, like you can't really work. I guess, most of the time there are circumstances, of course, but you got to be able to do that and there are two factors. But you got dotnet and you got Java and you got, I don't know, some sort of Python thing, and one is in Azure, another one is in AWS and another one is at Google, and all of that under one roof in one company in one year Unlikely, you know, like Unlikely, that they did that and they like, even if they did that and those were actually three different teams or three different products had a valuable learning experience there in that short period of time?
Lukasz: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 you know they crumble and they and they 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, like for our this and for our that, so it's even half time, right, for three months. You know like, how does that look like? And then a couple of deeper questions, especially when they say you know, you're, that's another thing, you know.
Lukasz:Third thing that I see to segue 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? So 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 and I would ask them to put together a nested query scenario for optimization, right? Because if someone says there are 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? And I really, really press on that. Because if someone is telling me they're experting this and everywhere else they put themselves for 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 right.
Lukasz:It's a little bit tough to do, really, because occasionally you get emotions in a candidate, which is not great, and this is not what we all want. But if someone is so overly confident, right, I want to see what's behind that. Is it really? And it turns out occasionally that I am proven wrong, right, like sorry, frequently, and the candidate is really an 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, like they build an image which is not true, and I see this a lot in people who consider them so seniors.
Pedro:He's like fake it till you make it.
Lukasz:Yeah, I think there is a certain level of bias to it, because if you are in a, let's say, five years and 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 and it's like you don't know what you don't know right. So I presume that in that knowledge space of their own joins and selects and inserts, they're really an expert. But they need to understand this is just scratching a surface of what the database can do for them. And 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, yeah, totally get it. So those are my top three picks.
Lukasz:I would say so I will be very careful with marking CVs and benchmarking oneself to any kind of scale, because it sends us. You know, there's no, 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. Say you're 10 out of 10 in SQL, even if I don't ask the nested question, ask what else is there to learn? Right, how current are you with the latest developments in different? You know database engines right.
Pedro:What, what the Cause a true expert will know what they don't know. Also, right Like, they'll know where is the bleeding edge, where is what direction is that technology growing? Where it's being applied?
Lukasz: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. And then even, point of time, they are expert in such a generic thing as SQL. So I'll give you an example. If you have different versions of Java, right, and someone writes there are Java expert Amazing, five out of five. But then in the last jobs they only worked with Java 8 and Java 14.
Lukasz:And as far as I'm concerned, I think we're on Java 21 right now, released until 21. 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 consider Java to be so, if you're considering yourself to be so strong with it, right, and this can be asked in any circumstances, in any versioning simply because all of this stuff is under development, undergoing development, and you know, just to allow yourself to think that you're an expert in function of time, yeah, yeah, and 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, right.
Pedro:Like I mean, the person might be interested in staying at a 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 being, you know, in having to deal with other leaders in other departments, stuff like that.
Lukasz:So on one hand, I would say that, as you grow, there are certain technologies or certain items on the CVE 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. Right, there's nuance, because maybe they come through 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 a 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 bottom up.
Lukasz:Whichever way, there's a thin line here between what I consider full stock, because people have their biases. So 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 CVE has to tell a consistent story about the individual, and this is the path of expertise, right, an expert.
Lukasz:And then there's this other part of your question where I felt you were asking more about do you wanna be more in a decision-making process and people interaction process where maybe you know you discuss the entire strategy. Maybe you can become a part of a hiring committee yourself, right, 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. So there's various things which then play with emotions, right Of the individual, but also on the people to interact with, and I think this is the entirely different game and I think this is the soft-skill game, as you mentioned.
Pedro:Yeah, exactly that's what I meant, that you know 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 backend engineer and then slowly going more towards these management positions, executive positions. For example, a CTO with the backend background, he won't be involved in the day-to-day operations technical side of things.
Pedro:As the very senior engineer is, he has to deal much more with the politics of the company or dealing with other departments. He has to be 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, you know, dealing with the computer and other technical-minded people all the time. Yeah, totally I agree. Yet they both have the same, let's say, amount of experience. Let's say they have a valuable experience that helps them 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.
Lukasz:I guess Totally, totally, yeah. 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 cutoff point, what is the progression from one to another? Or?
Pedro:No, it's just more of an observation that you, you, you can choose the where your career path takes you if you prefer to continue developing in terms of seniority but still remain focus in the that 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?
Lukasz:So, yeah, 100% will. You know 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 a given organization or team, because someone departs, someone joins you know there's some sort of split or you know 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're really liking it and they and it's a good opportunity for them.
Lukasz:Because, if I don't, I don't necessarily agree that Expertise path has to always transition into leadership path, I think. I think you know leadership should be more, 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. And and and experts tend to be these people. Right, 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 and segue into the solution rather than tell it right away, because you want the team to develop and dwell on the problem in and every individual in the team and the problem independently. And as long as it's a planned, planned path, that's wonderful. You know, if someone is dedicated and committed to become that leader or that expert or whichever path they decide to take, or even paralyze a little bit with product or a little bit of the design, whatever, whatever is, you know, into their liking and when they actually have a positive results, that's great.
Lukasz: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 Kind of temporary interim assumption Turns out to be permanent, you know, without a deadline moment where when they can struggle and or or they will make. You know they make it best they can. But you know, could also be a completely different experience with a lot of stress and learning new things with, with different kind of roles 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, like, because I feel that Organizations who say it's straight to the from the beginning, during the interview process that, look, clients are, where clients centric and you're gonna be having this exposure to our clients is is also attracting a proper, proper kind of character to this organization.
Lukasz:First, versus, you know, a transition where you have very With wrong, a group of people who who solves very complex mathematical problems and they generate, let's say it's, it's a quant project right for, for, for the traders desk right that is. That is entirely different to say that you, you would now put those guys on the trading floor and start talking to all of these traders right which which have a completely different level of communication. So 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 a career is and maybe what the end goal in your career is. So it's less of a I'm a leaf in a river from one bank to another, whatever, whatever happens, but more controlled and more designed career Development.
Pedro:Mm-hmm, yeah, and I guess that applies for all the stages, right, 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, I agree, and also having this helps you to make the right choices about kind of environments and organizations who want to work with.
Lukasz:You know, for people, for people who like it a little bit slower and stable, bigger companies you know corporates are better often someone who likes to constantly be challenged and changed their hat constantly, especially in the younger, 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 you know there's so many things to get your hands dirty with, to try and learn from totally Mm-hmm.
Pedro: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 a suggestions of some kind of book or some resources that has helped you or has helped other people around you? Right, I feel? I feel that going to meetups is of a great help, because I frequently had a vision of a role that I want to become.
Lukasz:And when I came close, or when I became that role and I got that role, I realize it's not what I imagine it's going to be. And if you go, if you go to conferences and meetups and you see people who are there, you know you're not going to be able to get that role. And I got that role, I realize it's not what I imagine it's going to be. And if you go, if you go to conferences and meetups and you see people who are there, you may realize, okay, this is, you know, 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.
Lukasz: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 engineering side, it was important to have a pet project, to have something which you're playing with in your free time. You know some.
Lukasz:There's nothing wrong about watching, you know some serious or playing some games, but at some point I felt, I felt the urge to be additionally creative and try things on site and maybe something even comes out of it. You know like you have your own spin off, or you have your own you know little product which 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. So there's, 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.
Pedro:Nice Thanks for listening. In this episode we discussed personal growth in the software development industry.
Lukasz:Stay tuned for the next episodes and connect with us on LinkedIn. The links are in the description.
Pedro:Feel free to drop a comment there with your feedback. We will really appreciate it. Thank you.
.png)
.png)