Do These Engineers Pass The Vibe Check?

Transcript is auto-generated and may contain errors.

Hey folks, I'm just driving to the office on Tuesday. We're going to talk about vibes. And no, it's actually not vibe coding this time. We're going to be talking about a experienced devs subreddit question. And this person was essentially asking uh do you hire engineers that don't pass your vibe check? Which sounds kind of funny, but I think I understand what they're saying. So they say they go on to say, you know, if someone is a dick, but they're they seem like a smart engineer, do you hire them still? Or like, how do you approach that? So, uh, I did a quick scan through the comments. Feel like I wasn't disappointed. Good job, Reddit. Reddit's usually pretty disappointing overall. Um, I don't know. Just not a place I love to be, but I think they got good topics. So, um I think there was some good uh or things.

I don't know. I'm calling them good just cuz there are similar opinions to mine, but I think there was some uh some good takes that I was happy to see and uh some things that I hadn't really thought about that are worth uh like I also agree with them, but it did wasn't the first thing that came to mind. So, figured this would be good to talk about. just did the live stream last night around um like from my perspective like things that I have found as a interviewer things that I like to do in interviews to help uh to make sure that I'm giving people a good opportunity to showcase themselves that kind of thing because those are from my own lived experiences where I was on the other end and I'm like I don't I don't want to do this to other people andor like I had a good experience experience and I'm like I want to emulate that for others.

So that's what the live stream was on uh last night at Devleer podcast. It's also on uh it's not on Spotify. Uh the podcast itself is the live streams or not, but uh you can check that out every Monday at 7:00 p.m. Pacific on YouTube at the Devleer podcast. And so I saw this topic on experienced devs and I was like, "Hey, I think this is feels pretty pretty relevant." We were just talking about this stuff. So, I think some of the top comments I saw were basically people saying like, "Hell no." Um, and I I definitely agree with that. Uh, if you're especially if you're more early in career or you haven't really thought about um Come on, guys. These guys are crossing the road at the slowest speed I've ever seen in my life. Yes. Take your time, sir. My god. He's like, "Watch the light turn green." and started walking across the road like no you you stop.

Um if you're newer in career or even if you've you know been in software engineering for a while but you haven't really thought about like hiring and what that looks like or um you haven't really thought about team composition and how to kind of bring engineers together to work through problems. I feel like this is an easy one to to not realize. So, you know, I don't uh for me, like I'm like, "Oh, this is so obvious. Like, this is exactly how I think, but if you haven't really uh gone through this kind of exercise before, it might not be obvious, and you might very well have a very different opinion, which is totally fine. But um it's not uh like if you were to think about building a team of software engineers, you know, on paper probably what you would want is you're like, "Okay, well, how do I find the smartest people that are the best at like, you know, the specific areas of code that we need to work in, right?

So, I'm just going to make this up like who's the the best C developer that like they write the best code we've ever seen in C# and who's got the best like SQL skills and we'll bring them in and like who's got the best like distributed system knowledge and like we'll bring them in and you build like this this powerhouse team of like the people that are technically the absolute best in every area and like that's the the metric that you look at, right? Because on paper you have this stacked team of like you know the most experienced best engineers in the world. I don't know who these people would be right but on paper that's what an amazing team would look like. The best the most skilled most effective team but in reality that's like pretty far from the truth. And it's because there's a lot of other things that go into building effective teams other than just like uh a highly technical skill set.

Now, don't get me wrong, it's not like I'm not saying like technical skills mean nothing, but like technical skills are also things that you can learn. Um, and they take time to learn, but if you're working in a space where you have to be practicing them, it's constant practice. It's constant learning. So, there's lots of opportunities to learn technical things and you will across your entire career go learn lots and lots of different technical things, right? It only takes you switching a domain or you know working in front end going to backend switching programming languages to basically put yourself in a situation where you're a complete newbie which is totally fine and then you know you you have all these previous experiences that you can kind of use to build on top of and you're like okay well this programming language is actually quite similar

