Some typical technical interview practices can be harmful and get in the way of hiring great people. April Wensel offers advice to help fix the technical interview process.


Transcript for episode 72 of the Test & Code Podcast

This transcript starts as an auto generated transcript.
PRs welcome if you want to help fix any errors.


Technical interviews can be stressful events. April Wendell’s on the show today to talk to us about a lot of the aspects of a typical technical interview that are really actually broken and harmful and actually get in the way of hiring great people. She’s recommending things like hiring for mindset and attitude and looking for things like empathy and mentorship skills to allow candidates to show their strength during the interview process instead of looking for their weaknesses, even to the point where a candidate should leave the interview process feeling good about both your company and themselves, regardless of the hiring decision. I think those are great goals and I learned a lot from talking with her, and I hope you do, too.

Welcome to Test and Code, a podcast about software development, software testing, and Python.

Welcome to the Test and Code. On today’s episode, I have April Wenzel. Before we get started, will you introduce who you are?

Sure. Yeah. So my name is April Wenzel. Happens to rhyme with pencil. I’m a software engineer. I’ve led engineering teams, worked at a bunch of tech companies for about ten years in Silicon Valley. And a few years ago, I started my own company, Compassionate Coding, to fix some of the toxic elements of the tech industry.

That’s pretty cool. So the compassionate coding, how do you fix that?

Yeah, right. Good question. So a lot of people might not agree that there is a toxic problem in the tech industry, but I see it as it has a few different parts to it. For one, the glaring thing to me is just the lack of diversity throughout the tech industry. But it doesn’t stop there. We’re building, a lot of times, unethical products or even in a milder case, products with not the best UX for our users and not accessible things like that as well. And a lot of times projects fail. And there’s this kind of poor communication on team. It’s poor collaboration. A lot of projects aren’t failing for technical reasons. Quote, they’re failing for people reasons, like not working on the right problems or not distributing work right or not collaborating effectively. And then finally, burnout is a big problem in tech. So a lot of people are dealing with stress and burnout, and they just a lot of times don’t feel comfortable talking about it because there’s some shame around it. So anyway, so I saw all of these problems as related because they all relate to the human element that often gets neglected in our digital world. And so Compassionate Coding is really about emphasizing emotional intelligence and related concerns like ethics and making that the center of what we do in software development. So asking and every decision we make, technical or otherwise, what’s the compassionate choice here? So I do workshops at companies, and I speak and I mentor and advise companies on how to incorporate compassion into the business and software development process.

Okay, that sounds really cool. And kind of a big lofty goal.

Well, you know, dream big. That’s how you do it. But yeah, and I think I really see it as planting seeds everywhere I go. And then I create, like, a lot of people become agents of compassion within their organizations, and they continue spreading the message. So it’s really taken off. It’s been amazing.

That’s great. Something I’ve thought about a lot is kind of how to do a good technical interview. Somebody on Twitter mentioned that there was a bad experience somebody had with whiteboard coding. And I can’t remember what your reply was, but that’s why I got a hold of you to try for us to sort of talk about what’s wrong with the technical interview and what we can do to make that better, because it’s tough. I mean, it’s tough on both sides.

Absolutely. I’m happy to talk about this, because it does tie in directly with compassion, because I think that the biggest problem is that tech interviews, as they’re done now, are the opposite of compassionate. They’re often adversarial. And I think that that particular example you mentioned is the woman. I believe that I was tweeting at that point, retweeting. She said that she had like six people watching her do the interview on the Whiteboard. And afterwards she said, oh, I completely bombed it. And she was doubting herself and everything. And there’s this phenomenon of imposter syndrome in the industry where people feel like they’re not good enough, that they don’t belong. And I think it ties into these harmful interview processes that put people undue pressure. That’s not like the pressure that you feel in the workplace. It’s a very different kind of pressure, and it’s why it’s not effective and it causes them to question themselves. And so it’s actually doing psychological harm. And that’s why it’s so important to me to help companies and individuals in this process.

