FounderQuest
FounderQuest
How to hire great software developers when you can't compete on salary
Full Transcript:
Starr: I was in my car. So there was no-
Josh: There was no, it like it wasn't that creepy.
Announcer: Hands off that dial. Business is about to get a whole lot nerdier. You're tuned in to Founder Quest.
Starr: Yeah I mean ... but also like this is Seattle, so literally everyone here is a quasi-tech celebrity.
Josh: That's true.
Starr: Yeah, it's dime a dozen.
Starr: So this week, we have been not getting much real work done. We've all been super distracted because we've been really focusing on hiring.
Josh: When you say, "we've been working on hiring," I think what you mean is "Ben's been working on hiring."
Starr: What's the point of being in management if you can't take credit for other people's work, right?
Josh: Exactly.
Ben: Exactly. That, and you got the whole royal "we" going for us, so gotta ... Yeah, it's been a bit of a slog, so. But it's been kind of fun too. Like, you know, we decided a few months ago, I guess, that we were about ready to hire and, you know, we've been thinking about this for a while. We've had contractors helping us from time to time. And we just decided it was time to have someone who could be around to the long haul. And so, we started the process of just thinking about who we wanted and what we wanted. And I had just ... it was pretty good timing ... I had just seen this blog post about hiring, and about what job posts should look like versus what they usually look like. You may have seen this on Twitter, but like there was an image where it was like colored red and green, and the red was ... it was mostly red ... and the red were parts about the business, and the green were parts about the candidate.
Starr: No, I didn't see that.
Ben: Oh yeah, yeah, it was really cool. So, like if you're a candidate, like, what do you care about when you look at a job post? What kind of technology are you playing with? Things like that. What kind of benefits are you going to get? And so this person was talking about how most job posts are all about the company and nothing at all about the candidate, right? And so, I had just read that and I thought, oh, that's, that's good to think about. And so, I wrote our job post in a way that was more approachable for a candidate, like, what would a candidate really wanna see? I guess it's like Marketing 101, right? Speak to your audience.
Starr: Exactly.
Ben: I think that was, that was really helpful in getting some great candidates coming in the door.
Starr: I sent the job posting to Evie, my wife, and she was bowled over. She's like, nobody writes job applications like that ... er, I keep calling it an application ... she said, nobody writes job descriptions like this. Some of the responses we got from people were amazing, some people said things like, I can't believe a job like this exists in such an imperfect world.
Josh: Yeah, it seems like we struck a nerve.
Ben: Yeah, yeah. It was fun to write and it was fun to see those kind of responses come back from people. And I think that was critical because our budget was kind of low, and in fact, we even included the budget on the job posting. The trade off there was that even though the budget was kind of low, the benefits were pretty high. Specifically, people were very interested in having a 30 hour work week. That was-
Starr: Oh, yeah. Maybe we should, maybe we should, go through some of the, the things we put in the job posting. Some of the benefits, some of the interesting things about the job that maybe drew people, because I know a lot of people are always wanting to know how you can more easily hire developers.
Ben: That's true, yeah, you hear that a lot. And I think, one thing that makes it easy is you give developers what they want.
Starr: That's ... no, that's too easy. That's too simple.
Ben: We found that there are definitely a group of developers who have experience, because we said, we needed deep Ruby experience, and who are interested in playing with new technologies, because we said, yeah, we're looking at Elixir and playing with that, and who sometimes value their time over money because we basically said, we'll be happy to pay you a little less but we'll give you a lot more time, like you can have a day a week off, or you can work five hour days, or however you want to work that.
Starr: Mm-hmm.
Ben: And I think a lot of people underestimated just how much a developer values that flexibility and having some more time versus just always maximizing the dollar sign.
Starr: It seems like a lot of the developers that we got who applied were a little bit more experience. I know, I know that we were really interested in experience in general, but we got a really good crop of candidates coming in with some real deep experience in Ops, in Ruby development, so forth. And it just surprised me. So it seems like maybe once you've ridden the startup rollercoaster a few times, once you've put in your 80 hour workweeks, you realize that maybe that's not the best way to live your life and start looking for something else. And surprisingly not many other companies are offering that sort of package.
Josh: Yeah, one of the, one thing someone said during this whole process was um, the salary we were offering was actually a small pay cut for them. But based on like, the benefits and the actual, like money for time argument, they're actually getting a raise if they take this job offer. Because rather than like working 60 hour weeks for what they're making now they can work 30 hour weeks for a little less, but it's still a net win.
Starr: And I guess a lot of the times people don't consider that when somebody is working for Facebook making 200 grand total comp that they're not necessarily working a 40 hour week for that. Maybe some of them can pull it off, but I think the whole focus on hours is kind of disingenuous because really when you work an 80 hour a week, you're not at your best for those 80 hours. Like personally, I find that I can get maybe two or three hours of really hard work done, uh, before I'm, I'm just kind of dead and have to move on to easier things.
Ben: Yeah.
Josh: Yeah, yeah. If we're talking programming especially, it's just, yeah, I don't, I don't believe you can even get 40 hours of, of solid productive programming in a week. There's always extra time you need to get into that space.
Starr: That's why you need bureaucracy, so you can fill in the spaces. We had a couple of meetings in there.
Ben: I think that was another big sell for the job. You know, we were three developers. We've really, and I told this to people a lot and are in the phone screen I did, like we really maximize the lifestyle portion of this lifestyle business. Like we've tried to make this company a place where we love to work, right? Why not? Uh, if you can have your dream job, why not make it? And so we have, you know, we get to work on what we want to work on, when we want to work on it. And that resonated a lot with developers being able to work with other cool developers, being able to have the flexible schedule, being able to work on cool technology, being able to work on a product that's being sold to developers. Like, all of those things were, were great points that our candidates talked about. When they talked to me.
Starr: One thing that came up a lot was that people had really read Josh's the 'Badger Life blog post, which is a blog posts he put on his, his own personal blog a while back that just laid out our philosophy of, of business and life, and showed people sort of how we spend our time during a day and all that. Was that included in the job description?
Ben: No, that wasn't, but I think a lot of people got that because Josh included that in his tweet when he tweeted about the job.
Josh: Oh yeah, that's right. I did.
Starr: That makes sense.
Ben: But, uh, next time I think we'll definitely have to include that or maybe even throw that into a page on our site where people can understand what our philosophy is.
Josh: I have been thinking about, uh, bringing that in, in bits and pieces and in our various things we're doing. Even in some of the emails I've been sending to our, our newsletter list. There's a lot of like topics. I think we can break in, break out of there, That kind of covers some of that in more detail too.
Ben: Yeah, I think it's, it's definitely a mindful philosophy that's opposed to the standard VC backed startup rocket ship culture. Alright, we've, we've chosen not to take that road. We don't have the super fast growth. At the same time, we don't have the super high stress job. And I think that's worked out well and I think a lot of people are finding that's an attractive place to work.
Starr: And this is partially why we've waited this long to hire our first real full time developer.
Ben: True.
Starr: Um, I think we could talk a little bit about what were we looking for in like a peer, to bring into the company and work with us as a, as a developer.
Josh: That was one of the things that I brought up in the interview. I wrote a document that described all of the things that we were, kind of looking for in a person. And at the very top of the list, the uh, the TLDR was we're looking for a peer. That's kind of different from a lot of other tech jobs. When I say a peer, I don't necessarily mean an engineering peer, although that's part of it. I mean somebody who can look at our entire business, our entire product and work on whole features, from the point where they contact the user, all the way down to the database level and the backend stuff. I guess there's not a lot of jobs out there that, that involve that. One thing that surprised me that some of our candidates mentioned in their interviews, was that this type of full stack generalist position is very hard to find. Like, people who are hiring tend to want specialists, I guess.
Ben: Yeah, it's definitely a, a function of the company size, right? I mean we're, we're tiny. There are only three founders, plus we have Ben Findley who does our marketing stuff for us. And so anybody who comes on has to be able to wear a lot of hats and do a lot of things, because there are a lot of things to be done and very few people do them. And then I guess, as companies get bigger and bigger, they just have to specialize to be able to most effectively use those people.
Starr: This kind of slides into lessons that we learned from interviewing people. Like I learned a lot from talking to the different candidates who passed Ben's screening and just getting a feel for them. Also from there, uh, the, the code samples that we asked them to submit. Personally, I learned that it's almost as stressful interviewing somebody as being interviewed by somebody. Because when you're interviewing somebody you kind of have to be in control of the, the, the flow of the conversation. You have to direct things where you want to go, but when you're being interviewed all you have to do is sort of answer questions and respond in a good way. You don't have to control the situation as much necessarily.
Ben: Yeah. Some of the candidates that we, that I talked to in the initial phone screens, like I would schedule a call for about 30 minutes and just get a feel for the person and find out like what kind of background they had, what their interests were, why they are interested in the job. And I found that of those, the ones that I really liked and the ones that I recommended to move on to the next stage, where those who asked good questions as well. I didn't realize at the beginning of the process that I, that would be something I'd be looking for. But I found that those who did that, who were really thinking about the position and how they would fit in and asking questions around those topics, those are the ones I think showed a, an initiative and an interest that helped them, you know proceed onto the next stage. So TLDR, ask questions when you're being interviewed.
Starr: Yeah, I found that the people who really stood out for me were the people who obviously put in an effort to understand both the position and our company and our, our somewhat unique needs as a smaller company. And then to really tailor their applications and their interviews to those needs. We had a fair number of applicants who were very competent seeming developers, but it was pretty obvious that they just submitted the application on a lark. They did a drive by application. We didn't get any resume from them. Uh, most of their interviews centered around just sort of generic developer topics. They didn't really seem to latch onto the idea that what we needed was this type of generalist who could work on all levels of our product, uh, who could interface with the users and interface with the database.
Josh: So I think what we're saying here is that it's marketing on all sides.
Starr: What a terrible realization for a developer.
Ben: Yeah, you'd have to learn how to sell yourself. Obviously when you're, when you're the product that an employer is buying, right? You've got to sell that product the best way you can.
Starr: I don't think that people who-
Josh: Right.
Starr: Didn't really stand out to me didn't sell themselves. I just think they were selling themselves for a different type of position than what we needed.
Ben: I think a lot of the way we, we approached the process was laid back and kind of vague, kind of like the day to day business that we have. You know, we are three developers who work pretty independently and we take vague notions of what we want to do, or the place we want to get, and then we just make it happen, right? We don't have detailed specifications as part of our normal work day lives. And we took the hiring process in the same kind of approach, where like we, we gave a coding assignment, right? We asked people to do a simple task that didn't take very long. Um, but we didn't give them a lot of direction and that was on purpose, right? Because we don't have a lot of direction in the things that we do, and that person that we hire is not going to be getting a lot of direction from us because that's not how we operate. And so we tried to use that as part of the filtering process as well. It's like, well, let's see if our candidates are going to respond well to the notion of having very limited direction. And we definitely got a spectrum of experiences back from those code samples. It was really interesting to see that. And it was also fun to learn from the code samples that we got.
Starr: Yeah. I think we all learned a new variation of the regular expression, was it the match syntax?
Josh: It was like a hash.
Ben: Yeah. We had one candidate use a gsub, but the block that had a hash for replacements, and that was kind of fun.
Starr: Yeah, we all, we all went scurrying for the documentation and then were like, oh yeah, this is actually a real, a real live thing that we don't know. That's a, that's a frustrating thing about Ruby but it's also kind of cool, is that you can work in it for 10 years and there is still surprising things about the language that you find. You know, surprising and hopefully useful things.
Josh: There's a different way to do everything.
Starr: It's either good or bad depending upon your outlook.
Starr: The code challenge was pretty interesting to me. Did you have any real inkling going into this code challenge that we would get such a wide variety of responses?
Ben: No. You see I've done hiring in the past, many times, but this is the first time that I did like the same code challenge for every candidate how got passed the phone screen. And, uh, again, I got this idea for a blog post. I really didn't know what to expect, but the thing that was critical about the blog post and the thing that I learned was that it has to be the same. Basically the idea is you want to have the same baseline comparison. It's like when you interview people, you're having a conversation. You're asking questions, and of course there are like some questions that you want to make sure you ask everybody, but obviously the conversations are gonna to vary from person to person. And so you may, you may cover one topic with one person and not cover that with another. And, and so you don't always get a great, even comparison of each candidate.
Ben: But the code sample like being like, here's the thing we want you to do, here's how I want you to do it, gave everyone the same instruction. Everyone had the same opportunity to report back and that to me was really awesome and that we were able to see variation from person to person and compare them as equally as possible. Like I said, I gave pretty vague directions of what we wanted and I was surprised to see people go off in one direction and see other people go off in a different direction. Uh, you know, and, and all of them accomplishing a task. And eventually the pers, the one that we liked the most, happened to line up with the kind of needs that we have. Like, we're very customer focused as a, as a business. And so that particular candidate had the most customer focus kind of code.
Starr: Yeah. I think in his interview he mentioned that he didn't view it as a code challenge. He viewed it as a product design challenge, which I thought was a pretty useful way of looking at it. It's not like we intended it to be some trick question or anything. It's just some people chose to the answer the question in a way where it was obvious that they were just assuming that we wanted to see if they could do an http post, if they could code. While other people saw it as sort of a, a chance to show off their, their product design chops. And so went a little bit more in depth with it and when a little deeper. We gave them all a rough time limit of which to do it. With all of their responses, it seem pretty reasonable that they could have produced them in the, what was it, two hours that we set the limit for.
Ben: Yeah, and I think some of the key factors in that code challenge were that, one, the task was simple. We asked them to post a payload to Slack. Two, it was relevant to the kind of work that we do because we do a lot of integrations with Honey Badger and involve sending post requests to things like Slack. Uh, and three, it was there was timebox, right? Like you said, we set a time limit for two hours. And so, set that expectation, right? It's not gonna take you a week, it's not gonna take you a day. It's just gonna take you a little bit of time. And then finally we said up front, we'll pay you for your time. Like we just-
Starr: Yeah, that's-
Ben: We don't think it's fair, you know, to make people do work for free.
Starr: That's important, because we've all been freelancers and we've all had people try and screw us out of our time. And we don't, we don't want to be that type of person.
Josh: Um-hmm.
Ben: Overall I was happy with how the code challenge went and it gave us, the three of us, something to talk about with each, as we reviewed all of them together. What was interesting to me though, what I was kind of surprised about was, you know after we, so we did the phone screens, we had four or five candidates out of that who we sent the code challenge to, and of each of the, and we also had a second interview with each of those. The thing that I was surprised about was that in our second interview, where all of us were together and talking with the candidate, like we didn't really discuss the code challenge much. It didn't really come up like, you know, we were more interested in the fit for the job, answering their questions, getting to know them better, but we didn't really like dive into a code review, you know, of the code sample itself. I guess I was expecting, I would talk about that more. So that was kind of surprising to me, but I think worked out really well.
Starr: Do you think it would have been more useful? Like, it was pretty obvious to me with the responses. Okay, this person is writing good code here obviously. So I don't think we're the type of organization where we are going to go in and, and nitpick and reject somebody because they chose a style that we didn't like for, for their code, or if they, they just did something slightly in a different way that, that we would do it.
Josh: One of the things I liked from the code challenge was uh, the documentation that people generated as a result of their, their projects. And there were, there were a few people that went really heavy on the documentation and outlining what their actual thought process and design process was to solve the problem. And I think that helped us with two things. It helped us, understand what kind of a communicator they were. Because communication is really important. That's, I think, something that's really key to what we're trying to match on. And then of course, the actual like what their, uh, like how they solve problems. And so we got to see that from the challenge. And I really liked not focusing on such the technical topics in the team interview that we did and kind of focusing more on a, like a team, cultural fit sort of thing. Just seeing how we blend basically, uh, cracking jokes and, and uh, answering questions and, and that sort of thing.
Starr: Yeah, the documentation was kind of surprising to me. I didn't expect to get such good documentation from some people.
Josh: Yeah.
Starr: Some people wrote up the, the problem as if it were a, as if they were giving it to somebody else to solve. Um, if they were ... which I really appreciated.
Starr: So what else did we do right? Did we do anything else right? That we want to brag about?
Ben: I can't think of anything else.
Starr: Crickets.
Ben: One of the things that was really handy to me and the phone screen, and this is like Hiring 101, I guess, is just having a template of questions, right? I talked about the inconsistency that you have amongst the interviews, there are of course certain questions you want to ask every time. And so just having 'em, I had a bullet list of five questions that I wanted to talk about in that first 30 minutes with every candidate, and that was, I mean, super helpful. Because you know, conversations can run away from you and you can just get chatting about whatever. Right? But there are certain things you want to know and having all of that in one place, was really handy to go back and review. And then of course, you know, taking notes during and after the call helped quite a bit in making sure that all the, all the bases get covered.
Starr: Awesome. Let's see. What, I'm trying to think of anything that, oh yeah. Like, I really enjoyed using Calendly to automatically set up zoom calls with people. I found myself wanting to have events where peo, I needed to talk to people and do a video chat with people, just so I could use Calendly to set up a zoom call with them. Because it was so cool to me that I could just, I could do that. Like they could pick a time, you know, you send them a link, they go on, they pick a time that's already in your schedule and then they get a zoom link back. I don't know why that's so cool to me, but it just seemed like magic.
Ben: Well, I'll tell you, that's one thing that we did poorly and we being the royal "we", uh, in this case, uh, because this was the first time I had been doing a lot of scheduling of Calendly and we used, um, Google for our domains that we have in a Google calendar and we use Gmail. And what I did not realize when I was first setting up appointments was that, um, Google, in it's wisdom, helpfully adds Hangout meeting details to every meeting request that you send.
Starr: Oh, that's right.
Ben: So I would set some, you know, I'd set up the Calendly, I send out links to people so they can schedule a call. But I wanted to do a phone call. And so I ask them for their phone number. But then when Calendly connected to Google calendar and made the appointment, they would get an invitation that had the Hangouts link. And I didn't realize this until like the third or fourth person said, oh I thought this was going to be a Hangouts call. And I went and looked, oh sure enough there are all the Hangouts links in there. And so I had to go into the G Suite Admin and turn that off so that um, events wouldn't greeted with that link. So I had to apologize to those people that I confused 'cause I was calling them on the phone, they're like, oh I was in Hangouts. Yeah.
Starr: Yeah. We could have had her process nailed down a little, a little better. The way we typically work on development problems, on business problems, is that we all work sort of on our own, sort of asynchronously, and we meet up and coordinate. This doesn't necessarily work when you're hiring people because you know, those, those people want a sort of unified experience. I don't want random founders contacting them and making appointments on their own that they don't really understand how, like, how does this fit into the whole hiring process. So for the most part, we uh, had Ben do all of the point work with the people, but at some point we had some confusion over should we, should Josh and I call these people individually now or should we do a group interview and we eventually got it sorted out, but it would have been nicer to have it planned, you know, from the beginning.
Ben: I think next time, definitely, I can put a document together like here's my plan and then we can talk about that before we actually execute the plan.
Josh: Nah, I like, um, we have some, our friends at Wildbit just posted their job interview for a, uh, engineering [crosstalk] I think it was.
Starr: A job posting
Ben: A job posting.
Josh: Yeah, a job posting. Did I say-
Ben: Interview. Application. I
Starr: I'm calling them job applications. Josh is calling them job interviews.
Josh: They posted a job posting. One thing I liked about it was that they had like bullet points right in the, in the posting, how, how the interview will typically go. And uh, it just kinda goes through like you'll have these two, three interviews, uh, and then you'll talk to our CEO and founders and then we'll get back to you. It kind of sets the expectations of the whole process up front and I think that's something that we would benefit from in the future.
Starr: Oh, definitely.
Ben: I think in the hiring process you really cannot over communicate. I think a lot of people really appreciate like, what is the process gonna to look like, how am I gonna know when you're going to get back to me, you know, what are the next steps? And I would always include that at the end of our, my phone screens. Like I would tell people, okay, and I'm halfway through my phone screenings or I'm almost done with my phone, the screens. And so you'll hear from me no later than x day. Right? And if you don't hear from me, please, you know, call, hit me up and make sure that I don't forget about you. But it's a process that, where there's a lot of nervousness, right? And you're, you're working with new people that you haven't worked with before and so. I love that idea that, that Wildbit post has of here's what the process is going to look like. So you can kind of have some familiarity with this, so you feel comfortable with it, take some of that stress out of the equation.
Starr: It's kind of a personal goal and also a professional goal to be maybe a little bit more transparent about things because it just helps everybody understand where you're coming from. It helps diffuse some of those nerves and yeah, in this case it would have been nice to be able to give people an idea of the interview process before they went through it. Uh, it also would have helped Josh and I to, you know, not a trip over our feet. Yeah. Just in general I think, I think transparency is kind of something we should all strive towards a little bit more.
Josh: Totally.
Starr: Although it is kind of telling that our quarterly meetings happen in a converted bank that's now an office space rental place.
Josh: The bank vault, in the vault.
Starr: Yeah. Our meetings happen in a conference room called "the vault" and it has an actual vault door that you can, you can, I guess hypothetically close, like we haven't tried to close it yet. There's a little device on the wall in the vault that I was always curious about and so I investigated it, I investigated it and it's air holes in case somebody accidentally locks you in the vault so you can breathe.
Josh: Well, that's comforting at least. At least there are air holes.
Starr: Oh Man.
Ben: [inaudible] You can't fit much food through those air holes, so.
Starr: No, no. Just lots of Spaghetti.
Ben: I think for our, for our first time in a full on hiring process, I think we did okay. We had a few missteps and a few stumbles there, but you know, no one went away crying and that's good.
Starr: I give us an A++.
Ben: Is that like C++?
Starr: No, it's, it's just an extra plus.
Josh: It's just an extra plus, Ben, you don't have to-
Starr: It's like when you do really good, you get an extra plus and then maybe a smiley face and a gold star or something.
Josh: Well, hopefully this is not the last time we hire, so.
Starr: Yeah, I mentioned this on Twitter that literally I wanted to hire everyone I talked to. Like I thought everybody was great.
Ben: Yeah.
Starr: I thought they were, I didn't think everybody was a perfect fit for this role, but um, for some sort of developer role that I could possibly see in our company, I thought everybody was great. I wanted to hire them all, but we don't have millions of dollars to spend on, on developers. So unfortunately that can't happen.
Ben: Yeah, it is, it is sad to be able to only I choose one because everyone was fantastic.
Starr: All right. And it's, it's really kind of cool to see that we have something that so many people are interested in joining. That's very gratifying.
Speaker 3: Founder Quest is a weekly podcast by the founders of Honeybadger. Zero instrumentation, 360 degree coverage of errors, outages and service degradations for your web apps. If you have a web app, you need it. Available at honeybadger.io. Want more from the founders? Go to founderquestpodcast.com, that's one word. You can access our huge back catalog or sign up for our newsletter to get exclusive VIP content. Founder Quest is available on iTunes, Spotify, and other purveyors of fine podcasts. We'll see you next week.