to this other one you know so your ramp up speed each time is much much faster but you every time you switch into something completely new you're starting as a beginner, that's fine. You will be doing that tons in your career. So, if we think about team composition, it's not just who's got the best skills, right? It's not who has the most lived experiences in these things. Just to be able to count them and check a box and say like, you know, this person has more than this person, therefore they're better. Um, there's actually a lot that goes into like trying to make a team be effective. And when I was kind of going through that contrived example, like I didn't mention anything about how people work together. And in my opinion, that's one of the most important parts when you're putting teams together. So, couple things, right?

Like one, you actually don't want a team of like just the most experienced engineers ever. And the reason you don't want that is I mean there's a bunch of reasons but one of the reasons is like the type of work that needs to get done in a team is not all uniformly the most interesting most engaging work that requires the most senior engineers with the most experience the best in the world. And like that kind of stuff over time is like very disengaging because you're like why do we have to go work on this stuff? And that doesn't mean that you're like like that doesn't mean I'm suggesting therefore we just give all the crappy work to to the junior people. No, there's like there's a spectrum to this. And um having more junior people that can work on smaller things that are more well understood.

They might seem like they're uh you know monotonous work or it's boring to someone who's got a lot more experience. That kind of work can actually be very interesting and engaging for someone who is more junior and it's a really good opportunity for them to build momentum and confidence and getting building up their independence as a team member all these things. So having a spectrum of uh of work experience in terms of like you know literally like how much experience you have as a software developer is like extremely important. Um skill set variation is going to be extremely important. Again, it's like even if uh you're a team of C developers, I say C a lot, by the way, because that's like basically what I've been programming in for forever. Um but like you know, you're building C applications. You don't just want to say cool like just only give me people that are like complete experts in C.

It's like sure having you know a lot of skill in C is going to be helpful don't get me wrong but like what about the other technical areas you want to make sure that you can in in many cases you'll dep prioritize C experience because someone will come with something else and you try to create this diverse set of skills and experiences so that your team is wellrounded like that's the thing that gets missed it's not like I don't play sports video games but when I was growing up. I had a friend, one of my best friends growing up. Actually, he's been like a successful musician and stuff, which is super cool for him cuz it's like a pretty rare thing, I think, but he's gone like touring around the world and stuff. Um, when we were growing up, he loved like uh like NBA games or like NFL games.

Uh, I don't know. Don't think he played much NHL for for video games, but not for me at all. Right. But he loved that kind of thing. And like the reality is like if you could just make a team like a custom team and you could pick all of the, you know, you go build a custom player and you can just max out all of their stats, then like yes, when you play the video game, you will have the best team. It will and if you go simulating stuff, it will be impossible to beat because statistically you have all of the absolute best things. But like that's just not this is not how life works. It's not how actual teams work in reality because and I don't know anything about sports to be able to comment further on that. So that's where that example and analogy ends.

But when you're building software engineering teams, it's like you you don't just get to max out all the sliders on people uh on their technical skills and say therefore, you know, therefore we're going to have the best team or a cohesive team. It just doesn't work that way. In fact, because you cannot max all of the sliders, uh, especially just on technical skills. We're not even yet talking about the soft skills and stuff, but like even on the technical skills, you can't max them all out. So, like having coverage over the important areas is going to be the most important thing that you can focus on. So, you want breadth of skill, you want breadth of experience. Uh there's a lot to say, people get, you know, up in arms about this, but there's a lot to say about diversity in terms of backgrounds and stuff like that as well.

Um I'm not going to get into the details of that because people will go off the rails in the comments, but truly having different backgrounds can bring a lot of different perspective. Okay, so that's we're just talking about the technical stuff right now. So that's like when we're thinking about building teams, even on the technical side, that's a huge component. Now you bring in the other part like so back to this Reddit post where they're talking about like, okay, so well Nick, like I was able to find someone that maxes out the sliders on the technical. Like you you said it's not possible. We found the the guy or the gal that does it. Like cool. Like that means we should hire them, right? because basically they're breaking your rule and like they are you know technically perfect.

