Q&A #5: How to be a Great Senior Software Engineer & More with Patrick Akil

Should I call this Ama's or Q A's? That's my life question because apparently a few people don't know what Ama's is. So I think I'm back to Q A's QA #5. Can't believe I made it to five already. We've got some great questions. Very specific, very topical. Today it's topical and English word. In any case, I'm rambling. Sit down, relax, get comfy. I got your questions with me and let's begin beyond coding. Big question, just started off.

I'm gonna paraphrase it. How do you manage your own high expectations? Sometimes I have the feeling of being left behind and not moving too fast, especially while looking at engineers, creators, and entrepreneurs on social media. Do you also have that or recognize that feeling? I recognize that feeling and more and more I try to let it go and not necessarily compare

myself to others. It's hard, I feel like because motivation for me also comes from comparison, but I feel like there's also a downside to that, that it might leave you unfulfilled or wanting too much in too short of an amount of time. To give you an example, I can compare myself to people that are of the same age or younger that I feel like have achieved more or are just in a better spot career wise or are where I want to be.

Maybe years down the line. But they've already made that right and because they're younger I feel like I'm missing out or I'm not moving too fast. But those people do not have the same experience as I have. If I want to get to that point, I feel like I should get to that point my way, right? And they don't have the same journey as me. They have their own journey. They got their their own way. They might not have had the same struggles or the same learnings

or the same choices. I feel like if I'm going to get there, it's going to be my way. And I feel like accepting that, that allows me to not feel like I'm being left behind because if it's my way then it's always going to be my way. So then I'm not really behind. I'm just on my own path with my own pace and I'll get there. That is something I'm I'm very stubborn in. I like goals, maybe not long term goals, but I'm very goal oriented.

If I have a vision to get somewhere and I fully believe, I usually have to fully believe. Otherwise I'll scratch the vision and I'll give it my all to get there and it then it doesn't really matter how long it takes. I feel like I'm a really good sprinter, and with this podcast apparently I can run marathons as well, so it doesn't really matter how fast it is then at the end of the day, I'll get there if I want to. I hope that answers the question. If it doesn't, reach out to me

and we'll have a chat. Now this is one I'm gonna have to think about. If you could change one thing

from the past five years of your career, what would that be and why now? This is a difficult one because I always say I like where I ended up. So then should I really change something? I think I can change something and it might completely change the outcome, but I have a hard time starting things. The reason I started this podcast is because I got help. Someone said I'll facilitate whatever you need and then I was like, yes, me pick me. Yes, then I can do it.

It's way easier to have help and to start doing things I've always gained a lot and I used to love. I still do watch a lot of YouTube, see people playing video games, having fun, interacting with each other. And I always thought about doing that, thought about getting my own recording stuff, getting a Blue Yeti microphone, playing some PlayStation and recording my stuff.

And I I mean, sometimes still think about that, But especially back then, when I was in high school, even I would think about that a lot. And I never did that because I would spin a car. I have to do this and I have to have this and I have to do this. And what if this and what if that and I never started. All those thoughts make me not

start things. I feel like I should start things sooner, maybe faster, but it's kind of a dilemma because I also like doing things to kind of the best of my abilities. So if I start more things, then I can't really uphold that quality that I want. So maybe that's why I don't start things. But I feel like some stuff I could have started earlier. I listen to a lot of podcasts, especially now that I know I really enjoy doing these

podcasts. I wish I would have started earlier and I would have been better, maybe faster. Hey, who cares? That's the end of the day. It didn't happen. I could have done it, and maybe I wish I did, or maybe I didn't wish at all. Other than that, there's probably one other thing that pops in my mind when it comes to career progression. A lot of my work, a lot of my progress has been kind of reactive progress, if that makes sense.

I feel like if I would have planned more what I really wanted to do, sit down and maybe write down those goals, I just don't really like doing that. But I feel like I could have done more with actively growing because especially already on I would come home and I wouldn't really work on anything. I wouldn't really work on self improvement or self development. I would just have my work life get better at what I think I

