Treating Devs Like Human Beings

Sometimes among all the sprints, the pressure to ship faster, tools to measure lines of code written, it seems like we as an industry forget a simple fact: developers are knowledge workers, not robots.

To remind us what it means to be a human, we invited some of the most empathetic engineering leaders we know to Interact and asked them to sit on a panel together. The conversation that followed is one of the most insightful and relevant conversations we've heard all year. Whether you are an IC, manager, or manager of managers, we promise this conversation will help you become a more empathetic leader and colleague.

Today's episode of Dev Interrupted features Kelly Vaughn, Director of Engineering at Spot AI, Jean Hsu, VP of Engineering at Range, and Lena Reinhard, an engineering leadership coach. 

Episode Highlights

• (3:34) Hot take: no coding exercises in technical interviews
• (13:35) Why the panelists are so passionate about this topic
• (28:52) How to conduct a proper 1:1
• (36:44) "BS metrics" 
• (46:38) Burnout isn't the "24 hour flu"
• (53:41) Discussing burnout with your manager

Episode Excerpt

Conor: So, I wanna kick off this panel by doing something a little different. When we were talking before this conversation, a kind of a, maybe a hot take came up, when we were talking to Kelly. Kelly, you said that you question whether or not engineers should be required to code in an interview. What's your take?

Kelly: Yeah, I love starting on a hot take, by the way. This is a great way to kick this off. Yeah, this is one of those hills I'll die on. I am very, I'm a strong proponent of not having a coding exercise in a technical interview, reason being, most of the time, we're hiring engineers who are not absolutely brand new, and they've been coding at other companies before, they have plenty of production building experience, and so I am not here to see exactly how you code, especially live. First off, we're not, you know, standing behind each other, watching each other code, so that's not a thing, and, second, when it comes to like take-home assignments, for example, they lean towards privileging those who have the time to put into doing the take-home assignment, and so, if you are looking for another job and you are still working full-time or working long hours, it's very tough to find the time to actually work on that, and so you might not be able to do your best work, so it's already putting you at a disadvantage. So, I like leaning more on system design interviews because I wanna know how you think, I wanna know how you problem-solve, I wanna know how you approach a problem, I wanna know just your entire thought flow, especially as you're working with one of our engineers and going back and forth, you know. No stupid questions in this technical interview. No, like, I want to hear whatever is on your mind, and I've found this works really well. I mean, I like to say, I like to think that I've hired some really great engineers in the past, so it's been working great so far. I will say the one caveat, though, is with junior engineers, I know you need to establish some level of baseline knowledge of where they're coming in, and so I'm okay with some like basic, how would you approach solving this specific coding problem, but I'm trying to make technical interviews less stressful for the candidates because they're already so incredibly stressful as it is.

Conor: What about you, Jean, what do you think?

Jean: I definitely tend toward the, like, let's simulate what it would actually be like to work with this person, and so things like, you know, having them describe something they did, which, you know, sometimes if it's a more senior engineer, we'll bring in some, you know, mid-level folks or junior folks and be like, okay, like this is kind of a situation where this person's describing something like, can you communicate with this person, right? Or have them work with a designer or PM and, you know, have a sort of like simulated kickoff meeting and see, like, hey, can this person help, you know, given these priorities, or will they ask for the priorities, and then how can they help scope or, you know, think about the timeline for this project that we just kind of threw in their laps, right? Like, this is for a more senior engineer, and that's really, I think, you know, going back to the topic of this talk, like what is it like to work with this person rather than like, what is the current technical ability that they have 'cause I'd much rather have someone who maybe doesn't know the language that we're coding in, but has a strong trajectory, has a strong career history of picking things up quickly, right? Like knows a few languages, they'll pick it up quickly. They've had that like, I guess, success in the past, and so, I think assessing what their current, like technical skills is not like super, is not super helpful.

Lena: Yeah, yeah, I would so agree on that. Like I was, for a different project looking this up just last week, engineers, on average, spend about 11 hours per week in meetings, and even if, you know, in your organization, that's different, and I know meetings are a whole different hot topic, but I find that a really interesting way to illustrate, like the job is so much than put, so much more than putting out lines of code, and the job is so much more complex than that, but I still see so many organizations where the interview process for engineers is essentially a row of technical assessments that just focus on how do you produce code, but how, in the sense of essentially how much code do you produce, and where the complexities of it that are about collaboration, communication, building good relationships, being able to take ambiguous problems and turn them into solvable chunks of work, and all of those kinds of things that actually make up the majority of the work, or interacting with your team in one of these 10 hours of meetings, that's the role, that's the actual job, but I think so many companies, already in the hiring, basically pretend like it isn't.

Jean: Also, the more senior folks get, I mean, especially if you're hiring someone who's sort of like a tech lead or engineering manager type, right? Like they likely haven't been coding, so you hear, you know, I have friends who are like, "Oh, I'm thinking about interviewing, but I need to spend like four months studying up on like LeetCode." I'm like, there's something so broken about the system if you're applying for the same role you have now, but you feel like you need like, full-time, to study for four months, like that's just ridiculous.

Conor: Yeah, to all of your points, what I'm hearing is this recognition that software engineering today is a team sport, and we're often taught, I think, as folks are moving into the ranks of becoming a developer, that it's more of an individual thing. You go in and you like knock out all this code and you solve this problem, and that's part of it, but you also are functioning within a larger organization within a team, you're working with product to make sure you're aligning on the right features, you're working with the rest of your team to make sure you're working on the right pieces, you're probably doing PRs, and I kind of hear that recognition from all of you, which is important that we consider the job as more than just pushing code out.

Lena: I think there is an added complexity in that team element, like so many companies essentially when they hire engineers, assess them at an individual level, and there's no doubt that that needs to be done, but the much bigger question that ultimately arises once they join is are they going to be able to perform effectively as part of a team? Because we all know that like adding one engineer to a team won't mean that the output of the team is going to grow by one engineer exactly. You're also increasing the complexity of that team, but what happens is that engineers are basically assessed as sort of standalone entities, and I think a lot of that still comes from this really pervasive hero culture that we still have in our industry, of sort of the lonely coder, maybe they're wearing a hoodie and they're probably also a man in that cliche, and they have the, you know, the stereotypical hacker, whatever, screen on that we all know from the movies, and they're doing it all by themselves, all by their lonesome, but that's not the reality, but at the same time is this question like, how will they contribute to the team? What value are they going to add? What impact can they bring, and how are they basically making the whole of this team better in terms of how they're working and what they're able to, has in terms of impacts, like that's the big question that I think is often really underestimated because we are so focused on these individuals.

While you’re here, check out this video from our YouTube channel, and be sure to like and subscribe when you do!