Okay, slow down cowboy because the the reality is like that's not the the most in my opinion the most important part because if that person is a dick, if they're hard to work with, they will bring down the entire rest of the team. And this is why I was saying a little bit earlier when I started this, like if you have not been in the industry for a little bit or experienced this, then it's it's less obvious. If you have experienced this as a as a team member or as someone who's uh, you know, managed teams and you've had this kind of thing come up within a team. When you have someone that's difficult to work with and they don't, you know, they basically bottleneck the entire team, toxic team members will literally, you've probably heard of people being called multipliers where they bring people up around them.

It's almost like toxic people are a zero multiplier. It's not even like, oh, it reduces the team effectiveness. Like, it does, but almost nearly to zero over time. Like, it's crazy impactful. And toxicity spreads and when you don't do something about it, you're actually like you're in a if you're in a manager position, if you're not doing something about addressing toxic culture, you're essentially allowing it to continue to propagate because it will. You demonstrate to people that that's an acceptable type of thing to do. And especially if that person is technically competent, they end up delivering good work, but no one else can get anything done or no one else feels comfortable speaking up. If you start rewarding that person for their deliveries and not addressing all of the shitty stuff they do, you are literally showing people on the team this is this is the expected behavior.

You might not realize that, but people will emulate things, right? This is why we have junior engineers that look up to the seniors and beyond because it's like they're going hey that person's been successful so far in their career like wow like let me let me do the things they're doing I should model that behavior even people do this subconsciously it's not like necessarily you sit there and you're making a list of all the awesome things that people do and you're like therefore I have to go do that some people will consciously go try to do this but like we will pick up on these habits and traits and things that people are doing and especially so if you're rewarding that behavior because now you as someone in a position of leadership is like is highlighting that, right?

So you have to be very careful about this kind of stuff because you bring in a bad apple that's going to have a negative effect on your team and then you don't do something about it and then that that sort of toxic behavior spreads. And if you've heard me talk about Whoa. What's going on here? I hit the I moved my phone and I hit the max button for my air. Like max heat blasting in the summer or we're in we're still in the summer. It's not the fall yet. Um what was I saying before? I got totally distracted by that toxic culture propagation. Um, I feel I was on a roll. I had something else I wanted to say. Sorry about that. Um, you need to address it. If you don't, this is the hard part about doing vlogs, right? Because when you mess up, I can't just be like, video editor, do something about that cuz I was being stupid.

You get the uh the real thing. So yeah, you end up supporting this type of um behavior and it gets emulated and then it's a really big problem to go solve. Oh, culture. That's right. Here we are. So when I talk about culture on teams, I say that like you don't get to say what the team culture is. You don't get to like write down on paper and say team culture is X and then all of a sudden the team culture becomes X. The team's culture is very much something that is an observed side effect. Okay. So you the culture is like the summation of the things that happen regularly with the team, right? How is the team behaving? How is it working? Like what are the team's values? Like all these things like you measure that or observe it and that is the culture. It's not the other way.

you don't write it down and then all of a sudden that's magically what the team culture is. But that means that we have to do lots of things along the way constantly to try steering the culture or like steering how the team operates and how they integrate and work together in a direction that gives us a team culture that we're that we're happy with, what they were proud of, that's effective. So again, bringing on someone who's a total dick or is impossible to work with, you are steering the culture dramatically in a direction that you do not want. And then by allowing it to continue, you're sort of continuing to allow this culture to move in a direction that you do not want. Let's go, folks. Why are we going below the speed limit in the fast lane of all the places?