wanted to get better at at work. And then when I would get home, I wouldn't really do a lot of things. It's probably because what I was doing, especially early on in operations, wasn't really a true passion. Maybe even cuz nowadays when I go home I do a lot of stuff. I do a lot of extra stuff. It's because I love doing it probably, and maybe that was missing. So then the goal should have been finding something I can be truly passionate about and I could have spent maybe more

personal time on that. Maybe that's something I would have wanted to change. What is the best piece of advice

you've ever gotten? Best piece of advice I've ever gotten? It's hard to pick one I like, don't have any expectations, so you can't be disappointed. That's one that really stuck with me. Other one is if you want something done, pick up the phone and call someone. Nowadays some people don't answer and that is rude as hell. OK? But especially when I was in operations before joining operations, I hated phone calls. I don't like talking on the phone. I thought, don't like the sound

of people's voices on the phone. I I'll just text, I'll text and they do whatever they want, whenever they want. But yeah, in operations I really needed people and I would call them and they would answer and we would get stuff done basically. Or if I would need a piece of information, I could really dig down into the documentation and spend an hour and get it myself. Or I could do one phone call 2 minutes and I would get that information.

I got a lot of stuff done because of getting over my hurdle and just calling people. Don't know if that was a piece of advice or more so realization, oh, I saw someone do that and he would get stuff done a lot faster than anyone else. So yeah, I definitely adopted that behavior. I know judgments is a big one. Try not to judge people, try and understand where they're coming from sometimes. Try and hold your opinion to yourself and listen before speaking.

I feel like that's a big one in kind of reaching to a common ground or a common solution. It's a hard one, especially when you're strong headed and have opinions like I tend to be and have. But I do think it's valuable to put that aside more consciously and actively listen in that way.

Apparently, and I realized this more and more, this tech space or probably the space you're in is a lot smaller than you think it is. You will find people that you've worked with before, people know, people that you've worked with before. It's actually pretty tight knit kind of area. Your connections know each other's connections also, and a lot of people know each other, so don't burn any bridges. You've talked about transitioning from operations to software engineering before.

Why did you make that transition? This is an interesting one. Why did I do that? I thought it would be fun to be more so creating things rather than maintaining things that other people created. I feel like I did partly software engineering in uni. It was a lot of Python, some web development here and there. And I always liked programming because for me it was like problem solving. Maybe sometimes I didn't even know what I was writing, but if I have to write output, I solved

the problem. That was kind of my mindset back then and I enjoyed it. I enjoyed coming to the right outcome by programming. Then I went into operations and for me, operations was like, OK, super broad, I can go anywhere, I can learn a lot. That was kind of my mantra going in there and I felt like if someone fires me, I'll probably not mind that much and be happy and find someone something else.

That was the initial mindset. Now I really enjoyed my time there and at some point it was a bit more frustrating because I would see exactly kind of input output and I would see that with that input my output should not be this. And then I could even view some of the code and be like, OK, this should probably where it is. I don't think I ever was like here it is.

But I always had a hunch that it's probably around here somewhere, and the feeling of not how do you say that I was really unfulfilled or someone else would fix that and I would not know if my hunch was right, if I was actually in the right area where I went wrong. I like to be right, maybe, and I never knew that was gonna have a problem, and I felt like I liked operations, but I really wanted to be more so on the creative side and answer questions like why did we build this way the

way that we did? Could we have done it differently? What if I knew from operations a few things and I could implement it also while developing. So looking online I saw development and operations in DevOps coming together and I was like this is what I wanna do now. Also back then in operations I managed the tool which was a lot used by project managers. It was not JIRA, it was not anything Scrum related at all. It was like a very specific tool.

Yes, and the person that managed that tool was basically a program manager overseeing a lot of projects. Like when people needed a bigger budget than 100K, she would be in the steer committee that would grant that budget. And she was like the ecommerce side of things. It's kind of our department called Nextel. They're doing a lot of fun stuff. They're working with a lot of new technologies. They have a lot of smart people. You're very smart. You're working with outdated technologies.

