Devshop Stories #3 - The Story of Our Hiring Process


Devshop Stories #3 - The Story of Our Hiring Process

In this episode, Josh and Tanner discuss some of the more "interesting people" they have interviewed during the hiring process and how they manage to separate the good interviewees from the bad.

Listen on Apple

Listen on Spotify

Listen on YouTube

Josh: Welcome to another edition of Dev shop stories. My name is Josh, and I have with me Tanner. Hey, guys. Hey. So today we're going to share a story about hiring, everybody's favorite topic.

Tanner: That's so fun.

Josh: Yes. There's actually a lot of funny stories that we could share with hiring. Some during the hiring process, some actually post-hiring in the weeks that followed, where we've made mistakes and everything. So hiring stories are always some of my favorites.

Tanner: Yeah, they're really fun. It emphasizes the importance of getting it right, and figuring out what works for you because you can really screw up.

Josh: And we have yeah, we have. Well, this first story that I want to share with you, we're going to call it The Quitter Story. And so this one was really kind of interesting. We were hiring kind of juniorish level at the time. We had a number of applicants that we're going through. I think in that day, we had four back-to-back kind of zoom meetings. And I think this was in the kind of the height of COVID too because we're doing them mostly virtual at the time. Right?

Tanner: Yeah, they were. We found everybody remotely. We set up remote meetings, all of that stuff. And it was it was like just one right after another. It was kind of a crappy long day of meetings.

Josh: Yeah. So this one actually put a spoiler face after it happened. So we were in we were just kind of did the whole intro, hi, this is what Red Sky does, and this is what you would be doing at your job and just kind of break the ice type of tension. And I remember specifically that we then decided to go into asking a little bit more of kind of technical questions. And we always try to start off with just some nice little, again break the ice kind of questions, which is like, you know, give yourself a rating of how good you are from one to ten in these different technologies and stuff. And based on that, we do other things and decide which path we go down. But I remember specifically, we asked this one individual a very simple question. It's probably as simple as, hey, what is like, a class, that you put on HTML? Right?

Tanner: Yeah, it was something super trivial. I don't remember the exact question, but.

Josh: We asked that question, and he kind of fumbled through it. And we usually try to help people and hold their hand through it if we can see they're kind of struggling. And then we asked another question that was simple again, like, how would you make a function that returns two numbers? You know, something that they should have learned in their first day of development? And I just remember the deer and the headlights kind of frozen, and he just said, I just don't think this is right for me. And we're like, what the second question? But then he just said, I just don't know if I'm just cut out to be a developer or not or anything. And he just started, like, questioning his life, his life choices on it.

Tanner: Yeah, it immediately you could see him pale in the video, and it was just this, like, almost come to Jesus moment of, like, man, this is not what I expected. It was so funny that it took him to that moment to even end.

Josh: And I think he was a graduate of a boot camp, and so he didn't spend four years of his life studying CS, but he went through probably a six-month program and did all of his learning and instructions there. But I think he just, like it clicked. It's just like, man, I'm just starting to question my choices in life, and maybe I should just go back to the power plant, to the coal mines.

Tanner: It was one of the funniest experiences that we've ever had on one of those calls with people. Usually they'll at least make something up, and he didn't even do that. It was just an almost immediate, like, man, I don't think I can do this. Holy cow, it's the second question. They haven't even asked you anything difficult.

Josh: So we try to let them off easy in the sense of like, hey, no worries. If you ever want to apply again, just send in your resume and maybe go get a little bit more experience and feel more comfortable and everything. And we let them out of the virtual room comfortably and stuff. But it was interesting. It kind of really goes to show that the hiring process is something that company's dev shop should take very seriously. Because you spend a lot of time with people, there's inevitably learning processes that have to take place that is on the dev shop, not on the client's time, on the dev shop's time that you want to make sure that you get the right people on the bus.

Tanner: Oh, absolutely.

Josh: Yeah.

Tanner: You don't want to spend the time necessarily mentoring and training somebody who doesn't have the capacity to do what they need to do, or they are gun shy or whatever it is, it really is. So it's kind of interesting to just say that, like, the different diversities of how people come on. Do you remember that story with the boot camp graduate, and he had this delusion of making just good money from an eight-week boot camp and some of that?

Josh: Yeah, that's kind of the sad part is I think some of these boot camps, they really want to get you in. And so they'll kind of do these extravagant promises. Like, you know, when you graduate, you're going to go from making $13 a McDonald's to 80 grand a year kind of thing, like, almost immediately after just a short six weeks kind of thing. And so I remember that we had an employee on that had worked with or was in the same boot camp as this other guy. And so he decided, hey, I'm going to make 80 grand. Six weeks. I can go out and get myself a brand-new Mustang.

