Charity Majors, CTO and cofounder of Honeycomb.io, discusses reasons why she doesn’t hire people. This is a very informative episode both for people who job hunt in the future and for hiring managers and people on the interview team.
Transcript for episode 94 of the Test & Code Podcast
This transcript starts as an auto generated transcript.
PRs welcome if you want to help fix any errors.
00:00:00 You’ve applied for a job, maybe lots of jobs, depending on the company. You’ve got to get through a resume review, a coding challenge, a phone screen, maybe another code example, and an in person interview if you get the job and you enjoy the work. Awesome. Congratulations. If you don’t get the job, it’d be really great to know why. Sometimes it isn’t because you aren’t a skilled engineer. But what other reasons are there? Well, that’s what we’re talking about today. Charity Majors is the cofounder and CTO of Honeycomb IO, and we’re going to talk about reasons for not hiring somebody. This is a very informative episode, both for people who job Hunt or will in the future and for hiring managers and people on the interview team. Thank you, Patreon supporters, for your continued support of the show. And thank you, Pie Chart, for sponsoring this episode.
00:00:58 Welcome to Testing Code, the podcast about software development, software testing, and Python.
00:01:09 On today’s episode of Test and Code, I have charity majors now. Charity is somebody that recently wrote an article and I recently read called The Real Eleven Reasons I Don’t Hire You, which it’s a great article, and that’s why I wanted to have her on the show. But before we get started, I’d like to know some background information. So who are you and what do you do?
00:01:29 Yeah, I am the co founder and CTO of Honeycomb IO, which is kind of a next generation look at how to do observability for distributed systems. And we’re almost four years into this thing.
00:01:44 This is the first year where I feel like we actually know what we’re doing and who we’re doing it for. It’s pretty exciting.
00:01:50 So observability for distributed systems, you said.
00:01:53 Yeah.
00:01:54 Okay.
00:01:54 So is that similar to other the products on the shelf that you’re competing with?
00:01:58 I think you could see it as competing with we kind of sit in the middle of logging, monitoring and metrics APM and tracing. We’re kind of all of those things. And I think that over the next few years, you’re going to see a real convergence in this space because it imposes so much costs on people to have to store data in so many different locations and then to have to sit in the middle of the kind of copy pasting IDs from one to the other. It’s unnecessary, it’s wasteful. And you sacrifice a lot of power, too, by not having it just be all in one place.
00:02:27 Well, that actually sounds pretty interesting. And maybe something I should learn upon and talk about later. So about four years for the company?
00:02:35 Yes, four years. Although, like for the first year and a half, we had to start by just write around storage. I’ve spent my entire career telling people, never write a database, never write a database. So I like to be very clear about the fact that we’ve only written a storage engine, a distributed storage, and maybe kind of a query plan or two, but definitely not a device.
00:02:52 Okay.
00:02:53 Yeah, we had to spend a couple of years building that. And so the product itself is more like a two year old product.
00:02:57 Okay. And how big is the company?
00:02:58 About 25.
00:02:59 About 25 people. Okay, cool. That’s an interesting magic number. When I moved to Beaverton, like ten years ago, nine years ago, the local site that I’m working at was about 25 people.
00:03:11 Right. It is. It’s a fun stage.
00:03:13 This whole article, you’ve been doing a lot of hiring then, or have you been?
00:03:17 Yeah, it was kind of our second big push of hiring.
00:03:20 I’ve been thinking about this because I ended up interviewing my friends, friends and people who I respect a lot. And it’s a really weird feeling to not offer someone a job when you think that they’re amazing and you would love to work with them.
00:03:34 One of the things I really loved before you got jumped into the reasons why you didn’t hire people is that it’s important for you to try to make it so that when somebody goes away from the interview process, they feel good about themselves and the interaction, even if they didn’t get the job. That’s a really cool thought and a cool idea to try to shoot for. So I’ve done a lot of interviewing and hiring, and in the stress of if you’re hiring somebody, you have a need and you’re trying to fill that. So trying to go the extra mile and make sure that it’s a good experience for all the people coming in and interviewing, that’s extra work that a lot of people don’t do. So that’s pretty cool.
00:04:12 It is. But I feel like anytime you have an interaction or transaction between two people, the person who has more power in the transaction, it’s their responsibility to kind of like, make sure that other people’s needs are taken care of.
00:04:24 This is a small industry.
00:04:27 We all know each other. We all know you could even look at this in a very selfinterested way and say it’s the right thing to do for your own sake, because you’re going to want to hire some of these people again or their friends sometime. We’ve all heard people talking about the terrible experience they had interviewing at some company or another, and it really colors people’s view of us.
00:04:44 I had an experience once that was surprising to me. We had went through a process of trying to bring on somebody extra to help with our work here, and I ended up doing a whole bunch of in person interviews. And then a couple of years later, I was at a Python meet up and somebody said, hey, I really enjoyed my experience with interviewing with you. I didn’t get the job, but I’m curious how it’s going. So I’m glad one person I had a good interview experience with me.
00:05:11 Totally.
00:05:12 The person I was having this conversation with the person who kind of spurred this piece. He was telling us the story of a person who turned him down for a job and made him feel so good that every time he’s, like, looking, he goes back and checks in with that person again. And I was like, how? Tell me your secrets. And it really just came down to the person had circled back to him very politely, very on time been like, Look, I think you’re amazing. Here’s where I think that he’s like, I’m probably going to regret this, but I’m not going to hire you. And here’s why. Because I think that where you want to be. The stuff you want to grow in is more in this data direction. What we really need is more in this general direction. So I just want you to know that the world of you, even though we don’t get to work together this time, and it’s so basic, there’s no magic thoughts in that. It’s just respect and letting them know how you genuinely think about them and thanking them for their time. And it’s amazing that with a bar that low, we fail to clear it so often.
00:06:05 Okay, I want to go through these. Are you okay with going through each one of these?
00:06:09 Sure.
00:06:09 But that feedback of like, I didn’t hire you because blah. Do you think that should be in a phone call or is an email good enough or what do you think?
00:06:19 I think that times are changing. I think that there are some cultures where that would be seen as an insult if you just did it in an email. I think that in most, like, Silicon Valley companies that you’d be totally fine to do it via email or text or whatever you do want to. Maybe, when in doubt, default to the slightly more formal means of communication. If you aren’t sure how the person is going to take it. But I really think that it does people a service. If you just let them know, just tell them. People are hungry for information about how they can improve. The worst thing is not knowing, right? The worst thing is just wondering and just replaying it over and over is because they said that thing is because I laughed at one time. If you don’t know, it can drive you nuts. Just giving people some signal that they can kind of learn from is, I think, a real gift.
00:07:00 Everybody’s got those painful memories, but the painful one to me was right out of College. I interviewed with somebody, and I had to go buy a new suit because I was out of College. I thought you had to do a suit thing. And then I drove up. I was in Eugene at the time, drove up to Portland, interviewed. They called me back and said the suit freaked everybody out. Could you come back and interview again without the suit? So I came back up and you know, I’m a student. Even just the gas is expensive for me. And then two weeks later, three weeks later, I got a letter in the mail with just a single sentence that says, we went with somebody else.
00:07:39 Some more information. Be good. I spent like two days on this.
00:07:43 It’s so easy to remember, because it’s easy to remember how it’s hard to remember how personal this all feels when you’ve been hiring for a while because you’ve got so many choices and everything just starts to feel very functional and very transactional. But every single time that you’re dealing with someone, this is a big deal to them, and it’s going to impact how they think about themselves. And I really do think that it’s worth investing in.
00:08:03 Yeah, I like it.
00:08:06 Thank you, PyCharm, for sponsoring this episode. Pycharm is, hands down, the best editor available if you care about quality software due to its unsurpassed support for running tests directly in the editor. If you are working with both tests and source code, you can have both files open at the same time, side by side. You can even have a test configuration run every time you make a change to either. But really, what I love most is the ability to run tests at multiple levels. Run the whole test suite, run a directory or a file or an individual test quickly and easily with intuitive controls in the project tree or the test file. All of these tools are in both the community and the Pro version, but I run with the Pro version because when I want the extra power, I want it right away. Currently, the Pro feature I’m using the most is the ability to try out custom Postgres queries against a remote database just right in my editor with all my Vim emulation customizations still in place. Super cool, super fast. If you care about quality, try Pycharm at testandcode.com PyCharm for a limited time, you can try Pro for free for four months.
00:09:08 Let’s just go through these. Yeah, I like them. So the first one is what scarcity, right?
00:09:13 Yeah.
00:09:13 What does that mean?
00:09:14 I have worked with there are hundreds of thousands of people in this Valley that I would love to work with again. And yet I have a head count of like four this year. And I want to be very careful about not just hiring. All my friends and the people I’ve worked with are awesome because I hate that. I want to let other people have opportunities. Right. And I want to build a company that’s not just a monoculture. So I really do try to cast the net widely, and it’s just a function of math. And not only is it not a question of is this person good enough to hire? Many of these people are good enough to hire. It’s a question of we have very specific goals that we’re going for this year.
00:09:48 When I’m interviewing people, I have specific projects and stuff in my head that I’m trying to figure out, this person is going to help us. Every single one of them is make or break for us as a company. Right. Our margin of error is tiny. So it’s not a question of good enough. It’s a question of can I see this person, like, being successful and help be like, the difference between success and not succeeding for this thing that I need to do this year. Right. That’s a super. When you’re hiring at a big company, you don’t have scarcity. It really is just you interview a bunch of people. If they answer your questions well enough, you give them a thumbs up and the machine just grinds into action. It’s so different at a start up.
00:10:24 You have to think ruthlessly about what are the things we absolutely need and make that list as short as possible because nobody is perfect. And you really have to hire for strengths, not for lack of weaknesses.
00:10:37 So my company is hundreds of people, but I have five people on my team. I might have an opportunity to hire one person in a year if I’m lucky.
00:10:46 And that’s super important, too, to remember that it’s not about is this the best person? It’s about. Here’s my team. I have a very specific team with specific needs, specific weaknesses, specific goals, specific. Like maybe there’s a person that I’m hiring. It’s amazing at mentoring seniors, leadership, everything. But I have plenty of people who are good at that and not enough people to mentor. And so I need to hire someone who is actually weaker in that area. And I really do feel like hiring managers at startups. We have to be thinking about the good of the team more than anything.
00:11:18 And that’s a very complex set of things that is not easy to communicate.
00:11:24 That kind of brings into the next two. So number two is diversity. And number three is we’re assembling a team, not hiring individuals. That kind of all goes into that. And I love the idea of thinking about the skills that you have and the skills that maybe are missing and seeing if you can fill those. And I just recently have started. I mean, it seems silly that it was just recent, but recently thinking about the ability to mentor people as a skill to look for in hiring somebody.
00:11:54 It’S really hard to identify those people because they’re really the flashy ones, but they are the ones who bring everyone above them up to a higher level. And they are invaluable when you find them. And they’re usually not the best at most of the technical skills, but they love it. Their heart is in it, and everyone just kind of magically improves when they’re around.
00:12:13 Yeah. Like the idea of assembling a team, not hiring individuals. There’s a whole bunch of stuff that has to get done. I can’t have five people that are all awesome at nitty gritty DSP algorithms. I need other stuff done also.
00:12:27 Yeah. In the beginning, we had a team that was very top heavy, lots of just a few senior people. Right. And what we found was our team got it better when we hired some more junior intermediate people because it forces the more senior people to kind of talk through what they’re planning to do, which helps them find the problems in their ship before they build it.
00:12:46 It’s motivating. Like, you want everyone on your team to be learning, growing, firing on all cylinders. You don’t want anyone to be sitting over there going, oh, well, today we got to build a web form. What is the 200,000 web form I’ve ever built in my life? Instead of just kind of on autopilot? It’s better for the team if you have someone who’s like, I get to build a web forum. This is so exciting. My first time ever. And everybody’s like learning and growing and holding themselves to this higher standard. It is actually like, I’m not just being like, I’ll touchyfeely about it is better for everyone, and it makes you have a better team if you have a diversity of levels.
00:13:15 I never really thought about that, that having a junior person helps the other people out for lots of reasons. They get to take on things that are exciting to them but won’t be exciting to somebody else. And also, like that mentor stuff, if you’ve hired somebody that’s really good at mentoring and there’s nobody for them to mentor, well, they’re going to be unhappy with their job.
00:13:34 And it’s so short sighted, too, because presumably you’re not just building a team for this year. Right. You’re building a company, a team that should be sustainable, that should be long lived. And that means that you need to have this constant churn. You need to be helping people grow. You need to be investing in people we have in our industry a serious problem for people being unwilling to hire junior people. It’s a real problem because it means we aren’t getting new blood. Right. And it’s really hard out there for a junior engineer. And it also means that we call someone who’s been programming for five years a senior engineer because of the constant title deflation. Right.
00:14:11 Honestly, if you think your company is going to be around for more than a year, you have an obligation to start hiring people who haven’t been in as long and helping them grow up. The loyalty that that inspires is profound.
00:14:24 People will spend a year trying to find a, quote unquote senior engineer that they can hire for a job. They could have easily trained a junior engineer to do less time than that. It’s really stupid.
00:14:35 I see that all the time. And also throwing an experience. You need to have three years experience in this stuff like that.
00:14:42 I hate that. And there’s another thing that I hate about that, which is that I want to work with people who don’t want to just do the same thing over and over and over. I want to work with people who want to learn and grow and learn and do different things, which means, like, if I put out their job listing must have built this before and I’m going to get the wrong kind of people.
00:15:02 I want people who are pushing themselves and who are learning new things, not just people who can check off, checklist, gosh.
00:15:08 I still have, like, a special place in my heart for all the mentors that I had at my first job because they really helped me understand what it’s like to work at a big company. And if that’s done well, you’re right, they will be like advocates for you for a long time, even if they move on to other jobs. Okay, so number that was number one through three. Number four, I am not confident that we can make you successful in this role at this time.
00:15:33 Yeah, what’s that as a flip side of being able to being willing to invest in people you have to be realistic about. So here’s an example. We hired some people who are to be remote on our team, and it turned out we were not in a place where we could make them successful because we had not changed. We were too young. We weren’t in a place where we really knew what we were building yet. We expected people to be able to kind of figure that out for themselves.
00:16:00 And we finally realized that we couldn’t actually have a distributed team until we were large enough that we had structure and management so that we could kind of have more formal communication channels. We also hired someone who was very junior just out of boot camp. And after three months, we realized we didn’t have enough junior work for that person to do. Everything we had to work on was too difficult, and we were trying to pair with them, and they weren’t learning fast enough. And we weren’t able to sacrifice that much of our engineers time to pair with them full time. And we just ultimately realized we were not in a place where we could take someone who is that junior. We could take people who had one job before and make them successful, but we couldn’t take people straight out of boot camp. We hope to be in a place where we can do that maybe in 2020, but it doesn’t actually do anyone any favors to take a risk on someone when you don’t have a plan for how to support them and when you aren’t sure that it can, you know, if you are pretty sure that it will work out. And this involves a lot more planning and thinking through than I think most companies do. I think a lot of companies just kind of, like hire, drop people in the mix and kind of sink or swim and I feel like that leads to a lot of unnecessary churn. I think that it’s kind of management’s job to think through.
00:17:19 What are the minimum requirements for this? How much support can we give this person if it’s a person who like, on the flip side, I was saying I don’t want to just hire someone who can do the same thing over and over. But if it’s a person who has done none of the things that we have and we’ve done this before too, we’ve hired someone whose specialties were just none of them were good engineer at what they did, but not. And after six months, I think it was a very frustrating experience for him because he was not used to feeling like a complete Nutter noob, who wasn’t really contributing for so long. In so many ways, it was a challenge for us too, because we were just like we hadn’t really counted on it taking that long and we were doing our best to be supportive. But since then, I think that we’ve tried to think much more clearly about the amount of support, the type of support, and is it what we can afford in exchange for the value that we think that they will be able to bring and how long we can wait for that value to be realized? I’m a big believer that anyone can learn anything like that’s not the question. Anyone can learn anything that they need to learn, but there’s a limit to how much they can learn, how fast, and it’s very taxi. You really want them to be contributing something of value at the same time as they are learning, so that it’s better for them because they’re not just going to feel like a Leach. It’s better to have something that you are good at while you are feeling like a complete beginner in these other areas. So this is just bears thinking about.
00:18:39 It is interesting. I like the idea of thinking about if there are skills the person doesn’t have and you’re willing to have them learn, but you don’t have anybody to help them learn. That that’s difficult. Some people that really like to have their work sort of chopped up for them to say, hey, I need you to do this. I need you to do that and this other thing. And there’s some roles that there’s nobody to do that. You just have to jump in and say what’s needed. I need to go fix it.
00:19:05 This is an area where I think we’ve basically come down the side of the first person that we hire in any given area needs to be pretty senior, pretty entrepreneurial, pretty not terrified by chaos, but just have the instinct to go in and start fixing things, bring water where you can, and not get too bothered about stuff. This is all related to one towards the end, which was just hiring people who are comfortable, who really want to work at startups, but we’ll get to that.
00:19:30 Well, let’s jump ahead then. Number five is the team needs someone operating at a different level. That just sounds like you’re not good enough. But that’s not what you mean.
00:19:38 It’s definitely not because I would actually say that we have declined more people for being too senior than being too junior.
00:19:44 Yeah. So different level isn’t just you’re not high enough?
00:19:46 No. Because in any team there’s only so much principal level, architect level, very senior work to do. Most of the work that needs to be done. It’s just stuff that you just have to chunk through. Right. And if you have a bunch of engineers who are way overqualified for what you need from them, they’re just going to be restless all the time. They’re not learning and growing either. At a company like ours where we need everyone to be contributing full time, we have to be realistic. There isn’t enough senior level work. We need intermediates who are still energized and excited by building stuff out. The team needs someone at a different level. And that has to do with like someone can be junior in some areas, intermediate in some areas, senior in some areas, way over qualified in some areas. Right. And so you just kind of have to look at where the team you have and what you feel would really benefit them. Is the team spending a lot of time on CICD and funneling around, set up. Do they need like an opsy type person? Do they need a Toolsmith, someone who just loves internal tools? Maybe that’s what you need. Or if you have a team that’s got a lot of senior folks and there’s a lot of egos kind of in the room or something, you probably need someone who’s more mid level. Maybe somebody wants to be a manager on the team. So you really want somebody who they can take under their wing and practice their people skills on. Maybe you need someone more junior but who brings a lot. And if you need someone more junior, what kind of junior person do you need? Do you need a very thoughtful junior person who isn’t going to like wreck things?
00:21:11 That was problem in SRE land, right. Where you hire someone junior, but you need someone with the right temperament who’s not just going to cowboy everything. Do you need someone who’s just like junior but fast can turn out a lot of code and turn around things really quickly. Like, I’ve met some juniors like that. They don’t know what to build, but if you point them in a direction, boy will they go fast, right? That can be great to have a couple of those people on the team. Our tendency that I try to lean against, our tendency is always to hire more people like us when in fact we should be doing the opposite of that. We should not be hiring people who are strong when we’re strong, because we’re already strong there. We should look for people who compliment as well.
00:21:45 That’s the one that I and I think everybody else struggles with how to interview for that to be able to recognize skills in areas that they don’t have those skills. Number six, we don’t have the kind of work you need or want. This is very painful to actually, I’ve had to not hire somebody. That was awesome, but I knew they wouldn’t be happy with the work I had for them.
00:22:03 Yeah, that’s a real tough one. Sometimes they’ll agree with you and sometimes they won’t. There have been people who have wanted to work here with us. We’ve hired some of them. Like the one I was talking about before, the very senior engineer. He was just like, I’m so sick of working for white dudes. I just want to work for somebody who doesn’t look like, just like me, total sweetheart. He was a hardware engineer, security person. We need someone who’s just, like, straight up, full stack web stuff and database. He was, like, trying very hard and working a lot, and it wasn’t what he wanted to do.
00:22:33 I just watched over time, and I was like, this was a mistake, and he ended up leaving, and it was all good. There are other times when someone is wanting to join you because they’re hoping that a position will open up that is more what they want to do or they really want to do management, but it falls under the good problems to have that. Lots of engineers want to work at our company because Dev tools, it’s like catnip for engineers. But a lot of times the reasons for wanting to work with us are ones where we just were like, I don’t know if I feel good about this, because I don’t know if I can give you what you want.
00:23:02 Number seven is communication skills. This is a big one, although they might not hear you when you tell them that. That’s the reason.
00:23:10 Yeah, that’s true. We select very heavily for communication skills. In fact, the technical part of our interview is the night before we’ll send you a piece of code for you to spend an hour, no more than two, please, like just extending it and improving. It like adding some small functionality. And we intentionally don’t want you to make it better. We don’t want it to be finished. We just want you to make some improvements and add the small functionality. And if there’s more you want to do, just kind of make a mental list of it, because that’s not the interview. The interview part is you come in tomorrow and you sit in a room with a couple of your peers and just talk through it like, why did you do what you did? What did you consider doing? What other things might you have done? What are the trade offs that you thought about and we’re trying to make it as much like a code review as possible. We just want to see how you think and communicate about technology. I always believe that if someone can communicate how to solve a problem, they can get it done. Like, no question about it. And the reverse is not always true. If people who can engineer and build things but can’t actually communicate about how or why they did it, they are great engineers, lots of them, but they’re not right for our team.
00:24:15 I believe that the way that high performing teams are made is by communicating and learning from their mistakes. And so I really value communication.
00:24:24 There is some of that people that communicate well, it shows up in more clear code as well. If you can coherently speak and write, then your code might be better. I don’t know if that’s universally true.
00:24:36 But it seems right if you can communicate about it and receive feedback. Like if in the code review feedback. If you’re given feedback about stuff and you aren’t getting defensive, but you’re interested and curious and you’re receiving it and everything, that certainly leads to you having better code.
00:24:51 Okay, number eight is you don’t actually want to work for a startup.
00:24:54 Yeah. So many times, like, I’ve interviewed people at Google or Facebook or whatever, they’re just like, yeah, I really want to get to a startup and you ask them what they value, and it turns out that they really need everything to be predigested for them. And they’re just offended at the idea that something might change or something might not be clearly defined. If you start asking people about process and it’s super clear that they unsettled by the idea that they might have to figure something out, these people don’t want to work to start. And the first time I wrote this, I wrote it kind of sloppily. And I wrote that the bad signal was that people were so focused on they want life work balance and work from 95 and all this stuff. And I will defend myself by saying that that is what they usually say.
00:25:35 That’s always what they say. But I value work life balance, too. I value everyone who works here having a very good life and on call, not being rough and all these things. I value that highly. But I also know that it’s a start up and things are unexpected and they change and people who are not going to deal with that well are not going to really thrive here. And the way that I wrote it made it sound like I didn’t value work lifestyle. So I rewrote it. And I tried to emphasize that when people say that, it’s a sign for me to dig in and ask more questions and find out if it’s really about work life balance or if it’s about the kind of depend on this giant apparatus of stuff supporting them before they can engineer.
00:26:13 I get both the flavors of that. But also a large company might be kind of like what you’re describing as a startup, because a lot of large companies are a lot of tiny teams put together.
00:26:24 It’s true. I was at Facebook, and I think that what got to me after a while was it’s not that, yes, things will be canceled out from under you all the time, but you learn to not care. Like, you learn to kind of separate yourself from your work. And like, you check in to work and you check out at a startup. There’s an element of we’re all in it. We also personally responsible for this. When we were trying to raise over the summer, I know that a lot of our engineers, I did not ask them to I did not want them to cancel their vacation to put that off, but they did because they didn’t feel comfortable leaving while the company was really trying to. That was endearing and broke my heart a little bit. But every single person here is invested, as I guess how I would put it. And when you’re investing, it’s different.
00:27:04 Got you. Well, we all want that. No matter what the size of the company.
00:27:07 We don’t all want that.
00:27:10 No.
00:27:11 What I have learned is, no, we do not all want that. Lots of us actually really just want to not have to feel personally responsible. I don’t know. I feel like it’s because they got burned at some point. And I think that everyone is born wanting ownership and investment. I think that over some people’s lives, they get burned and they get.
00:27:30 I think you’re right.
00:27:30 Yeah.
00:27:31 Okay, I’ll clarify. I really want to work with people that are invested in their job.
00:27:35 Right so much. Yes.
00:27:37 Number nine is you just want to work for women.
00:27:40 I’ve been surprised how many like, there’s a real unmet need in Silicon Valley right now for people who just want to work for women. It’s so weird. But there are so many people who are just like, oh, my God, I just want to not work for another dude. And I’m kind of like, that’s sweet. I guess. I don’t know. It’s kind of like somebody going, I want to go on a date with you because you’re a woman, you know, I guess things. I don’t know. But it’s fine with me if that’s what caught their eye. Right. But I would like them to have done some more investigation or found some more things, much like being asked out on a date. You want to be asked out for you and who you are and what you’re interested in, not for the gender that you happen to have been born.
00:28:17 That’s a funny one. I think we’ve already covered it. But the number ten is, I truly want you to be happy.
00:28:22 Yeah. I always want it to be mutual. Like the times that I’ve had to let someone go or not hire someone. I always feel like, man, we can see the same thing, right? Like you’re not happy here, you’re not thriving.
00:28:36 My first instinct is to talk through it with them. Just be like, you see this too, right? But I will occasionally overrule them, be like, this isn’t working out because of XYZ.
00:28:46 But it’s always kind of sad to me because I do want the best for people and I feel like it’s never the best for them if it’s not the best for us, right? Like they should be somewhere where they are valued. What they have to bring is what is needed. And there should be an enthusiastic consent on both sides, not just, well, they’ve been here awhile.
00:29:05 You wouldn’t want to be in a relationship like that.
00:29:07 Yeah, exactly.
00:29:08 And of course the perfect number eleven is that I’m not perfect.
00:29:12 I have messed up so many times not hired the person or hired the person. It was wrong and I will again.
00:29:19 I have as well. I guess. Enough said on that. But it’s just a really great I think it’s a good thing. One of the reasons why I wanted to bring this up is I think it’s good for people looking for jobs to think about what it’s like to hire somebody. It’s not easy either. And I think it’s good to think about the reason why you’re not hiring somebody and try to I think these are good buckets to have to say, I don’t think I want to hire this person, but why don’t I want to hire them and be able to say that? And nobody wants to have like the 19 reasons why I’m not hiring you individually. One is enough.
00:29:52 Yeah, I would like to encourage more hiring managers to be less scared about communicating.
00:29:58 You can ask if you’re not sure if the person wants it. Sometimes I’m not sure if the person wants to hear it because sometimes people can be in a space where they’re kind of fragile and they don’t want to hear. So you can ask, would you like to know why? But I think most people there are way more people who are hungry for information that they’re not getting than there are people who are upset about the amount of information that they’re getting.
00:30:15 I guess before I start putting these into place, I need to talk to my HR Department and find out if there are rules around whether or not I can.
00:30:21 People will always be like, no, don’t because it opens you up to legal, blah, blah, blah, blah, blah. And that’s bullshit. Sorry, you can give perfectly true unless you’re telling people, Well, I didn’t hire you because you’re Indian or I didn’t hire you because you’re a woman or something. In that case, yes, absolutely.
00:30:35 Don’t tell them. And also don’t do that. Right. But if it’s for a real legit reason, it’s either about the team dynamics or about the person. I think that HR is too.
00:30:45 Like, they’re always just trying to save the company’s ass. And I’m not actually thinking about what’s best for the ecosystem.
00:30:50 I like it. Any closing thoughts that we haven’t covered?
00:30:52 Mostly just I want to reiterate everybody higher. Juniors, if you can. They’re worth it. They will hustle, they will get up to speed. They’re worth investing in. And PS, five years does not make you a senior engineer.
00:31:05 Now, I got a couple of follow up questions like, let’s say you hire somebody and it’s kind of a mistake and, you know, that’s going to happen sometimes. Do you have put in place, like, I don’t know, Grace periods or something that you’re going to evaluate whether it’s working?
00:31:19 Yeah, it’s like a 90 days. I don’t know, remember what we call it or whatever. But it’s just the acknowledgement that you’re not going to know until you try. And honestly, the more senior person is, the more I think that it’s hard to know because they’re going to be able to answer all the questions, which is why I’m a big fan of for senior people, where possible, offering them a contract to hire. Like try before you buy. Like, we’ll come up with a project, you can come and sit with us, commit to a month or two. And if everything’s great, because the more hire and if not, like, nothing will pay you, et cetera, and no harm, no foul. But there’s just a feel of working someplace that you can’t really get. You can’t get that. And the more senior you are, the more you realize that people are everything.
00:32:05 And some people are just your people and some people just aren’t.
00:32:08 Yeah, I think those are all good. This is all great advice.
00:32:11 One last thing. You really do have an obligation to. So I believe in opening the barn door wider and taking more risks on people.
00:32:19 I really strongly do. But you have to pair that with a commitment to when it’s not working out, you have to pull the plug sooner than we do. Right. We always wait too long to fire. You owe it to your existing team. It’s very demotivating. When they see somebody who’s not getting work done or who’s not really there and not contributing. It’s very demotivating. And it will bring down your entire team if you don’t kindly stop soon.
00:32:46 Yeah. The sooner the better.
00:32:47 The sooner the better. Everybody always knows. It always happens too late. Yes. Give people an opportunity to improve. That’s what that 90 days thing is about. To me, it’s about once someone has been there for a little while, you have a real obligation to them, to people have ups and downs in their lives. People go through things. Nobody is like participating in 100% all the time. So somebody struggles or has a rough patch. I’m not saying get rid of them because, no, we carry people through periods like that. But for the first 90 days they’re going to be on their best behavior. They’re trying their hardest everything. So if you can tell that it’s not working even then just eject just pull the rip cord.
00:33:23 I guess that also sort of highlights that you need to be in a place where you can’t be paying attention for those 1st 90 days.
00:33:28 Yeah, it really does.
00:33:29 Hiring somebody in a crunch period where nobody can help them out and nobody can pay attention to what they’re doing is not a good idea.
00:33:36 No, it’s not.
00:33:36 This is so fun. So thanks for coming on thanks for having me.
00:33:41 Thank you to charity for taking the time for this interview and for being so open about the hiring process. Thank you pie chart for sponsoring this episode. If you value your time, try pycharm at testandcode.com PyCharm that link is also in our show notes at testandcode.com. The show notes also have a link to the article discussed in this episode. Thank you to Patreon supporters keep me motivated. If you want to become a Patreon supporter or sponsor an episode, head to testingco.com support that’s all for now. Now go out and test something.