You should go there. And I was like, maybe I should. So she was like, if you want, I can connect you with the director there and you can have a conversation and blah, blah, blah. And I did that. And for me, it's just a conversation to be like, okay, what are they doing, right? Because if someone so drastically says, these are where the smart people are and they're working with the latest technology, to me, I'm like, all right, let's see what they're up to.

Let's see what they're working on. I was curious. I'm always skeptical. So I had that conversation. And funny enough, just the week before I actually was gonna have that conversation, a huge kind of restructuring took place. And it was like, OK, these plans are not going to, we're not going to do anymore, this is going to go in the garbage. These things are going to get sold. People, actually, I mean, had worked there for a few years and we're really upset about that.

It was like my first six, 7-8 months there. And I was like, OK, things are changing. I don't really know how that impacts me. I feel like my experience was a bit too, too fresh and too new for that. But in any case, I had the conversation. He was like, well, I can't make any moves now, but there will come a point where people in operations need to go back to the different companies because I was in a holding company and I might be able to open up a

position then for you. So I'll keep you in mind. And I was like, I mean, I liked what they were doing, I liked the director a lot, like I had a good click with them. That's probably For me, choosing a position was like, one of the most important aspects was me liking who my manager was going to be, someone I could look up to, someone who I saw got shit done, basically. So with that in mind, I was like, OK, that's gonna be an option then it'll come when it

will come. And it came a few months later. From my position, the people in my team could apply to some of

the organizations that were gonna be standalone. It was said to us that you can apply to two positions, and it was not two positions separately at different organizations. Now one organization would have a few positions and another organization another few positions, and you could only pick two. So if you wanted two kind of same things, you could do different organizations or maybe two different things at the same organization.

I didn't like any of that. So I applied to like 5-5 positions and then I went on a holiday and I didn't pick up my phone. I always had separate personal phones, separate work phones. So I threw my work phone.

Someone in a corner, didn't look at it, got a bunch of calls, and apparently some people made the decision that I had picked too many, which I agree on, and they chose two that were more suitable to me. I even applied to some senior positions and they were like, there's no way he's going to get that. So they picked the more junior positions for me and even positions that were at different

organizations. So no, no, they were at the same organization, but they excluded some of the organizations where I like the people I wanted to talk to them. They didn't even put my application in there. I found that out later, and I pretty much pissed me off. And I told them something in the lines of you can't stop me from having conversations with people. And if they like me for the position, I will get the

position. I know it might be unfair, but yeah, I'm going to do something with my best interest and that is getting a position that is good for me and probably also good for the organization. Otherwise they wouldn't pick me. So yeah, it might have not been as fair, but I wanted the position I felt I deserved. So I talked to everyone.

And at the end of the day, that same director from the e-commerce side, he said, OK, this is the position, this is what you will do. We know you don't have any software engineer experience. You're gonna do XY&Z. And what's your salary now? Yeah, this is what Ioffer you. He was the only one that actually said to me, this is your salary. It was like a 3040% increase. And I was like, at least that's something unique, right? Someone that already can say this is what you're gonna do,

this is what you're gonna have. This is all the options, full transparency. And now make your decision. And I didn't have any of that with the other conversations. So then I was like, OK, this is the route I'm going to go. Funny enough, I joined. Then the ecommerce side of things, the person that was going to manage me was no longer with the company, got a new manager. He was just one week with the company after I joined. So he didn't really know what he has to expect either.

The person that was going to mentor me for what I was going to do was not there anymore. He was just there two or three times a week and he had to do his normal development as well as transferring all the knowledge to me. And within a few weeks I went to my manager. I was like, this is, this is no, no, I'm not learning anything. Like I don't know what I'm doing. I'm doing the operations side of ecommerce now. This wasn't the deal. I want more.

And then he finally put me in touch with the consultancy team that was there, which is coincidentally was from Cybia and he was like, Patrick's knew. Patrick needs to do everything that you guys can do. Basically teach him everything you can. And that's really where my kind of learning journey and software development career started.