Tanner: Right off the lot, Brand new cherry.

Josh: And we're just like, oh boy, wait until he finds out. Yeah.

Tanner: That is not reality.

Josh: But not all stories are bad. Sometimes you actually get, like, really happy coincidences. So do you remember the kind of Hannah and hiring her on at Red Sky?

Tanner: Yeah, it was awesome. So she came in with just kind of requesting an internship. So she was at a university up in Idaho.

Josh: that required internship to graduate. Yep.

Tanner: So she kind of reached out, was just like, I just need this internship so I can graduate. I'm almost done. This is one of the last things that I have to do. And that was it. So with her, we sent out kind of a normal challenge that we send. So we send out an actual project that they have to build that's real world example. We'll get more into the details on that. But we sent that out to her and it's like, hey, if you can do this right, we'll talk.

Josh: Yeah, because I think we're kind of right at the end of our day where we've basically filled up our schedule of other applicants that we wanted to hire. And I just remember getting this email late and just being like, well, I guess the very least I could say is, hey, do this little challenge, and if you complete it and it looks halfway decent, then I'll invite you in and stuff.

Tanner: Yeah, it's like we didn't want to necessarily close the door, but we had already kind of made our decisions of what we wanted to do. So we sent it out.

Josh: Yeah, kind of came back and we're like, wow, this actually is probably some of the most concise and correct software I've seen. And so we invited her in and got her on as an intern, and she's still with the company and just doing awesome, just completely rocking it. And then it's just all because we had at least a system that allowed us to be able to send them an application. Kind of like almost like a filtering kind of challenge. And that filtering is actually filtered out good and bad. I know that we've sent it to a number of people that just said, like, I just don't want to do this. Those are the kind of people that we shy away from wanting to hire. Right?

Tanner: Yeah. We definitely don't want the people who aren't going to take the initiative be ambitious and hungry. And it's a real world example, particularly if you've never done any production grade work before, some actual realworld work. It's that, and so it's what you're going to do every day. Like, if you don't want to put your foot forward and at least try, it's not the person that you want to have to have somebody who's not going to at least attempt something.

Josh: Yeah. And developers, they come from a large, diverse backgrounds and no path for anyone is the right. You have to do it this way. So you might have some people that go to a full four-year university and they can either be great or they could be terrible.

Tanner: Yeah, and I've graduated with people who I don't think they can stoke up.

Josh: Yeah, absolutely. And then you have some people that go to boot camps for four months and then you have some people we have an individual at our company, Alex, who never went to any formal school and just learned on the job and just from asking questions and YouTube videos and hard work and he's doing awesome there. So in the end, the background isn't something that we necessarily look at. It might be something that makes us look at your resume a little bit more over somebody else's, but it doesn't necessarily mean that this person is going to shine above others.

Tanner: Yeah, it doesn't roll you out at all. But what I do think it does is it lets you understand the depth of some of the knowledge that they're going to have. There's obviously a pretty drastic knowledge difference in depth of functionality from a four-year degree to a 6th boot camp. Not saying that they both can't immediately come in and immediately contribute, right. But it just helps you kind of gauge a little bit of what you're going to get. But it certainly isn't an identifier for hiring or not hiring some at all.

Josh: Yeah, I look at kind of the four-year degree or even if they stayed on for Masters or whatever as just years of experience. Whether you went to a boot camp for four months and then worked out in the industry for three, or four years, that's equivalent pretty close to somebody that went to university and then spent four years in there. And it's just getting these years of years under your belt that puts them into a place of understanding.

Tanner: Because you have to have the exposure one way or the other. You either have to have it through academics or you have to have it through real-world experiences and make those mistakes because that's how you're going to learn is through those mistakes. So, yeah, it certainly shouldn't be a disqualifying factor on anybody's things.

Josh: Right, so what we're really saying is what we're looking for is somebody that has the passion for learning and the capacity to learn too. Those are two kinds of different things. I've seen people with a lot of passion, but they just don't have the capacity mentally to understand some of these challenging algorithm concepts and processes. And I've seen some people that have zero passion, but they are smart, you can see it, but they're just lazy effectively.

Tanner: So frustrating too. That type of person is very frustrating.

Josh: So it's trying to find that mix of passion and capacity to learn. And again, you don't have to know everything, but if you are learning, like for example, we put everybody through a Red Sky University. We have video courses that we've created that show our processes, our procedures, our code components, how we do things. And no matter who they are, whether they're the most senior person at a big firm that's coming in and working with us or a junior person just right outside of them kind of thing, we put them through that Red Sky University because it allows them to at least have the knowledge of how to get their feet up and running. It actually really stems a lot from we found that when we hired people on, we would have to individually put a lot of time into each one of these individuals and teach them all these core concepts that they just weren't being taught in school or on their previous jobs and stuff. And so we said, how can we take this time and just replicate it right and be able to kind of have a nice course? And so we actually created Redsky University for that purpose.