So yeah, I think that I mean maybe this topic was obvious for some people, but I thought it was good to talk through because like I certainly, you know, when I focus on behavioral interview questions and like how I'm talking to someone, it's not it's I thought it was framed kind of funny in the in the Reddit post, it's like pass the vibe check. It's not like like what what is the vibe check, right? These are things that when you're talking through someone's uh experiences and behavioral interviews trying to understand like you know if you're going through scenarios where there was conflict and all they're doing is blaming other people like there's some things that are are pretty obvious red flags where you're like okay you're telling me that anytime there's ever been a problem ever in your career it just so happens that it's everyone else's fault and you were perfect right?

like there's no lessons ever learned. The lesson learned is that you're the the best person in the world. Like no. So, um you try to use behavioral interview questions to uh not just focus on that. Like there's other reasons you go through behavioral interview questions to see how people think through uh like you know project retrospectives or other things. But when you're asking questions about conflict or how you mentor people or like what it's like to work on teams with them, like you start diving into these aspects, you can start to uncover if there's like and like you'll hear about how people talk about others, this kind of thing. It's not a perfect, this is maybe why they're calling it like a vibe check. It's not a perfect science, right, where you can just like give someone a score like, well, you scored 78.2 two out of 100 on the vibe check.

So like therefore we're going to move forward with you. But if you're noticing some red flags with how people are um like how they've affect like worked with other people historically, I would um I would take that pretty seriously because that's their opportunity to be putting their best foot forward. Now, if someone was like, "Hey, at this point in my career, I'm just going to give you a madeup example like, yeah, I was actually like, you know, I had a hard time working with others. I actually got feedback on this. I didn't realize there were certain things I was doing. I learned a lot from that. Here's how I transformed how I work with others." Like, that's actually a super awesome like thing to in my opinion to bring up in like a in an interview because we're not perfect. Our careers and our lives are full of lessons, right?

I don't I'm not interviewing people and I'm like this person better literally be the most perfect human being ever. I care about things like what are you learning? How are you working with other people? Like all all these things because that's what I hope that you're going to be doing when you're working with us. So no, I will not hire dicks. Um, I would much like some of the comments were saying I would much rather hire engineers that are that are good, right? Like obviously if they're great and their soft skills and how they work with other people are great. Like hell yeah. But I would much rather take someone that is like I want to work with the team. I'm excited to learn. I'm excited to work with others. I really enjoy collaborating with others. I like solving hard problems and you know all this kind of stuff.

Like I would rather prioritize that over like the ultimate number one skill set in the universe. Like and that's fine because that means if I have a team that's well-rounded, they can get help from other people. I can coach them on things they might need some help with technically and they'll pick that stuff up. I was saying on the live stream last night that um when it comes to behaviors and stuff like technical skills take time and you have to work on them, you have to practice them. But that's the kind of thing that I feel a lot more confident that like people that put the time and effort into those things can learn and will get better. And when it comes to changing behavior, it's not that it can't change, it's just it's a lot more work. It's significantly more work, right? Cuz some of this stuff might be tied to like how people's personalities are.

like there's a lot of things that are sort of ingrained that um I don't know like if you've tried to if you're trying to work with people that have some you know some challenging personalities it's not like you just tell them like hey man like have you ever tried like not being an and they're like oh perfect yeah thank you and then it's just all better. It doesn't work like that. So like you need to find ways where you can like get on the same page as them understand where they're coming from. understand how they're making other people feel and like work at this thing. And some people will be like, "Look, man, like maybe it's not a good environment for me and they'll go somewhere else." And sometimes that's the best thing that can happen. I've literally worked with engineers and I mean this respectfully, they were they were a pain in the ass.

It was difficult when they were working with team members. Some I'm not even saying people on my teams necessarily. I mean like worked with engineers on different teams where they were very problematic and uh you know either they leave whatever happens but they're no longer at the company and they go somewhere else and they're flourishing right they're they end up being in an environment where like things just work really well for them that way. Maybe it's because they're working with other colleagues that do something similar. Their personality type is matched. I don't know. But it's like you you relocate the person, they're transplanted into a different environment and all of a sudden it works really well, right? So like it sounds kind of funny, but you know, just if someone's not a good fit because they're a dick, sometimes the best spot is like not at your company.