It was very much I want to do this in the moment, reactive again, maybe going into the last question, but still I feel like it was the good choice for me. Probably if I didn't like it as much, I would have stuck with it. I feel like because I'm, I'm not someone that gives up early. And then I would have probably moved on to something adjacent in software engineering, because I feel like the history and operations I've always leveraged. I could do the same with software engineering.

I don't know if I'm going to be software engineer for in the future, like how long that's going to last. But I'll always take that experience with me and transition to something I think is interesting and a true passion. What languages are you currently

learning when it comes to programming languages? Zero. Actually, I'm not learning anything right now. I'm working a lot with Go. I dabbled a bit in Rust like an innovation day we had. It's kind of like a hackathon day, and Rust has a way too big of a learning curve. Things are way too complex. I didn't feel productive at all yet, so no, I'm not learning anything now. I wanna learn Spanish.

I've tried some Italian. I've always wanted to learn Japanese, but right now I'm not learning any programming languages or regular languages. Maybe I should start though.

Oh my goodness. Feel dehydrated? Yeah, When people say you'll learn this.

When people say you'll learn this on the job, I can't speak. When people say you'll learn this on the job, what are the realities and expectations of that situation? How much time is given to learn and are you expected to apply it right away when you're inside of work or even outside? That's a big one and I feel like it's very much context dependent when I say you'll learn these things on the job usually.

Mostly it's about the domain and I feel like that's more so because I'm in a consultancy where a certain set of like technical expertise is already required. If there's four things on a technical level that we need to know, you can learn one or two, but ideally you would bring a lot to the table already and then the domain that you're in, you can leverage your past experience. But usually it might be something new.

Like I've worked in more of the medical industry, I've worked a lot in e-commerce and right now I'm working in IoT domain and the domain have. The domains have always been kind of new and the technologies I've always leveraged or

sometimes learned on the job. I feel like if it's within a team and you have a safe environment to learn from others and you can do that, you have that curiosity and drive to learn fast to get up to speed within a few weeks, even spend some personal time on there because you want to be productive at the end of the day, then you can learn a lot on the job. But it very much depends on the

context of the situation. Mostly when people tell you from a team perspective this is what you'll learn on the job. That'll mostly be true, but for me, in the context I've been, it's been about the technical but way more on the domain side of things, I missed a little bit of it.

How much time is given and what is expected? Now? Those I can't answer. I feel like the biggest thing you can do, especially if you're new, is ask those questions. What is expected of me? How much time can I get from that to make sure it's clear for you, you don't want to commit to something you cannot do and you don't want to commit to something that is very much unreasonable. So you have to clear that up in

the air. And part of you clearing up those expectations also makes it clear for the other people, open cards on the table, be direct with each other. I mean, I can't really give that as advice because I'm a person that is direct, but I feel like as long as everyone is transparent, the expectations are clear and you can see if you

can do it or not. I would say you can spend personal time on it, but only if you're really passionate about it. I feel like passion will get you far, will take you to a place where you can spend your personal time on it. Otherwise you can do it, but it requires a lot of discipline. The best way is if you really enjoy what you're doing, you'll also enjoy in your personal time and you'll get better at your craft. Basically, is only writing in vanilla CSS instead of learning

Tailwind, Bootstrap, All the other stuff going to hold me back? If so, which one should I learn? I don't think it's going to hold you back. I think it's going to give you a foundation. And then the other, I would say extra steps, frameworks, conventions are gonna build on top of that.

I think vanilla CSS is always kind of at the foundation and you can do a lot with it. You can do almost everything with it. And that's also how I learned was CSS first, then we were using sauce, so I learned that then on for me learning was always project based, so it was OK. On this project we're using Tachyons, which is kind of like kind of like Tailwind. Then I tried to and at like an innovation day, like a hackathon day, and I joined a project where it was a lot of.