Tanner: Yeah, it is. It's very frustrating to have to teach the same thing over and over and over to every single person that comes in. And it's not scalable. You can't scale your time that way. So that continuing education and just really understanding that the people that we bring in have the capacity to learn that stuff. It really kind of shortcuts a lot of that because it's not a concern of, do you understand this? We know you can understand this. It's just here's the content, the context to understand this stuff.

Josh: And since we started Red Sky University. We've expanded the course content from just developers and developer-centric topics to now designers. We have a number of videos and courses on UI UX design, and how we framework our Figma designs and our style guides and brand guides, how we've done that. And we've now expanded it to QA and how to look for bugs, how to write bug tickets and all that kind of stuff too.

Tanner: And then a big emphasis that is not necessarily as apparent as, hey, this is how this thing works, whether it's design, QA, development, whatever, is the understanding and kind of context between the two. So one thing that's really hard is understanding the design to development communication. So having some training on that piece, how does the design interpret into development and that kind of translation and stuff. So anyway.

Josh: And so that's kind of the post-hiring process. But let's take it back to our actual what is our kind of multi-step process for hiring. And so imagine, as you will, somebody comes in and they're, I'm just going to sit down in front of Tanner and say, hi, I'm looking for a job here. What do you do? What do you say, how does your hiring process go? Yeah.

Tanner: So for us, this was your idea to do a ranking system. So we ask the individual on a bunch of different technologies. For us, our predominant stack, we like TypeScript, we like NodeJS, we like react. We have a custom framework that we wrote. So we ask questions relative to that, and we ask ranking questions relative to that. So for the individual, it's, hey, Josh, on a scale of 0 to 10, a 0 meaning you've never heard of it, and 10, meaning you're the guy who wrote it, how would you rank yourself on NodeJS?

Josh: Oh, 10, obviously.

Tanner: Yeah. The crazy thing is you hear 10 a lot more often than you should. I mean, I've never personally met Ryan Dahl, but I've heard a lot of people say that their 10's on NodeJS.

Josh: Exactly. That is funny. And our follow up always like, oh, you're the guy that wrote it. And they're like, oh, I just know it really well.

Tanner: It's really good. Okay, that's not the scale. Even from that initial assessment, you didn't pay attention to the details of the initial assessment. Even you don't even understand the scale or didn't assess the scale appropriately. So no one should be attentive if not.

Josh: And so with those numbers, then you can direct what type of questions you would have for them. If somebody said that there only a 4 on CSS versus an 8, you might ask them lighter softball-type questions in that regard.

Tanner: Yeah, somebody who says that there are 4 on NodeJS, I'm not going to ask them about how the event system in node works versus somebody who's an eight or a nine in node. Well, yeah, I want to know exactly how these things work. You should understand that at that level if you're at that not ranking yourself at that level. So we very much tailor our questions based on what that is and it obviously takes people who are at that higher end to be performing the interview. And it is a very technical interview. This initial phase is highly technical. We ask a lot of those questions and then we go through the questions with those people and assuming that they answered adequately across the board and no one's ever been 100% and that's perfectly okay, we kind of dismissed them and schedule a follow-up meeting. And this one is equally as important, I think, to the technical one. And this is our culture, right?

Josh: Yes. So we have HR Jacob. That's essentially what we like to call him, but he's a master communicator. He's really good at just getting people to like him. He's charismatic, and he Just was able to kind of break down barriers and Just kind of see What They're like to work with, because we really highly regard culture at our Dev shop at Red Sky. And so we want to make sure that we have the right cultural fit, that this person is going to fit in well and jive with the team. Because you're working with these people. When you think about you spend more time at work with your coworkers than you do with your spouse or your significant others. So you want to make sure that the environment is going to be good, it's going to be healthy, and you're going to be able to build off of each other.

Tanner: Yeah, it needs to be cohesive. And he said HR Jacob is phenomenal at that. I've said it several times about him that he could be the guy that tells me that he ran over my kids and they get that's, okay, he just is that type of person. But it's important to have that for us and I think for most people to have that cultural dynamic that they want and to kind of maintain it. We've had some experiences in hiring that have been opposed to our culture and it has caused some pretty drastic problems. So we can get into those stores at another time.