I think it’s great to talk about it also, because on the other side of it, if somebody’s interviewing, trying to hire somebody, the hiring manager wants to know if they can. We’re trying to assess stuff like what skills the person has and can they problem solve. And it’s possible that sometimes that’s just people being clueless and thinking, well, I don’t want to just have one person’s opinion of whether that person is good or not. So having a couple of people in there might be more fair. But at the same time, it puts somebody on stage a little bit well.

So it’s interesting because I think what you hit on there is a really good point, which is that a lot of the problems with the interview process are not intentional.

Like you said, they’re like an innocent mistake. Like they’re thinking, oh, yeah, six people and one. Now, what they don’t understand is that especially in the situation where you’re dealing with a woman, somebody from an underrepresented group, person of color, LGBTQ, or somebody in another underrepresented group. There’s this phenomenon called stereotype threat, which is this extra anxiety that people from minority groups feel when put under pressure in such a situation because they have this fear of confirming negative stereotypes about their group. So in a situation where there’s like six white men in the room and you’re also like a white man, then sure, maybe you feel camaraderie and you might not feel as much pressure, but when you feel like, oh, they all already think that I’m not good at coding because of stereotypes, it puts an extra pressure on you. So that’s one dynamic that I think often gets overlooked because of the lack of diversity in tech. But it really affects everybody because six people watching you do something, people who are introverted or highly sensitive people won’t perform as well in that scenario. And the problem too is that it’s not at all what work is like when you’re working with somebody, collaborating on a team. It’s much more or it should be much more collaborative where you’re sharing ideas, you’re giving each other feedback in a positive way. Not like prove to me that you’re not an idiot, which is basically how a lot of interviews are set up. And if you go in in that way, it’s not going to work. I think that doing it in this way of using pressure on people, basically putting pressure on people to prove that they’re not incompetent. Right. Is this form of hazing? I think that people go through like we all went through it and so we think, oh yeah, let’s just interview other people the same way. And if I survived it, they should be able to too. And it’s just using this old model. That’s the problem. So as far as your question about, you know, should we use whiteboard interviews? I think a whiteboard is just a prop. That’s not really, it doesn’t really matter whether or not that’s in the room. I personally have had positive experiences on both sides of the table using whiteboards. Like, for example, when I was being interviewed, somebody asked me to explain something, just some concept to them on the whiteboard, which I thought was a great question. And so I explained my senior thesis, which was I’d done some machine learning on movie reviews, to do sentiment analysis on blogs. And I knew it very well because it was my senior thesis. And so I could explain it, answer questions about it, sketch it out, and it was gauging my ability to discuss technical concepts. I thought that was a great use of a whiteboard. And because it was something I had done before, I felt comfortable talking about it. And then on the other side, I’ve used whiteboards to both communicate things to candidates, like to communicate an issue and then ask what they would do in that scenario or whatnot, or ask them to describe a past project and if they want it to use the whiteboard. So I think in those ways it’s useful, but to basically use a whiteboard as a proxy for almost like a sheet of paper. Or you would be taking a test on, like some kind of standardized test or like a computer screen and asking people to write code on it or that sort of thing, I think is not very helpful because, again, it’s not like what you’re actually doing in the workplace, so it’s not a good gauge of your skill as a software engineer.

Okay. One of the things you said in your Twitter chain really bothered me.

Great. Let’s talk about that one.

We usually hire more women when we’re working on family oriented games.

That’s not our focus right now.