Vanilla JavaScript and we didn't have any CSS. We used BOMA as a framework so it was already predefined classes which we used. I feel like as long as you understand CSS you can make a lot of the tools work. If your project has those tools then it might help to do that on the job, off the job before you get the job. But it really depends on the project. A lot of people I've met learn out of interest, they're like hot tailwind is a thing. I've never worked with it, Let

me see if I can apply it right. They take an existing project, they rework it part of the components with tailwind and they form an opinion about it. They will always say it's a brief first impression, very brief opinion as well. And at least they then have kind of an experience with it. You don't have to master all the tools. You can form an opinion and then still be like this was my

initial thought. I would love to learn more in an actual conversation on a project or with a colleague, Something like that. I think that would be my advice. Like all the vanilla stuff is always the foundation the framework's built on top of that, so understanding the fundamentals, it's also going to allow you to use the framework more aptly and understand what's happening under the hood. I don't know how to answer this. How many projects should My

Portfolio include and what concepts should I incorporate in them when applying to junior front end roles? Yeah, that's the hard part. I don't have a portfolio so it's hard for me to judge. I feel like I've always kind of used my network or got lucky enough. Let me just let me just put luck there to land the job without having to have a portfolio. I think being good at communication really helps with that.

But if it's hard to get the first conversation then I get that having a portfolio really helps for me. What I would want to see in there is a certain amount of passion that someone has. I don't just want to see a portfolio with a bunch of stuff that anyone that can follow a tutorial can do. What interests you and what can you build with that? For example, I've seen someone create like a website with a lot of Pokémon stuff.

I thought that was cool and they chose a framework which they had never worked with before, something like that to show them they can learn something as well. Otherwise, portfolio wise, junior front end wise, I don't really require someone to work with every framework that is out there and for me, honestly, what you bring to the table beforehand is not going to matter as much as the conversation. I can hire someone without a portfolio versus someone with a portfolio based on the initial

interview I have with someone. And the interview is going to be sure a bit more about the technical side of things. But I'm also going to ask questions that are going to give me or help me form an opinion about how someone thinks. If I want to work with them, genuinely want to collaborate with them, want to have them in my team if they are someone I would trust and can rely upon. Because if I trust someone I'm going to trust them the 400% from the get go.

If that is not there within the conversation then it's a hard fit for the team that might not say anything about the person, could say something about the team as well. So then it's just not a good match. Technical expertise wise, there is a baseline and a portfolio can help you show that. What usually with conversations I can already find out what someone knows or what someone doesn't know based on what they're talking about.

Basically based on what they focus on when they're communicating and based on what they say their impact was on previous projects. If you don't have any previous experience, then yeah, I do get how a portfolio might help. But again, find something that aligns with your passion. Try and build something in a web app or an application online, a web app or a mobile app, I guess to show that passion as well as kind of your technical skill set in that way.

Ask for feedback. I think that's a big one, but I look for someone is someone that is curious, someone that is driven and eager to learn. I think that's the biggest factor. If you're a sponge and you're eager to learn, you want feedback, then I'm like, OK, this person is going to grow real fast and he can grow the right direction because we can teach him, basically, and that might be a good ad for the team then as well. If people teach, they also get better, so it's a good ad for

the team. I hope that kind of answers the question again. If it doesn't hit me up and we'll have a conversation, how important is it that a software

or software as a service startup in its initial stages has in house developers versus outsourcing developers to build your MVP? Very interesting one and I've never had a SaaS company. I've never had a company, so take this with a grain of salt. I'm on a lot of subreddits though, so you definitely have an opinion on there. I feel like you definitely need a technical cofounder. For me to imagine being a cofounder or being a founder without having any technical knowledge.

You're giving away all of your trust, basically, and if someone does not have any skin in the game in the form of being a technical cofounder or having any stock for that matter, it's really hard for them to deliver what you want. They don't have any skin in the game. They'll just do what you say and if you're not saying the right thing, it's going to be a mistake.