And it doesn't mean because they're always going to be terrible and no one's ever going to like working with them. It just might not be a good culture fit. and working somewhere else with different team members like their their personality type might actually like fit in really well with that. For what it's worth, I have been doing this my whole life, but for the past, you know, 13 years or so, um I've seen this happen like on more than one occasion, so it's a thing. But yeah, um, someone else, just because I'm getting close to work, someone else said something in the comments that I thought was really good and especially because this might be more applicable for for folks because I assume most people listening to this content are not necessarily like engineering managers and that kind of stuff. But, um, one of the things I thought was really good that someone said was like, I do this the other way.

and they said, "If I'm interviewing somewhere and I get the feeling that like the person I'm interviewing with is a dick, they're like then I'm not interested, right?" Which is hard, especially right now. I understand that things are very difficult for people looking for work. Totally get it. But, uh, it was really interesting to hear this person kind of still making a stand for it and saying like, "Look, like I might need a job, but like if I take this, I get the feeling that this person's going to be a complete to work for or work with, depending on who's interviewing and stuff, that might tell you something about the culture." Right now, this person didn't get into the details about how they gauge that when they're in the interview. Uh, but I thought it was a good reminder for folks like look, you know, like it does work both ways.

So, something to think about when you're interviewing, you know, when people people will say like, "Hey, do you have any questions for me?" Like at the end of the interview and stuff, like if you're if you're the kind of person who's like, "I never have questions." um some things that you might want to consider or like how could you how could you tease this kind of information out of someone, right? Like trying to understand what the team culture is like, these kinds of things. Trying to understand that more effectively can give you a better view for like you're about to if you're accepted into that, right? You get an offer. Is that a team that you actually want to work on? Pay might be great. work might be interesting, but if it's like a a really toxic team, like I don't know, your situation might warrant it where you're like, screw it, I need the job and like I'm doing it.

Uh but I suspect if you don't want to, you know, burn out from working in an environment like that, then uh you might be, you know, hunting for jobs like almost immediately after you start. Um but anyway, just something to consider, right? It does work both ways. So, I hope that was sort of interesting. I was uh I don't know. I thought it was very relevant for some of the topics recently. So, wanted to chat through it. Um so, I did mention earlier, right? If uh if you want to see the live stream where I go over uh code commute topics, the Devleer podcast. So, it's just Devleer podcast on YouTube. It's where you can check that out. I do a live stream every seven or every Monday. My goodness. Every Monday at 7:00 p.m. Pacific. It's roughly an hour long. It's all recorded. It's on YouTube, so you can check that out uh afterwards if you can't make the live stream.

And then if you have questions you want answered on Code Commute, what you're watching right now, um leave them below in the comments. And otherwise, you can go to codecommute.com and you can submit a question anonymously. And then that way, um you know, if you leave a comment, it's public. If you don't want to have it, you know, shown, then submit it anonymously and that way I can answer stuff for you. Oh, come on. Parking spots. We came to the office a little later today. Um, otherwise, Dev Leader is my main channel. If you want to learn C programming, how to work with AI tools for your software development, check that out. Um, that is my main channel. That's where I got all the the goodies, edited videos, that kind of stuff. And uh otherwise, Dev Leader Path to Tech. There's no parking spots here, man.

Deleter Path to Tech is where I do resume reviews. So, if you have a resume that you want some feedback on, uh I don't roast them. I try to call out the things I do you uh that do I think you're doing well. Like, I can't speak apparently. And um where am I going to park? Holy crap. And then yeah, if there's things that I think that you could improve for clarity and that kind of stuff, then I will address that as well. Thanks so much for watching. I will see you folks next time. This guy's parked over the line. Come on, man. See you.