Yeah, that happened to me in one of my first interviews out of College. I was still at College, like, finishing up, and people came to Harvey Mud. It was this gaming company. And they came to Harvey Mud, which was. I went to Pomona College, but I took some classes at Harvey Mud. It’s like an engineering school. And they came to interview us on campus. And I did my best in the interview. And I mean, to be honest, I did really great in school. And I just say that because it’s true. I was really good in all my classes, like Summa cum laude in computer science, all this stuff, but, like, the tech. And so in the interview, I assumed all I test well and everything, so I’m just going to do great. But I did not anticipate in the real world all the bias that women have to deal with, because when you’re taking a test, it’s less of an impact. So anyway, so, yeah, they said that in the interview, and I was just like, how do I even respond to that? And I was more insecure back then in terms of I was just entering the workforce. So that was pretty discouraging that they were putting me in that box of like, oh, yeah, we assume that women want to work on family oriented games. Meanwhile, little did they know that I grew up playing, like, Quake and Doom and Duke Nukem and all these shooting up games and also, like, SimCity and all these whatever. So I actually probably would have been great. But then I was like. And they ended up hiring some people from my class, of course, men who didn’t do as well in the classes and everything. And so I was just like, seriously, that was my first taste of what it’s like in the real world.

That’s just terrible. Yeah. Okay, well, that’s what I was going to say is there’s some real awful stuff, like obvious sexism, there’s some jerks and some complete idiots in the industry. But if you’re trying to do the right thing and trying to. What do we do to go about trying to do the right thing?

Yeah, no, I think you’re right. There’s an extreme there. But I think more often the more common problem is more unconscious bias that gets slipped into the interview process because it’s unconscious. And so, for example, if you do an interview with somebody and having been on hiring committees, I’ve heard this so many times, like he just didn’t seem technical enough or I don’t think she’s technical enough. This is such a vague way to talk about candidates, and it means nothing. And it’s tied to bias because a lot of times it’s because, okay, maybe the person doesn’t code on side projects all the time because they have a more balanced life. Right? But they’re still a competitive programmer and they code well at work, and then they do stuff in their free time. And sometimes things like that will be used as a signal of, oh, well, they’re not really technical. Or, for example, women, because of whatever other skills they communicate in the interview, aspects of emotional intelligence, empathy, et cetera. They’re often also assumed, like women are often told, oh, you should be a product manager because you’re so good with the customer. And whatnot, when really being an engineer who understands the customer needs and can have empathy, it makes you a better developer.

But those people in interviews will often be labeled as not technical. So I think, yes, there’s the extreme, but there’s also a lot of unconscious bias, and this rules out a lot of candidates. Now, I think this is important for both sides because a lot of people talk about this, quote, talent shortage, which is a myth. I mean, there is no shortage of talent. And I know this because I see both sides of it. I advise companies on this, and I’ve interviewed tons of people, but I also mentor a lot of people from underrepresented groups, especially, and people from nontraditional backgrounds, the people who go through boot camps and or self taught, and they’re desperately looking for jobs. But because of these processes that are based on a narrow profile of what makes a good software engineer, they’re being ruled out. So there is no talent shortage. They’re just we’re bad at interviewing. And so that’s the gap there that I see. And so as far as things that you can do, I think the key is to stop approaching interviews as, like, a hazing process or coming from a place of fear, like, oh, we’re so scared we’re going to hire the wrong candidate, or, oh, they’re just faking it. I feel like there’s this great fear in tech that people are just pretending to be good at programming. And people cite these studies of, like, oh, a lot of programmers couldn’t write Fizz, Buzz or whatever. And a lot of those studies have been debunked. And the thing is that people under pressure, as we talked about, can’t perform very well. There was a study out of the University of Waterloo that found that people who have anxiety and are in intense situations have trouble counting up to five when they’re under pressure. So we shouldn’t be evaluating people under pressure because we’re not getting their best. So I think the key is a mindset switch here, which is fundamentally let me go into this interview and give this person the opportunity they need to share what value they could bring to my team.

And that might mean allowing them to talk through past projects if they have them, and asking technical questions about them doing a coding exercise if they want to. I personally don’t feel it’s worth my time to do coding exercises for free for companies, so I don’t do that. But some people do prefer that pairing pair programming can be a great way to interview for people who want to do that. But I think the key is having a variety of options and knowing what you’re going to look for ahead of time with a rubric, an idea of what you’re looking for, but giving candidates the opportunity to share strengths that they might not get to if you try to use a very narrow way of evaluating them, especially if it’s based on your own biases.