At the end of the day, someone that is a technical cofounder can challenge people, can make sure the quality of the product is high, can make sure you focus on the right things. Also low hanging fruit, getting out the MVP faster, not over developing or over focusing on quality, really getting feedback as fast as possible. Because if you're in an MVP

stage, that is what you want. I think when once you have customer validation, right, product, market fit, that's when you have to build something that is gonna then scale for the people that you imagine it can be for the initial phase. I would probably, I mean, since I am a technical person, I would build it myself or I would find a technical cofounder and build

it together with them. If they think it needs a bigger team, you might be overdoing it. Because if you're reworking on MVP for market validation, at the end of the day you can throw that in the trash and you can do that again. If you really want to build something complex and you want your MVP to also then completely scale to the masses that you expect it to be, then it might help to go to a consultancy

company and help them. No have them help you out with kind of the initial phases, right? They can put out 7080% of the architecture for it to scale to what you've imagined. Again, only when you have kind of part of market fit and you want to be through this, it's been validated and then you can take it from them and build it

out with an internal team. I feel like that's where a consultancy and an internal team can kind of go hand in hand because they can help you and they can challenge you on doing the right things. But at the end of the day, consultants are expensive. Implementing is cheaper if you can do it in house, if you can find the people. And I feel like if you are adding value, I would always give out and allow people to have skin in the game because then they're really going to care.

So let's say your team also asking in the game, then you can form a team around this and build it in house. That is what I believe. Again, I haven't done it myself, but that is kind of the track I would go and I would always give out a stock. I feel like maybe I've listened. I've listened to the show with Kevin Hart and Mark Cuban and they also talked about that and I agree. So that's where it's coming from. That's why I say give out stock. OK, Yeah.

What are the trades that differentiate good developers

versus great developers? Senior level or not doesn't really matter. I feel like that's a hard one for the people that I've worked with that are really senior that I think are great. They get a lot of stuff done. They challenge the business in where they think the value is. They really try and understand the domain.

They don't just wanna, how do you say that When they speak, they use the terminology consciously and if there's a mismatch in the language, they focus on that mismatch and say what is it? Basically, they really want to understand the domain that they operate in because then the product at the end of the day is going to match the domain that you're in. And maybe it's because I'm in IoT. But when we say device versus unit versus digital twin, what do we mean with that?

And let's understand each other, write it down and speak the same language. I've seen senior developers, really great developers, refocus on that. And then it really depends on the type of developer as well as the project phase. Because for me, great developers in an early phase can make decisions real quick because their throughput and their output is just insanely fast.

If we have to pick a database solution, we have some non functional requirements which means we only have a few options from those few options. Past experience plus research out there, not even that much research shows this is the best option or these are the two best options. We pick one which we think is the best option. We don't do too much research, we don't go analysis paralysis.

We pick, we go, we iterate. If it doesn't work we pivot and we pick the other one and they're fast enough to make the decisions quickly to really focus on the decisions that matter and yeah, the throughput is just insane. I think that your pinpoint in a conversation with someone if they can do that, if they have done that, if they're not afraid to make those decisions because they know they can pivot at any

moment. For me truly that makes a great developer that is at the early stage of a project once things are a bit more established again. Also they focus on conventions, making sure that people other people are unblocked and making the team more efficient. But once that is established, they more and more focus on other people, making sure that everyone is more effective. Because then there's this kind of multiplier within the team,

right? They can focus on communication, making sure requirements are aligned. They can basically go in and out of different roles, whether it's product owner, Scrum master, software engineer and make sure that the whole operation, the whole delivery of the project is more smooth than it would be without them. For me that makes a great engineer, makes a great team player even, because they can be more than an engineer.

I feel like if I can give them kind of the product owner title, they would still make sure the outcome would be great. It's because they're a great team player, they're a great product developer. I don't know how to phrase it, but I want them in my team and I want them next to me so I can learn from them. Those are the people I'm talking about. Yeah. And they're going to rat. I hope not just a little.

