guidance counselor 2.0 · episode 54
w/bill isreal at built technologies
key takeaways
- mix team levels with seniors, mid-levels, and juniors; don't go too top or bottom heavy
- let senior engineers own decisions and use you as a sounding board, not a gatekeeper
- juniors need to struggle for an hour before asking for help; don't hand them every answer
- in interviews, care way less about junior code quality and way more about enthusiasm and questions
- screen for personality fit and team gaps first; you can teach python in weeks but attitude matters most
listen or watch
listen
about this episode
how to hire and scale engineering teams by balancing mentorship, personality fit, and attitude over pure technical skills
If you like what you hear connect with me...
Website
full transcript
auto-generated from the audio, so expect a few typos. the audio is the source of truth.
I have a special guest today. I'm having more guests trying to branch out. So I don't run my dang mouth for the whole 20 minutes. I have Bill Israel. Bill, thank you for coming in, man. Hi, it's my pleasure. Thank you for having me. So I just got the notification that LinkedIn is live. So we'll wait a few more seconds. People trick-in-a-win. Add us, comment. Let us know if you're tuning in from. I know Bill would love to see a beautiful face. And again, the whole point of this is obviously it's to allow people to network and develop community. So again, please comment, please network.
Please sign up to other people's DMs. And just obviously reference this show. Bill, before we get started today, and for the people around us. So we're doing a bedroom series. We're doing guidance counts with 2.0, the cribs. So we're both reporting live from bedrooms. Yes, Bill. Thank you for making sure you're bed this morning. I appreciate it. Thank you. I make it up. My bedroom is my office, unfortunately. And so I make it up every day because the last thing anyone needs out there on the internet needs to see is my messy bed. So here's my question. Are you a bedmaker normally or not? Yes.
Yes, I am very much a one of the first things I do in the morning is make the bed for sure. I knew I liked you the moment I met you because bedmakers, all the bedmakers out there, please comment, all the people who are OCD, please comment now. And we can all be friends. Kathy, good morning. Thank you so much. I appreciate it. Tasha, what's going on? Andrew, what's going on? Andrew, I got your email about mics. I will get back to you a little crazy right now, but I will get back to you. Thank you for your email. We'll go ahead and get started again.
Thank you all for joining the guidance counts with 2.0. The whole point of the show is to develop community foster and environment where people can learn from others. You learn from Bill today. I'm very excited to have Bill on. I'm going to let Bill introduce himself here in a second. But again, want to give some shots to my team, Brandon R.A. Brandon 78, shout out to them, who's doing a ton of my marketing efforts, shout out to Alex Poole or Noah Allen, Ambionka as well, my marketing team around me, Sam Green. Hey, Bill. And so all that being said, Bill, interest himself, and then we'll dive in.
Absolutely. My name is Bill Israel. I'm an engineering manager over at Bill. I've been there a little over two years. Two years back in, well, I would say back in April, like that wasn't four days ago. And then see before that, I was at Eventbrite and a couple of small startups in town, studio now, and spend some time with you, if any of them remembers that one from about the 12 minutes it was around. And at Bill, I'm over the integrations team. So a lot of built technology needs to integrate with all sorts of weird banking systems. And third party APIs and that kind of stuff.
And I'm trying to help do that as much as I can. So that's awesome. Yeah. So Bill has like one of crap ton of awards. I mean, literally like y'all are the golden child of Nashville right now. Oh, thank you. Talk, or at least I think so. Talk, talk about Bill, what y'all do again, Bill is repping the built t-shirt. And you're like, hey, Bill, what do y'all do where your logo looks like a house? It's a B and it's also a house. So Bill does, well, we're sort of starting to do more things, but Bill initially started as a construction lending, like I call it group wear kind of.
The construction lending space is a very strange one. It's usually sort of a tiny, a kinder corner of the bank in terms of like number of people. And so it is a part of a banking system where not a ton of technology actually sort of gets snuck in there. And so it's the workflow there is a lot of spreadsheets and emails and phone calls and it's slow. And it kind of error prone a little bit. And so gosh, I have six, seven years ago or so, Chase and Andrew sort of co-founders decided like this could be better. There's construction's huge tons of money in construction.
And it's people kind of don't know where all of it is. And we can just do this, we can do this better, we can make it more efficient. And that's kind of what Bill initially started as, right, was getting those lenders and the owners and builders and inspectors all kind of in the same system. So they're all, they all have the same view of the data at the same time and can draws and things can get out faster, money can get from the bank to where it needs to go to the contractors and those kinds of things. Just significantly faster and more efficiently. And that's kind of where it started.
And obviously the plan is always to grow outside of that. But so we've been six years on that train and I would say we're killing it. Well, and you are. And that's, and I wanna go and dive into the meat and potatoes of this talk. So what you also do, it's been really cool. Because I got back to Nashville from Raleigh six years ago. I have literally seen y'all absolutely explode. And it's really cool. Bill's got a special place for me because obviously we've been a part of helping you staff up your teams and obviously, you know, place a lot of people with y'all. And it's been cool to see y'all gross.
We can congrats to y'all. And that's awesome. Let me, let's dive into why I brought you here this morning, which is hiring and scaling. Right. Yeah. So one hiring we could talk about that for the next hour. We're not going to because we all have things to do. And then also scaling teams is probably another hour as well. So we're gonna try to condense this in the next about 10, 15 minutes. Go first off, talk about maybe some things. Companies should be mindful of kind of your principles and your thoughts when it comes to scaling organizations and teams right now. And I want to give you a shout out live about hiring junior developers.
Yes. Talk about maybe hiring junior developers and scaling, how are you guys are doing it so effectively right now? Sure, sure. So scaling teams, especially teams, is tough. Scaling and hiring senior talent is even harder. And so one of the things that we try to do, we try to be really good about is growing people within the organization. Certainly on my teams, I can speak most specifically for my teams, but I believe that it generalizes to build. It's generally better to take someone who's more of a mid-level dev and sort of train them up to be a senior and then hire junior and just sort of kind of constantly cycle that out.
Because once they've got to get up to a senior, maybe they go somewhere else or maybe they just go somewhere else within the organization, which is really the hope, honestly, is that they take what they've learned from my team and then kind of help apply that in other areas of the organization. And so scaling teams is I sort of aim for a good mix of developers, right? I don't want to be too top heavy with seniors. And I don't want to be too bottom heavy with juniors. Both of those are kind of a drag in different ways. And so a couple of seniors who can kind of help the people underneath them and a couple of juniors who kind of on their way up, learning seems to be a good mix and works really well for us, works really well for me, too, again, specifically.
Scaling teams and how you sort of figure out how to break up this group and that group, that's going to depend a lot on the business. It's kind of hard. And really, the only advice I can have there is you just sort of have to try things. Break it up, see what works. Give it time. I think there's a lot of desire for to make a change and then see it happen, see that change happen immediately and see it be effective. But it takes teams, especially if you're shuffling people around, it takes teams a little while to Joe and kind of get into that groove with each other.
And so don't expect that to happen immediately. Yeah, absolutely. And so my question to you is, so let's do Bill's principles. So for your team, you have been able to scale your team very well. What are some just core things that you believe in? So let's take Bill to add in it. What are some core leaders and principles that you believe in that you think has really helped you scale within your team? Let's see. I'm not the world's greatest delegator necessarily, but I am one. I'm working on it real hard. And so I think letting the people closer to the work make the decisions. And then mostly have a dialogue about where that decision came from and why that's the right idea is super, super important, especially for your more senior people.
They want to feel some ownership. And I think you get better work out of people and better product out of people if you let them own it. And really just use me as sort of a sounding board or help figure out if we're headed in the right direction or if that matches organizational direction, strategy, policy, whatever. As for juniors, it's strange as this sentence may sound. You got to let them struggle a little bit. Don't hand them every answer. Go off on your own and figure it out for a little while and just try to make it work. And don't struggle forever. I don't want juniors, especially new people to write out a software tool.
I don't want them to sit out for days at a time, just a drift trying to figure it out for themselves. Go figure it out for an hour. And if you get to a point where you are making no progress, come ask me. Let's talk about it. Let's sit down. Let's either do, I guess, these days. Let's hop on a Zoom and do it and share a screen and point at some stuff. But it's hard not to feed people the answer. Because if I know what it is, I just want to help them get through it. So let them struggle a little bit. And then give those people, the seniors, the mid-levels, those people give them the opportunity to do the mentoring and do the work there.
It's all about reps, kind of. We talk about just getting that stuff in. And as those people interact more and learn how each other communicates, thinks, works, et cetera, the team honestly just gets more efficient. They kind of know what this person's going to do and what that's going to look like, what feedback works, what doesn't. And it has sort of this weird snowballing effect. And don't be too hands-on to my core energy. I mean, maybe that's too obvious. No, I mean, and listen, I'm at a point now. I mean, we're growing like, driving the markets bonkers. And I'm kind of in this kind of flux role as well.
And I think one thing that I try to keep in check, I think we as humans are inherently selfish. We want to control what we can control. And kind of have this grasp around our work. It's mine. I mean, listen, Bill, I mean, you've been a bill from the get. I mean, you've developed a large part of the code base. It's your code. You don't want anybody to go there and blow it up. I'm assuming. And so you're probably like, that's my baby. Don't mess it up. It's so good. I have to. To grow. You do. Yeah. You've got a pride and ownership there is really that's something that I try to preach just probably the wrong word.
But I try to hammer on pretty hard, especially with people just out of software school. It's like, you are not your code. Code is going to change over time. It's really not a big deal. If somebody tells you that that's wrong, they're not telling you that you're wrong. The code is wrong. That's OK. We can change the code, not a big deal. And yeah, you kind of get used to that a little bit as you have been around it more. It never feels good to watch somebody take something that you labored over real hard and just blow it up and tell you that it's all wrong.
But you do. I don't know. It's part of the gig. Absolutely. Absolutely. Or to have to swallow your pride there. I know. I know. So let's talk about interviewing for the next minute. So interviewing is a thing that I think everyone sucks at for the most part. No one gets it right. And you can't be tied to your people if it doesn't work. Be open and honest. I mean, I have thoughts as well. But I want to hear yours. We've worked with y'all for a bit. I think our process is good. I mean, my argument is y'all can move faster. But y'all are hiring so dang much that it's kind of hard to do that.
So what are your thoughts specifically around interviewing? Again, the people who are watching this are going to be more on the job search. So if you want to give some tips as well. How does built interview? How do you like how y'all interview and then maybe some tips for people? Do you want to know specifically about how we hire or how I hire for example engineers? Or yeah, let's do that. Yeah. OK. I hire mostly engineers, which is why. So specifically, engineer hiring is real tough. Because there's a balance to be struck there between how much do you expect them to write code in the interview?
And how do you sort of appropriately respect somebody's time in those kinds of things? And that's just a really tough balance to strike. And there's really no way we try to offer, if someone wants to do it in a take home, if a live coding session is just a real stressful thing for some people, then great. Take the code home. And we're going to have a slightly different conversation because you had the privacy of your own home. And the time constraints were different. And the pressure constraints were different. So we're going to have a slightly different conversation about the code you wrote after when we get back together.
But we will always get back together and talk about it. And if you choose to do it live, then my expectations are slightly different because the circumstances and context are all different. What I look for in a senior, I give typically, you give juniors and seniors the same problem. And what I look for out of those solutions coming out of those people is just vastly different. I would expect and hope a senior is having a more long view of the changes that they're making and why it might be important. And a junior, I'm really honestly, mostly, I'm really way less interested in the code that they write and far more interested in their enthusiasm and their desire to sort of learn and the questions that they're asking and that kind of stuff.
Hold on, hold on, hold on, hold on. Yeah, we'll have a more time. Because I get so many junior devs like, hey, how do I work on an interview and how do I get better? What about my code? Say that one more time for all you junior devs who are walking out or who will watch this, build just said it, build say it again, that's what I've been saying for. Especially for juniors, way less interested in the code that they're writing and far more interested in their attitude, the enthusiasm, the questions they're asking, that kind of stuff. Junior devs, this is gonna sound bad. Junior devs are all saying, right?
Like they're basically all the same. They don't know anything and that's okay. That's exactly the way that's okay. Like the goal of a junior dev is not for you to come in and know everything. I don't want you to know everything. I want to help you learn. That's the fun part for me. For junior, it was like helping those people learn to get better. And so what I'm really just looking for is somebody that I'm gonna get along with who's got a killer attitude and who's excited to do the work. And I think that generalizes probably to, not just engineers, that's certainly not true of just engineers.
That's generally true state when I think. You know, again, my purview is mostly in engineering. So online y'all's interview process from the get. So you usually do a 30 minute phone call. Yeah, yeah, we usually, it kind of depends on the person but sort of like where they are gonna be. But for, again, for engineers, it's usually a quick phone call with me just sort of sanity check stuff, ask some basic questions. It's mostly background, honestly. It's really not as much technical stuff. And then we do some sort of technical challenge. Again, whether it's take home or in person, it's kind of up to whatever the person's most comfortable with.
And then we'll, if it's a take home, we'll have a get back together and talk about it. We won't get back together and talk about it if we're doing it live. We'll just do it then. And then it's a quick interview with the team just to make sure everybody kind of gets to know everybody and the team that they're gonna be on gets a chance to ask the questions that matter to them. Sometimes there's an executive interview, right? Sometimes the CTO wants to talk to people. Sometimes they don't, especially as they get further up their ranks. I think it's more important for an executive to talk to them.
And that's it. It's not a huge process. It doesn't take terribly long, usually within the first, first two interviews. We know everything that we need to know by and large. Right. So the one thing I see after meeting this point for 5,000 engineers at the point of my career, I've obviously talked a lot to about interviewing and whiteboarding and coach having a lot of coding and all of that is already. So let's talk about that real quick. And we'll wrap up on this. And again, for those of you who are watching, thank you again. Again, I haven't really shouted out, Kathy of the Bed making Sow, Sow, You're my boy.
Yes, I've made bed first thing. Sow and thanks for joining. Tasha, you were obviously smiling with something Bill said, I don't blame you, I've been smiling the whole time. So it's built in on Sow, build your unicorns, absolutely not to mention unicorn finders, humble brag. And then obviously love the struggle. Yeah, so real quick, I didn't have it set this. It won't get back to my last question on interviewing. I'm a big college football fan, specifically the University of South Carolina where I graduated from, go game cocks. We have hired a completely new staff. And I've been fascinated with the culture and the building and how it shifted.
There's been a lot of conversation within the building of like where the culture was and what it is now. Our strength and conditioning coach, his saying is called struggle well. Yeah. And it's like we in life, it's not a journey. It is a journey, but you have to know how to struggle and enjoy the struggle and struggle well. And that's one thing that resonates with me is like, listen, you have to be okay struggling. As a junior dev, you have to be okay, not being okay. Yeah, yeah, it's honestly, it's all about learning how to find the information that you want and learning to sort of be, you're gonna pick up most of that stuff over time.
And a lot of things I hear from juniors are, I'm still not, I still don't remember this function or I don't remember where this thing is in the code. I don't remember where that stuff is half the time. Like that's okay, that's not a big deal. What you're really trying to learn is how to go find it. When you need it and the stuff that you really use all the time, you will, it'll just, it'll eventually just sink in and you won't even realize that it has happened. So learn, learn, learn to struggle, go find it. I love it. So find, so going back to the questions, last question about interviewing, what are your thoughts on why, like how can developers be better without going to look at a book?
I mean, what are your thoughts on, what do you like to see developers, not necessarily solve a quick question, but what do you like to see that developers can keep in mind, can take away from this? Be like, ah, Bele said this, I will approve on this. Ooh, um. In an interview situation, I would much rather somebody just tell me, like don't, don't be asked me really. I can, especially if you're sort of more junior, like I can smell it a mile away. I know, I know you don't know what you're talking about and you're just throwing out words you've heard. That's fine. It's okay not to them.
I don't know. I do as a recruiter, I just thought words. Yeah, which is great. Like, I think for your perspective, that's fine. Like for Virginia perspective, I'm just, just tell me you don't know. And then ask and let's learn it together. Like it gives me an opportunity to see what it's gonna be like to mentor you in that situation. And that's super fun for me. And so if you're looking for, if you're gonna get a whiteboard kind of interview, which I'm sorry if you do, I really hate those, then maybe spend some time on hacker rank or coder wars or something like that, just to kind of have a sense for some of those silly algorithms.
Like most of those tests are really just how well do you know what off the top of your head anyway? Is that what I don't know why board, is why boarding mainly algorithms? Is that usually a hundred thing? Yeah, yeah, usually it is. It's usually like, can you reverse a string or can you do some sort of binary search thing? No, I can't. Most of, if you don't know the answer, you're probably like if you don't know going into it, the likelihood that you sort of just divine the answer in that moment is approximately zero. Under pressure in front of somebody, it's almost zero. So like just have a couple of those under your belt.
The other real trick honestly is use a hash map, use a dictionary of some kind. It's the answer to almost every single interview problem you'll ever come across. Hash map, yeah, maybe this is too nerdy. Probably is. There's no trick to interviews. Interviews are different everywhere. The real trick is enthusiasm, excitement. And being honest about what you know, what you don't know, ask questions, getting in there. Like that's the real honest answer. The other stuff is just depends on the place. And if a place says no, you probably weren't gonna be that happy there anyway. Like it's probably not the place for you. It's almost like I know what I'm talking about because this is what I've been preaching.
Go find somewhere that is excited to have you there and that you're excited to be there. They're not excited like, move on. It doesn't matter. What do you want to say? And again, I want to ask you this. And then we'll wrap up here. And again, I have a lot of people commenting. Tashiko's dude, I wish I had you interview me. Obviously not me Bill. I scored good on the I.K.M. but couldn't wiper to hold program. It's crazy what most of the fact. No Tash is more junior, accurate to keep when the company's make up their own. Like white boarding stuff is such a waste.
Yeah. Hash map for the win seriously. Andrew, thanks, man. Hash map with the Hash map child. Um, so what would you say? I feel and we'll end on this. I feel like companies try to screen out instead of just say, hey, this person's good. Let's see where we can fit him in. What are your thoughts on that? Do you think that's like, I don't know. I'm interested because I just feel like companies try to beat people up. Oh, yes. I do think some companies try to beat people up for sure. Um, man, I'm so I'm sympathetic to both sides of this. Okay. A bad, a bad hire is so troublesome, not for just for the organization, but for the person too.
Um, right. Like it's just, it's just bad all around. It's, it's tough on the organization because they spend tons of time and money and everything else trying to find the right person. If that person is a tough fit, then that person's miserable because they're on a team that they're not fitting in with and they're not doing a good job and that everyone's trying to like get the whole thing to work. And if it's just not going to work. Um, but I do think people, I do think how many companies probably screen out too fast. Yeah. I think, and I think that's kind of the problem, right?
Like if I get 200 resumes for a junior position where they all kind of look the same, it's really, it's really hard. And so I do, I do have to just kind of make some hard rules there and just say this is what, this is the stuff that I really care about right now. Everything else is going to have to go because I have to whittle it down. Once you're talking to people, it's a, it's a real different ballgame. And you really sort of have to dig a little bit harder and try to find like what, what are the personality qualities? What's missing on my team that I'm trying to fill in and that isn't always knowledge based, right?
That is, that is oftentimes personality based. Um, you know, I've got this person who's kind of quiet over here. And this person who's a little more sort of gregarious now going, can I have someone in the middle who might bridge that gap a little bit who might be, you know, because these two aren't getting along, how do I find someone who's going to keep the whole thing together? And, and so it's, if you're really screaming just for knowledge, that's probably not the right answer. And I think a lot of people and a lot of organizations do that in screen just for what do you know, what will you know walking in the door?
And I can teach someone Python in a couple of weeks. Like it's not a big deal. Um, so I don't care if you know Python or not, but if you're going to fit on the team and you're going to sort of fill a niche that I don't have. And your attitude's great. Yeah. And then get on my team. That's it. And I want to end on that because that's perfect. Yeah. I think companies who are watching as high managers who are watching is there's a reason why build is successful, not only because obviously they're software and the industry and the capitalized. Not, that's it. I have watched build from an engineering side.
There's a reason why they retain top talent. There's a reason why they're always hiring for growth. There's a reason why bill has been there for so long. It's because of that answer from Bill. I think when companies can make can put a more focus on the people side of things and so the tech side of things with the tech being important, I'm not saying that's wrong. It's not, it's not nothing, but right. But I think that's where the magic happens. So Bill, man, thank you for coming on. Look at this. Oh, man, I love it. Oh, my God, my COVID hair. It's also jealous. So jealous.
Oh, please, it's terrible. My wife's on me about getting a haircut. So I think it looks great. You can tell your wife. Oh, thank you. Absolutely. I'll tell her that Taylor told me it was okay to keep it. Who did that? Heck is Taylor. Yeah, thank y'all for tuning in today. I appreciate it. Reach out to Bill on LinkedIn. Please. If you're on the NASDAQ, I know Bill's on there as well. And again, Bill, thank you for coming on, man. And I really appreciate it. Thanks for having me. So this was a blast. Come back anytime. The bedroom edition. Y'all have a good one. Exactly.
Bye, Taylor. Thank you.