Right. That’s hard to get at. One of the things that a lot of I don’t know if it’s still done, but at least when I was starting out so this was 90s, 2000s, there was a lot of emphasis on trying to get somebody that would be a good cultural fit or a team fit. Is that, like just code name for more people just like us?

Yeah, I think it is. And I think Kara switcher has this great term for that in tech, which is a mirror talkracy. So we like to talk with a meritocracy, but she says it’s a mirror to see because it’s people who all look alike and like the same thing. And I think that happens when you try to fit somebody in. Now, that said, I think that there’s always nuance here, so there is something to having shared values so that you can all work together. Well, right. I mean, there’s something to that. And I don’t want to pretend that that’s not a thing, because it is. And I think sometimes we overlook that. But also it’s better instead of talking about culture fit to talk about culture ad, which is you’re looking for somebody who is bringing something to the team that you don’t have. So a lot of programmers go into interviews and say, oh, I want to see how this person solves problems or how they think, which is kind of arrogant to assume you can figure out how someone thinks in like an hour long interview. But really, it’s often a code for saying, like, I want to make sure this person thinks like I do, because that’s how I determine who’s smart and who’s not. And that’s really often what it boils down to. So instead of doing that, look for somebody who thinks about things different from you, even if it seems weird or if they seem like, oh, that’s not how I would have done it. Oh, that’s great, because that means this person will bring a balance to the team. So instead of culture fit, I think it’s important to look for who’s going to add to the culture, culture ad.

I love that idea of culture or adding to the culture. Also adding to the features or the skill set of the team. Who’s qualified to interview somebody for somebody, for a skill that they don’t have.

You hit on one of the biggest problems, which is that engineers are given basically no training and how to interview, or there’s just like a Wiki page or something. But I know from doing interviews I could pretty much ask whatever I wanted, assuming I wasn’t crossing any legal line. And that’s a problem because a lot of times, let’s be honest, I know interviewers who just open up that like cracking the coding interview book and basically pick questions and then just ask the candidate, or they look up some obscure term and then right before the interview and then ask the candidate to figure out to answer the question, trivia question about it. And so the lack of training is a big problem. And so I think companies need to invest in training candidates on how I’m training interviewers on how to evaluate candidates, because, again, we want to look for certain skills in terms of how they’re going to solve problems and things like that. But I also think it’s much more important, much more important to look for mindset and how they’re going to work with others, because it’s much more important whether or not you’re going to learn new skills, especially in the fast changing industry we work in. It’s much more important to think about how you learn new skills and what skills you have already. And so I emphasize growth mindset. Carol Dweck’s idea this growth mindset where it’s about building your believing that you can grow the skills you need. And so there are ways to get at this in an interview, and there are also ways to and the way you do that is you ask about things they’ve learned in the past and things get them to tell stories about things like that and things like empathy. I think it’s been so undervalued in our industry because we work on computers, but we also work with human beings and for human beings. And so I think it’s important to ask questions that get empathy both for the customers and for coworkers. So you might have stories about when they’ve had a disagreement with coworkers or when, but not just to evaluate how they handled it, but more like, can they put themselves in the shoes of the other person and understand where they were coming from? A question like when was the last time you changed your mind about something, things like that? Can help get somebody’s attitude, because one thing that we’re missing on a lot of tech teams is the ability to mentor. And this is important as we have more juniors coming into the field and people from boot camps and self taught, they can benefit from mentoring. And we don’t have people that are very skilled at mentoring. And so being able to hire people who are also good at mentoring should be really important for growing the skills on your team and making you all together more effective.

That’s also something that we’re not taught is how to mentor.