Is it a little? If if I'm out of breath, does that mean it's a rat that that that confirms, That confirms, Yeah, I think so. I just have a few questions with regards to hiring and I I already touched on hiring actually. If you were a hiring manager, how would you conduct the interview of a junior front end

role for example, What questions would you ask and what kind of tests would you administer when it comes to a junior front end role? What would I ask questions like what would I do? Let's say what would I do? I would probably find a problem space that I think would be doable. I would want to do that together with them. Now I know it's confronting and some pair programming sessions can be really disheartening to a lot of people. But for me that's the quickest

insight into how someone thinks. And I hope this is my hope that I can make someone comfortable enough to have that collaborative session that is also contributing. Because I feel like if there's any reason why it's going to be no, I can give the feedback then more direct, maybe direct is the

wrong word, more honest. At least I have a better place to give feedback because I've actually seen the more hands on things I can give feedback that is going to help them also in next interviews and it's just going to give me better insight. Basically the insight that I need to see if we're going to hire this person or not. When it comes to the questions I might ask for certain decisions on tooling or on what they would

use. Not necessarily because I'm interested technical wise, but I want to know if they have an opinion that is not just from a book, if they genuinely care and have an opinion on something. Because I want to talk to them about that opinion. I want to have a discussion, I want to see how they interact, how they communicate. I feel like that's very important.

And also if they're open and willing to learn if they don't, just read a book and say this is how it is, but say this is one of the options and I'm willing to learn many options and I want to know all the options and I want to know how to use those options aptly when I'm on the job.

I feel like people that are eager, people that are curious and people that can make this their passion doesn't have to be it from the start, but people that are just eager and hungry to learn, Those are the best people, those are the best people. And usually that's what junior developers bring to the table in my experience. And having that also can strengthen the team. Because then the team is going to be challenged, really

challenged on its decisions. And things that might just stride and glide all of a sudden have to be more so explained, have to be defined, have to be really thought over. Because someone is going to challenge them and be like, why are we doing this? And the genuine how you say that, the genuineness of that question, the honesty and the openness I feel like is going to contribute to the team as a whole because people are going to be like, OK, why do we do

that? Have to really form their own opinion or understanding first before you can teach it to someone else, before you can explain it to someone else? And then the shared understanding, this kind of shared mental model of the team, for me, it's just going to be more robust, more hardened. And for me, that is also what I expect of people that have not had as much experience. Questions hungry, learn eager stuff like that. Can you share any tips for hiring senior developers?

Any tips for hiring senior developers for me, again, senior developers can do a whole slew of things, so for tips on that, I would really just have a conversation about their first of all previous work experience. I want to understand how they communicate, what impact they had.

I want to talk about them in a case where if they weren't there, what would have happened If they allocate a lot of value to themselves, I want to see if it's their ego or if they genuinely can have this kind of argument. I don't have to convince me, I guess, but I I just want to hear their arguments towards that. What if I took them out of the out of the project? What would have happened then?

If they would say that they would have the trust in the team for example to have everything running smoothly because they basically help them with that or help them with a lot of factors. I feel like I would have more faith in someone that is honest and also self reflective in that way than I would have otherwise. I probably would want still to have kind of a pair programming

session with them. I would expect them to be more comfortable with that if they're not comfortable with pair programming and their senior developer. For me that is a bit of a red flag because what what does that mean? Then you don't wanna your stuff to hide or you don't do that with other people. How do you create this kind of shared mental model or how do you learn from each other if you're not open and willing to

pair? So for me, that would definitely be a must and I would want to do that with them. Then in there I would just challenge more so the decisions not to challenge whatever they're doing or everything that they're doing, but I want to know and understand what they're thinking. I want to see if they can explain it to me, for it for me to make sense. It can be something I know about. It can be something I play dumb about and know a lot about.

But I want them to. I have the opportunity to explain things to me, to also be able to dumb it down because I want to see how they can breakdown complex problems and communicate it in a simple way. And I'm realizing that a lot of it is on more so communication rather than technical expertise. But yeah, probably the exercise we would do, I would kind of tailor it skill wise to something that I would expect a senior engineer to kind of do on a more easier basis.