Josh: Yeah, obviously we'll always look at their experience and what they've done. But in the end, the kind of the final phase to our multi-step process is we want to give them a real-world challenge because we realize that on the spot, you're nervous, you might not be thinking clearly. It's really hard to kind of judge somebody there. And so we want to give them a challenge that's going to be something that they actually see. So it's like, hey, go and build this little website and have it communicate to a back end so you get your front end of the website, the back end meeting the server and the software that's running on that and have them talk back and forth. Make a site that you can add a customer to it and pull down that list of customers that you can update a customer or delete a customer. And we've iterated on that approach a number of different times. And what we do is we ask them to measure how long it actually took to do it because some people might just fly through it and that's great. And if their product looks good and their code quality looks good and their time is great, that seems like a sure hire. But we've also had people that have taken we kind of estimate it's going to take if you really know what you're doing, maybe 2 hours kind of thing. If you don't know what you're doing, you know, obviously a lot longer. But if you're like the guy that's super thorough that has to get everything just right and check all the boxes and everything. We've had people take up to 24 on it.

Tanner: The actual work all day.

Josh: And I feel bad because this is not a paid challenge, which some companies are moving to. That where they're actually paying you to do that kind of stuff. And we want to make sure that they understand. I've heard a number of horror stories where dev shops have asked them to essentially work on customer-client projects as part of their tests to do it. And then they just basically think of this as free work. So farm it out. They're essentially farming it out to these hires and then they never hire them and everything. So we wanted to make sure that it's very obvious that this is something that's a throwaway, but it's something that we do. And so we figure that they are putting time into it to show us what they can do. And it's good on us to actually call them in. We do this with all of our interviewees. We call them in and we actually go and do a code review with them in that spot. We figure they spend time with us. We should at least spend time, even if it's not going to go forward into hiring and stuff, to give them some feedback, some criticism, some words of encouragement, whatever you'd say.

Tanner: Yeah, absolutely. The objective is, even if we're not going to hire that person, like you said, Josh, you spent the time to do it, we want to give you some constructive feedback. There's definitely a few ways that you can give feedback in code reviews in particular. You can be that kind of brutal, just beat them up sort of approach. But what we want to do is whether we hire them or not, is give them some constructive feedback to grow from real-world example. And for us, that's really a big differentiator, I think. I don't care if you can do a binary tree search from memory on a whiteboard. That's stupid, I don't care. But a real-world example of building this site and how this interacts. Even if I don't hire you, that's a real-world example. That's something real and tangible and an experience that that person can take going forward. So it's been great inventing people on both sides of it, people who have made it through the questions, the culture, and they get to that part and it's like, oh, I don't actually know what I'm doing, or I don't want to do this. But then the other side of it too, where they may have struggled on the questions, the culture is a good fit or not, whatever, it's important. But they get into the challenge and they absolutely nail it. It's like, okay, well, at least if for nothing else they're willing to work hard, they put worth a tremendous amount of effort to get this so we can take a more measured evaluation of that person.

Josh: And like I said, we have iterated on the challenge. Originally, we just gave them just a Google Doc that just kind of described the challenge and have since iterated on that since we're getting back a number of different designs. So we're basically looking at the programmer art of what they kind of came up with, which is one thing. Some people are better and some people are way worse than others.

Tanner: I can still see that color in my eyes.

Josh: I know what you're talking about. But the real-world example, though, is they're actually going to be given a design, right? They're going to be having a designer that says, hey, here's the font size, here's the padding, the margins, everything that you want there. So the real challenge actually is how well can you actually match that design? And so we've since shifted from do whatever you want to, try to match this design as best you can.

Tanner: Yeah, we had our designer go through and do a real-world write-up of what this would be. So it has typography, it has the things, it has everything that we would want in an actual project, and it's structured like any of our actual projects. And part of that evaluation is not only can you make it work and do what it's supposed to, but can you kind of read between the lines and do that thorough evaluation and actually hit your margins and your padding and the colors? And do you have enough attention to detail to get to those things without necessarily being directed or guided to those requirements? Because you've been given a full figment design in this case to do all of the things that you need.

Josh: So moral of the story is be very slow to hire, be choosy, but these are real people out there. Give them real-world experiences, life experiences, and treat people well. And that's about it. So thank you for listening to our story. We'll be back next week with more stories, personal experiences, and advice on running Dev Shop. Thanks, Tanner.

Tanner: Thanks, guys.

Also Check Out

DevShop Stories #12 - Six Steps To Be A Successful Product Owner

In this episode of DevShop Stories, Josh and Kai discuss the role of a product owner and why it is crucial when working on a project.

How To Bypass AI Detectors

With the popularity of AI on the rise, thanks to ChatGPT, it's valuable to know how AI detectors function so we can beat them at their own game.

From React to Svelte - A Devshop's Journey

RedSky Engineering transitioned from React to Svelte due to challenges with React’s client-side rendering and the cumbersome nature of large projects. They found Svelte's simplicity, efficiency, and robust community support more appealing.