Yeah. This is why I saw a big gap in the industry in this and why I started my company, because I was like, oh, wow, we’re doing all of this really poorly because a lot of times that the emphasis has been on some guy coding alone in the basement and cranking out code. And that’s what we’re evaluating for. And that’s not the state of modern software development. You’re working on a team, you’re working with customers. The agile movement has you talking to customers or understanding their needs. And so we need people who have many more skills than just cranking out code. But it even affects the code, because if you have more empathy, then you’re going to be better at naming variables and structuring code for maintainability because you’ll have empathy for the people who are going to be using your code. So I think that these skills really are essential. They’re not just, like, extra nice to have soft skills, and I hate that term soft skills. I always recommend using catalytic skills or meta skills or something like that, because these are really key skills to being a good software developer.

Communication. Yeah. One of the things that I’m stuck on a little bit is that if I’m hiring somebody to write code, I kind of want to see some of their code.

Yeah. And I think that that’s a fundamental misconception is that you actually have to see them. I don’t think that you do that.

I feel like what we need to evaluate is the value that person’s going to bring to the team. And so I think you want to simulate what that’s going to be like. So there are ways to if you do want to see code, I think offering, like, a pairing exercise where maybe somebody on the team does the driving and then the candidate helps come up with ideas. I think that is good for helping simulate what an actual collaborative work environment would look like. And then it gives both people a chance to evaluate what that working style would be like. But also, this person has if their experience in the industry, they’ve likely written a lot of code. So one, they may have some to show you. And if you’re trained, you can ask them very technical questions to find out whether they actually understand the code and all of that. And then two, you can either see the actual code or you can ask them very technical questions about how they went about planning it. Because to be honest, as a software engineer, some of your time is spent cranking out code. But I don’t think it’s true that we’re hiring someone to write code. I think we’re hiring somebody who will deliver value to our customers. And I think it’s important to remember that because the actual coding part, I feel like it’s just something that just comes out, like they can learn the skills they need, for example, somebody who doesn’t know a specific language or whatnot. If they have the mindset to learn that and the motivation and the track record of having learned other things, then yeah, I’ll hire them to do that. So I think that there are a lot of ways to evaluate somebody’s ability to contribute to your team that don’t involve forcing them to code under pressure.

I don’t really like the under pressure part. So one of the things in one of the interviews I did when I was interviewing was a company sent me before they even did any like too far into it. It was like a really quick phone screen or something, and then sent me three problems and I could pick which one I wanted to do, I could use any language I wanted and then just code up the answer, and that was part of it. And then that code itself was used during the discussion.

So that’s one option and some people will appreciate that some potential issues with that one is the timing. So depending on how much time the person has, sometimes though, you’re given like a narrow window where you can submit it like you have 4 hours to submit that. And so that does create the undue pressure and whatnot. But even if you don’t have that, having this be the one representative sample of you and how you code, I think can be really problematic and create a lot of pressure on somebody to spend excess time on it. If they’re given free amount of time overthinking things and whatnot, and they won’t be able to ask questions and ask for clarification and feedback on things that they would be able to do under normal working conditions. So again, you’re not really simulating what actually working together would be like. And then three. And this is something that often goes overlooked by people with more privilege is that if you’re a single parent or you’re working several jobs already, you’re not going to have a bunch of time to spend on doing free labor for a company that’s just not very good at interviewing. And it’s forcing you to do this exercise. So I think that you’re going to rule out candidates who don’t have the luxury of a ton of extra time to be working on things like that. And that’s something to consider too, especially if you’re trying to diversify your team.

Okay. The free labor thing, I do get that. I’ve seen people interview where they actually ask a question that they don’t know the answer to and they’re trying to come up hear what other people’s opinions are. I’m like that’s lame. You’re trying to get free answers out of somebody. When I’ve used it before, I’ve tried to just give, like you said, some of those really simple questions, I don’t know, fizz buzz or anything. I’m looking for a lot of stuff. So I do understand that that’s a hardship on somebody. There’s also, like the time of trying to figure out maybe you’re in a different environment in California, but we do sometimes have trouble finding people that really do have the skill set that they list on their resume.