I feel like I would try and talk about also the architecture of things, give them a few nonfunctional requirements and then see what they draw up on or what they would implement on a more architectural level. I feel like software architects or software developers also need some architectural knowledge. If they don't have that, that's fine. I would still want to have that conversation with them based on what they've used in the past, based on what they think.

Also because for them, I feel like it's probably going to be something they want to learn then if that's what's expected of them. So yeah, I feel like I just said a whole lot and I hope it's helpful, but it is a whole lot. I feel like senior software engineers, really great senior engineers, a lot of there's a lot of expectations on them, at least the senior engineers that I've worked with. I've also worked with people that have been labeled senior

engineers. Oh yeah, there's different levels I feel like to this game as well. What interview questions would you ask to people that you're

hiring now? The funny thing is some or actually almost all of the interview questions I have asked and ask. I don't interview a lot anymore, but I did in the past would be also what I ask when I'm interviewing, because it's more so about people's experiences and people's journeys. So let's move away from more the technical side. I wanna know what people are proud of. For example, in the last few years, in the last two projects, maybe in the last project, what

were you most proud of? Because that I feel like, makes people more at ease, makes people open up more. And I wanna know why that is something they're proud of because that tells me something about the person, right? The person that's sitting in front of me, the way their mind operates, what they truly value, who they are as a person. I feel like those questions kind of allow me to get a better

insight in that. I've heard people talk about the fulfillment they got when people used it, when other people used it finally, and they said finally because they've been working on projects and those projects never went live, for example. Then I really know that is it is really important for this person to work on something that they think is fulfilling because that's why they hoped from project to project, right? And I can see if my project

currently is a good fit. Otherwise, I talked to people and they said when they've really solved a certain technical problem, that's something they really felt fulfillment in. And then I have to see, OK, do we have these technical challenges, right? Otherwise this person's going to be unfulfilled.

When I'm I'm, I want them in my team or when I'm hiring, I do the same on the opposite side because that gives me an idea of who I'm working with, the type of people, either my manager or my direct colleagues, who they are as people. And it's mostly what they're proud of, what they would do different, how they've moved from career to from position to position, how they did that, even what their thoughts are. And I feel like also I want people to understand what

organization they're going into. So I want them to be aware of what type of organization do you want to work with? Is it a consultancy, an agency? Is it more a product company? And why? Right. Do you understand the differences? And do you understand why you're choosing for this one? For example, in what type of size of company do you work with? Have you worked with different size of companies, right. Can you understand the differences? Is this a conscious choice for

me? I need to distinguish all the known facts that someone already has, kind of the biases I have to remove and then see if it's a good fit for the organization, for the team that I'm in. And I feel like those those questions at least help me give an idea on first of all, how some how, how prepared someone is, if they've actually given this a thought, if it's a conscious thing they're doing or this is just one of the options they have and they're kind of

buckshotting different applications in that way sometimes. I've had people that have not been proud of a lot of things that would just be like, that's a good question. I'll I'll get back to that later. Like I would really ask and really felt like I was like putting this conversation on my back and really like putting a lot of effort into it and I wasn't really feeling it from the other side yet.

Then it's a quick note, but for the conversation where it really flows, where I can find someone that is truly passionate, that is eager, then usually yeah, I would want to work with that people. I trust that person, basically. And that is like a base level of requirement that you need to have for a team and someone and a colleague. So yeah, that's what I focus on, on hiring questions that are like in that region, talking about questions.

If you have any questions and you want me to answer them next time, leave them in the comment section below. Otherwise, I'll throw up a post again on LinkedIn. I'll reach out to some people personally, or I'll throw up a poll and a post on YouTube so you can put in your questions there. For the next one, it's going to be in 2 1/2 months, so that should be like the end of the year, actually. Man, stuff moves fast. But yeah, this was Q&A #5 episode 120.

We're getting up there. So thank you for listening. We'll see you on the next one.