Yeah. And I think a lot of that perception probably comes from how you’re interviewing them. So I would challenge that because I think that I’ve heard that from a lot of people. And then when we actually dig into it, it’s because they’re quickly ruling people out based on filters and unconscious bias that they’re not even aware of. So I don’t know. I would be curious about more specifics there at another time. But yeah, no, I think it is important, too, for the interviewers to have a good process, like a good experience. It should be good on both sides. Right. And a lot of interviewers, a lot of engineers hate doing interviews. So making it positive for them, too is important.

Yeah.

So I think I can see that. But I would say, too, a lot of times with those take home exercises, you said you’re looking for a lot of things. And the problem is those things. Like, for example, I was at one company, they gave a candidate, like a take home exercise. They returned it. It was a great solution, but they didn’t include tests with it, even though that wasn’t part of the assignment. And who knows if they had written tests on their own. And they said, oh, well, they probably don’t do tests driven development or something like that. So a lot of times we make assumptions when we’re just dealing with somebody as if they’re robot producing code rather than thinking, feeling human being that we can actually have a conversation with.

Okay. I do like the idea of opening it up, too.

So there’s something to talk about to say if you have a GitHub profile or some other code that you’ve already have that you’re willing to share with us, we’d like to take a look or the collaborative thing where you could have questions. I like that. And it’s a different personality thing. I didn’t give somebody a choice. Me personally, I’d rather go off in a corner and think about the problem and solve it rather than while somebody’s listening to me do it on a pair programming application or something. That would stress me out.

Right, exactly. Yeah. And that’s the thing is giving options. And that’s why I think honestly having that variety and really making the goal, like finding people’s strengths rather than trying to expose their weaknesses can really change completely the way we do interviews.

I’m thinking while we’re talking, it would be completely reasonable to just be upfront about what we’re looking for.

For instance, when I’m trying to look at somebody’s Python code, I know people come from Python from different languages, so I want to make sure that they aren’t really just writing C in Python or really just writing Java in Python. It’s not just a personal preference. It’s maintainability with the rest of the code base.

Right. And the question, though, is how much how hard is it to close that gap if you think that they are? Like, for example, I was hired at a company to write Ruby code using Ruby on Rails, and I had never written Ruby before. I had written Python. I’d written Sequel plus Java, all that. But I’d never written Ruby code. They hired me anyway. And I learned on the job. And sure, the first few months, I did write C Plus Plus code in Ruby. I did four loops instead of old fashioned, kind of like four loops instead of the Ruby each thing and everything.

But you can learn.

But I could learn. And so I think that that’s the thing is why rule someone out? Because they don’t include test or because the style when those could be style guidelines that you give as part of their onboarding, because this stuff is not that hard to pick up. I mean, I’m just being honest here. It’s like once, you know, the fundamentals of coding, like, as far as these style things, what’s important is to have the motivation to learn it and the openness and the humility to admit that you need to improve on these things, not that you can already do everything perfectly or perfectly according to the company standards. And so I think, again, that’s the thing that is missing in our typical interviews.

Yeah. So the ability to learn and change. And how do you determine that in an interview?

Yes. And I think that’s a very human thing, which is why a lot of engineers aren’t good at assessing it. And that’s why training comes into play. And that’s why I do training and other people do training on this. But it’s asking questions about past experiences and asking them about past projects and then trying to get into like, well, who did you work with on this, and what did they think about that, or were there other ideas proposed for doing this and trying to get through some of the walls that people often put up and try to get into?

Like I said, when was the last time you changed your mind about something, or is there something that you used to believe and now you no longer do because that gauges somebody’s openness and people who are openminded will probably have a ton of those to talk about.

So a lot of interviews with companies, there’s going to be the person is going to go around. Either multiple people will come in the room one after another every half hour, 40 minutes, or the person being interviewed will go around to different people’s offices or desks or whatever and get interviewed by different people. For some people, that’s terrifying. Is that a good thing? Bad thing? Can we change it?

Fix it terrifying. It’s definitely never a good thing. I don’t think you mean just being interviewed by multiple people. Is that the yeah.

Like over the course of 5 hours or 6 hours, it’s a long day of interviewing.

It’s terrifying. And it’s also exhausting. To be honest. I’ve heard from a lot of people who just feel exhausted after a day like that. And again, it’s not like what’s going to be working there. And so it’s like towards the end of the day, especially, you’re not really getting the best assessment of that person. So I really don’t think that’s necessary. I think that examples of great interviews that were long enough to gauge somebody’s confidence but not overwhelming. We’re like a few hours like maybe 3 hours or something like that spent pairing with someone on the team, maybe two people on the team and then like a conversation afterwards with somebody else on the team, that sometimes hiring manager or whatever, that kind of thing can be helpful. And if instead you aren’t doing the pairing thing and you’re doing the exercise, I think trying to get it down to we talked about like MVP for things. I think it’s important to get like minimally viable interview where you’re getting what you need and you’re giving the candidate a chance, but you’re being respectful of everyone’s time. But yeah, I think we don’t need to do those marathon interview days and I think that I’ve never seen one of those. That’s good. Even when people I think that they’re always usually paired with, they’re typically paired with poor interview practices in other ways because it’s just a lack of compassion for the interviewer and the interviewee, to be honest, because people get tired with that much going on.

It is tiring. One of the reasons it’s done sometimes is to make sure that there isn’t just one person saying yes or no.

Multiple people is good, but it’s about finding that balance. So do you need six people? Not necessarily. Do you need more than one? Yes. And then the balance is somewhere in between and it depends on the team and everything like that.

This idea of a pairing, like two or three people hanging out with the well, probably one to two people hanging out with the person. Coding through an exercise, you can’t show people your secret code. So do you come up with coding challenges at that point or how do you do that?

Yeah. So I’ve seen it done both ways. So some people have parts of the code that they don’t mind sharing because especially this works for small startups and stuff that their code is not that valuable yet. And this is how interviews are done at Pivotal, at least when I interviewed their first startup that was working their Pivotal lab, sometimes it can be code, like in a part of the system, maybe too. If you have anything open source that would be useful too. But it’s otherwise yeah. I think at one company we did kind of one of those basic problems that you might give to a candidate, but instead of having them do it on their own, we wrote it together. And what was cool too about that was we were using a language that wasn’t the language being the person was being hired for. So it was more to talk about more abstract levels of how they solve problems. And so the emphasis wasn’t on syntax or anything like that. It was more on that worked at the company, did the coding and they knew the language and so it was more having the other person say, okay, and then we’ll want to have a variable for this. So they don’t need to know that specific language. I think that that’s like a higher level of hiring where we understand the computer science concepts kind of transcend language. I mean, yes, there are language specific things you need to learn, but those are much more easy to grasp in a few weeks of reading the materials on it. But the fundamental, like computer science concepts and problem solving concepts are really what’s much more important to the value you’re going to bring to a team? Can you understand the problem? Can you come up with solutions? Can you discuss solutions with other people?

Those are the types of skills that I think we should be going after, rather than like, oh, do you remember how to declare a class in Java and all this stuff? And it’s like, well, I might have to look that up, whatever it is. So I think that’s an example.

I don’t even know if they do it anymore. Actually, I’ve never interviewed with Google, so I don’t know if that’s true, but these weird questions like how many marbles fit in a school bus and things like that.

Yeah. And they came out saying that they know that those interviews aren’t very effective. They recently came out one of some of their people and said that those were not effective. And so sadly, the industry is not still using a lot of those questions, other arbitrary things that aren’t very useful.

We’ve at one point tried to come up with in the past, I’ve been involved with interview processes. We’re trying to come up with a representative problem that is similar to what we’re working on. But there’s a lot of roles that what we’re doing is. So we don’t even expect somebody to understand, like communication systems right off the bat, because I know that there’s not going to be anybody that’s an RF expert, a communication system expert, and knows really good C Plus Plus and Python all at once. Those people don’t exist. So we got to figure out what skill we’re really trying to fill for and what they can learn. The other thing is we’re not taught how to teach people either.

This idea that somebody can learn on the job with mentoring that relies on the team being able to help teach. And teaching is a skill that we don’t often have.

They got to approach it from somewhere. So it’s like you got to start change has to start somewhere. And so I think it’s about promoting people who are good at mentoring already. If you do have some, it’s about starting to hire waiting more heavily how well someone mentors when you’re hiring them versus how fast they crank out code solutions, whatever. Those are ways to change because we need to have a big culture shift here. And so it will lead us to challenging the traditional way we do things. And I think that that’s a good thing because I think it will help the industry. It’ll help us make better products. I just think it’s the way to go here.

Okay. Let’s say there’s a hiring manager or team that needs to ramp up pretty quickly and hire some people. And for some reason you’re completely booked and they can’t hire you. Is there some place where they can go to just sort of at least get better than where they’re at now to learn some more stuff about interviewing better a few resources that are online.

So one is I wrote a blog post that touches on I’ve written a couple of touch on some of these points. So one is called Leave Your Gut Out of Hiring Decisions, and I think that will help people understand some of their own biases and that sort of thing. I written another one about called If You Can Use a Fork, You’re Technical, where I talk about this. I told you about this bias. This person doesn’t seem technical. And that gets at a lot of the assumptions we bring into the interview process. And I talk through some interview examples and how to do it better there. And then three. And this is not something I’m affiliated with, but it’s a great website, I think that will help people understand the problem with tech interviews and how to do better is project include. I think it’s projectinclude.org.

Okay.

They talk about they have specific strategies for dealing with having better interviews and whatnot. So I think that’s another place to go. And I would say don’t go to Google Microsoft history or cracking the coding interview. And definitely not Joel Spolsky The Gorilla Guide to Interviewing, which I know a lot of people still point to. Don’t go to those go to anything else pretty much is probably better than those.

I love all this information and I’d love it if we could fix this because really software? Yes. We need some people to have solid computer science backgrounds, but we also need people with other backgrounds as well. And just like a lot with so many software problems that we kind of need to be fairly representative of the rest of the population, we’d probably write better software that way.

Absolutely.

I’m glad that you’re one of the people Trying to fight the good fight and thanks for all of this great information.

Thank you. Yeah, I think if I could leave you with three things, one would be higher for mindset attitude over the other things to look for things like empathy that don’t get as much due allow the candidate to show their strengths. And finally, I think just an easy way to see if you’re doing this right is the candidate should leave feeling good regardless of the hiring decisions. They should still respect your company and everything. They shouldn’t be crying afterwards, which is something I’ve done after many tech interviews to try to leave the person feeling good regardless of whether or not you hire them.

Oh, that’s great. Yeah. Crying is bad.

Yeah, not necessarily, but making somebody yeah, that’s not good.

Well, good luck with everything you’ve got going on And I’ll talk to you later.

Yeah, for sure. My website is compassionatecoding.com that if people want to stay in touch, I’ve got a newsletter so they can come to compassionate coding.com or on the Twitter at April. Wensell tweet a lot about interviews.

Yeah. And lots of other great stuff. You do things like code reviews and all sorts of stuff.

Yeah, we can do better. We can all do better.

Yeah. Okay. Thanks for coming on. I’ll talk to you later.

Thank you. Thanks for having me. Have a great day.

Thank you to April for all that great information. The links discussed in the show Are in the show notes at testandcode.com 72 thank you to Patreon supporters for sponsoring the show. You keep the lights on and the servers up and I really appreciate it. I hope this episode was helpful to you. It was helpful to me. And if you know some hiring managers that might benefit from hearing this, Please pass it along. That’s all for now. Thanks for listening.