199 How Do I Find the Best Developer to Hire?

How do I find qualified developers when I post a job? How do I ensure that the developers I review have the skills I need? How do I know if a developer is a good fit for my project? These are the questions we will cover in this episode of Dev Questions. 

Website: https://www.DevForge.com/ 
Ask Your Question: https://suggestions.iamtimcorey.com/
Sign Up to Get More Great Developer Content in Your Inbox: https://signup.iamtimcorey.com/

Transcript

Copy Transcript Copied

SPEAKER_00 0:00

Welcome to the Dev Questions Podcast with Tim Corey. Join us each episode as we tackle the questions you are asking about a career in software development, understanding the industry, and new technology. If you're just starting out or you want to grow stronger as a developer, this is the place to get your questions answered. Now, here's your host, expert developer and online educator, Tim Corey.

SPEAKER_02 0:26

How do I find the best developer to hire? That's the question we're going to tackle in this episode of Dev Questions. And it kind of pairs with last week's, where we talked about how to build out your portfolio. Well, this week we're going to talk on the other side on how to hire a great developer. But even if you aren't a hiring manager, this is going to be informative since it's going to give you insight into how your application might be evaluated and seen by a potential employer. Now, internally, we have a formal process we go through that's laid out in a number of steps. I'm going to simplify this into a few categories for you. Maybe if there's interest, I might create a more comprehensive training on this topic, but it's really in depth. So in general, here are the steps that I recommend. Number one, remove anyone who doesn't meet the requirements. Now, some people say, well, the requirements is so high. We're not talking about everything listed on the job posting. So if I say, well, I want C Sharp application developer that you know, five years experience, five years in SQL, five years in Git, five years in GitHub, you know, I'm listing out like that, and you have four years in GitHub, five years and all the rest, you don't get rejected. What I'm talking about is there's gonna be some things that you they're non-negotiable. You need to have. For instance, for me, non-negotiable is was that you could move to the Dallas, Texas area. We're all remote, but we get together often enough that it's important to be here. Also, because of legal reasons, we have people in just one state. So there were some non-negotiables in that. There's also non-negotiables for us that you have to have a green card or be a US citizen because of the fact that we financially can't afford to deal with people who run work visas or sponsorships and so on. So there's some things that were non-negotiable. We have to have this. And if you don't match that, well, we just move on. We don't even address that person except to say, sorry, you're not a fit. And a pro tip here is to be clear on the non-negotiables. Okay, and then use that as a filter. And there's some things that, you know, even in the experience category, I was hiring for a senior C sharp developer. Well, I can't take a person who has three years' experience as a developer. That's not a senior developer. So that person just doesn't get looked at beyond that point. So we remove anyone who does not meet the requirements. This cut out hundreds of people. And so that really reduced our workload because this is an enormous workload. Number two, look for red flags. All right. So I'll give you a few that I've seen, and somebody's gonna sound silly, but they're true. Resumes and cover letters with different names. That's a red flag. It's not automatic ejection, but it's a red flag. I'm concerned about why your resume have a different name and email address than the cover letter, which has a name and email address that are different. That's concerning. Um a one-year position that takes up a page on the resume, a full page for one year's worth of time. First of all, you haven't learned how to summarize. But second of all, again, this is not an automatic disqualification, but it's a red flag because I wonder, can you not summarize? Or are you taking credit for things that you didn't actually do? For instance, if you worked on a team that implemented a microservice, great. But did you just get coffee? Or did you architect the microservice and build it yourself? There's a difference there. And when you list so many things that you have done, my assumption is probably some of those are more like you were on the team. And so you're taking credit for that work, not you did all of these things. So that's also a red flag. And again, red flags are not immediate disqualification, but you need to start looking at how many red flags there are. Number three, multiple jobs in a short period of time. Now, this is a yes, a controversial one because in today's market, first of all, you get laid off. It happens. And you can even get laid off within weeks or months of starting a job. That's not your fault. So, yes, that happens. And maybe it can happen five, six, seven times in a row. Probably not, but maybe. The other option is you've moved around because you want to get better salaries. Again, that's, you know, you can't actually get a raise in your own company, but you might be able to get a 15, 20, or 30% raise by just moving to a different company. That's pretty common in the industry. So it's not a disqualification, but it's a it's a red flag if you do it too often. And it's something we need to think about because am I gonna be a six-month stay for you? Or are you plan on staying around for a longer time? Because if you do nothing but jump around, well, I don't want you to jump into my job, start, you know, we invest in you, we we get you up a speed, and then you go, okay, I'm gonna leave now. Because I've spent a lot of time and effort to get you up a speed and a lot of money, and I have to start all over. So I don't want that to happen to me. And your track record is a bit of a red flag. Next is portfolios that don't have any contributions in the area you're looking for. So they give you a portfolio, great, or maybe a GitHub profile, and there's nothing in there that applies to what you want to do. Why is this a red flag? Well, because how much time and effort is the candidate spending in the areas you want. So maybe they could write in C sharp and may they even have experience in that, but they haven't done it recently. They're kind of rusty because their passion is Python. Well, that's great if you want to work in Python, but if you want to work in C sharp, then hopefully that's what your passion is. And if you're not spending any time outside of work, or you're not creating any portfolio projects in C sharp, that makes you wonder if you're even happy in this position, or if you're even truly skilled in this position, or just you're a developer can switch languages. There's a difference. And then competing major technologies in a position. Again, this is something to think about. I see this quite a bit where people say, yes, I was a C sharp developer for two years at this company. I worked on C sharp and API, and I built out React and Node, and I start listening to all these things they've done. And so then I start to think through the calculus of, well, how much time did you spend working in C sharp as opposed to React and Node and all these other things? Because you might have spent just a little bit of time in React and most of your time in C sharp, or maybe you just had a SQL database and you were a quick little wrapper API, and the rest of the stuff you spent you spent in React making a nice UI. Well, that's different. That's not really two years' experience in C sharp. That's more like three months' experience in C sharp and maybe a little rust because you haven't done it in a while, because your major focus was in this other major area. That's where you need to talk through. Again, these are red flags, not necessarily deal breakers. They're things that you need to identify and then have a conversation about and say, hey, I noticed that you're spending a lot of time in these compete technologies. Where do you spend most of your time? Because that can kind of inform where a person is. Now, number three is look for green flags. It's not all bad stuff, right? Sometimes you want to look for, well, you always want to look for green flags as well, which here's some green flags, and again, start taking notes because these are the things you want to do. A resume and cover letter that are tailored to the position. Again, people like to push back on this one, and it really frustrates me because your resume, your cover letter, should be tailored to the position you're applying for. That does not mean you rebuild an entire resume for one particular job, but it does mean that if you're applying for a C sharp development role, that you should highlight and focus on the C sharp development you've done, not focus on the web work you've done, not focus on the work in other technologies like Python that you've done. No, you want to focus in on the things you've done in C Sharp. Make that the highlight. And when you talk about a cover letter, you want to talk about the actual position. Say, hey, I'm looking forward to working in a small company that does training in technology. I look forward to being a major contributor in moving the company forward. That's all you have to do. And now you've been, you've said, hey, I know who you are and I'm looking forward to working with you. Whatever the company is, do a little bit of research and then target that cover letter to that. In your resume, you might have four or five or six different resumes. Maybe not, maybe three. It depends on what types of jobs you're looking for. If you're looking for one specific type, you might have one resume. But if you're looking for two or three different types of jobs or you're applying to a broader range, make your resumes different based upon what the position might be. Otherwise, you get lost in the crowd. And you know what? You're going to apply to hundreds of jobs and barely get a look. It's very hard when you have six, seven, eight hundred people applying for a position like we did, to figure out who the people are that we should talk to. I cannot do Zoom calls, even introductory Zoom calls, with 800 people. So you need to figure out how to stand out in that crowd. Otherwise, you will get lost. And the way to do that, the easiest way I do that, is to have a resume that's focused more on the job that you're applying for. And then a cover letter that's specific to a specific job. Other green flags. A portfolio that has contributions in the areas you're looking for. If I'm looking for a C sharp developer, when I go to the portfolio or GitHub profile, I'm looking for what have you done on C sharp? Let me see how you build logic. Let me see how you lay out projects. Let me see what level you're at in your development. And if you have nothing but web projects that are HTML and CSS and JavaScript, and a Python script over here and a TSQ script over there, okay, that can teach me some stuff, but that's not nearly as helpful in saying yes, this person is standing out. So green flag is contributions in the area you want that you can review. Another green flag is a resume that shows growth in the areas you're looking for. Okay. So if I'm looking for certain areas, I want to see, did you just always maintain a same level? Did you always just be a person who's fixing bugs? Or did you grow into building applications? Did you grow into a senior role? Did you grow into a larger position? Did you do more things? Did you have a bigger impact? I want to see the growth in your career, not just a, hey, I did the same thing over and over again for the past 10 years. Now, another thing I want to see in our green flag is an indication of fulfilling a role. So for example, if I'm looking for a senior developer, I'm looking for, do you say you mentor anybody? Do you lead a team? Do you set vision and direction? Do you do some architecture or do you do you do some design of systems? Do you are you responsible for larger chunks? If you're a junior, I'm looking for, I look for, do you have any specific accomplishments? Meaning junior developers just start out, they're just trying to figure things out. But when you build that one app or when you build that one piece that that contributes in some way, talk about that. Because I'm looking for, hey, did you start to progress in that? Did you did you get beyond the I'm terrified and I have no clue what's going on? Into the I can contribute something. And you know, mid-level developers, I want to hear about your complex situations that you've you know you've come across that you've solved. You know, I did this, or I, you know, I figured out how to improve performance in an area by 15%. I figured out how to rewrite this part of the application in order to reduce security concerns. Some type of you took initiative, you were able to accomplish a larger chunk, something that you've done that's a little bit bigger. So those are some green flags. And I look for those green flags, and now we have red flags on resumes and green flags. And step four is you order your submissions by perceived fit. So I'm gonna look at, okay, you know, who are the people that I'm like, this is green flags all over. And let's order that down to the nothing but red flags. And then step five is interview the top 10 to 20 candidates. So this in this interview, um, my interviews are a bit different. My first interview is just let's talk your resume. Like, give me the talking version of your resume. Let's get to know you. Let's you know, ask some questions in there, trying to figure out those green flags and red flags and you know, if they're, you know, resolve them or not. But talk through like, hey, you worked at this place for two years. What was that like? What'd you do? What was your responsibility? And kind of just get a feel for each other. Having a conversation is much more beneficial than having an interrogation. So make it a conversation and do that for 10 to 20 candidates, sometimes more, depending on how many you have and how many make it through this round. Because here's where you start to, again, reorder your candidates. So let's say you put 20 candidates through, you order them one through 20 and say, okay, out of this interview, that person came off the best. This person really struggled. And you order it from you know best to worst based upon that. And then I would go to the next round of interviews, which I call the technical interview. Don't freak out, but that's five to ten people. And I don't like the idea of you know, write text on a whiteboard. That's not an interview. That's not a great indicator of what you do. I try with my interview process to make it all about real world. You know, so I would really ask you in your role, I'd say, hey, you know, what did you do this past job? And how does that affect what you do today? I would ask that of one of my employees. I have. So that's a conversation you have, a normal, relaxed conversation. Of course, there's always gonna be tension, but as a hiring manager, I try and bring as as little tension and try and relieve tension whenever possible. So this next round is the technical interview, and that's technically the technical interview, but we have an informal conversation around architecture or design. We talk through a real scenario, and I ask them, how would you approach this problem? And I even work on it with them to come to a solution. For example, I might say, and I have not used this in an example or in an exam before, but an example might be we want to build an email capture form on our website. How do we approach that? Well, that's gonna spark some questions. Like, well, what technology do you currently use in your website? Do you have just HTML and CSS? And that's true for us, but or do you have a Blazor site or do you have a React site? And so we talk about that and they go, okay, so you have an HTML and CSS site. Um, where do you want to capture those data into? Well, I want to capture it into SQL. Okay, so it sounds like probably what would be beneficial is that we write a little bit of JavaScript to talk to an API. And we'd write the API in C sharp and we use a minimal API that that API can talk to the database. And we can just use that system, a little bit of JavaScript in the front end, a little form, and then we can send that on through the API and onto the database. Okay, so we start to have that conversation. I can start asking probing questions. Like, what if I want to add that another place? Can we just add another one? Well, sure, it's just another API and a little bit of JavaScript. That's, you know, we can just use more JavaScript and call it good. Well, okay, what if I wanted to and start kind of expanding from that? And you because this is the kind of conversation that I actually have with developers. I'll come to them as as the manager. Now I know development, but I'll come to them and say, hey, I need this. I need you know, this built. What are your thoughts on how to approach that? And they'll have that conversation with me and say, hey, I think that we would do this. We'd create this thing in Azure and use this thing over here. We'd you know, use GitHub actions in order to deploy it and automate that. And we talk through and say, okay, I actually want to change a couple of things or tweak a couple of things, or let's not forget this is long term, and we have that conversation as a natural conversation. So by doing it in the interview process, we just practice. We just practice what we're gonna do in real life and see how we fit. See if the person is just off in left field and just doesn't get what I'm talking about, or if they're on the same page and they're like, yeah, you know, I would think about this, or I would raise some points that I'm like, I hadn't thought about that. And we have a back and forth conversation because that's what they're gonna do in their real job. And that's what I call a technical interview. Now, step eight after that is to order the candidates again. May the person who was number one is now number three because number two is number one and number four is number two, whatever. Like you kind of rearrange things and say, okay, now we have a new order based upon the technical part of the interview process. And then step nine. And this is the controversial one, so hang with me. So for the top X number of candidates, I try to do three, I try not to do too many many, but this is the take-home project. And I already hear people going, whoop, I'm not gonna do that. Here's how I do it. And here's what I believe should happen. This is a paid step. So what I do is I figure out the, I have a rate, a pay range for whatever position. I also publish that by the way, but I have a pay range for the position. I take the top end of the pay range, I figure out what the hourly rate of that would be, and then I pay them for however many hours that take home project should be. And I try and limit it to a short amount of time. My preference is eight hours. Because also what I do is I will give the project at the start of that eight-hour time timer, and then eight hours later it's due. Otherwise, what happens is I say, okay, only spend eight hours in this and turn it, you know, it's a Friday, only spend eight hours in this and turn it in on Monday. Well, what are you tempted to do? Well, I wasn't quite done, so I did a little bit more. I I spent a little time, I came back to it. I had a thought in the shower and I I worked on it again a little bit, and then you turn it in on Monday, and you really spent 20 hours. Hours on it. Well, first of all, I'm not paying you for 20, I paid you for eight. So now you're getting paid less. But also, remember, this is a real world scenario. And so if I give you a job to do on a Monday morning, and I expect you to do what you did in the interview process as far as the speed goes. So if all of a sudden you're taking three times as long as you did in the interview process, I'm going to feel like I've been jipped. Like, you know, you gave me, you, you tricked me into thinking that you're faster than you are. I want real world. I want real world expectations. Let's set those. So my take home projects, I pay you, and that's up front, you know that. And I give you an actual problem to solve, real world code that I might even use. I might not. I might, but I'll give probably that same project to more than one person. But I give you a real world problem to solve. And, you know, I say you only have eight hours to do this, so you might not solve the whole thing. That's fine. The goal is not that you write code for me that solves all the problems or is even usable code. The goal is to understand how you approach the problem and how you write the code to solve the problem. So this is again about a real-world scenario understanding how you work. We've understand how you just talk to other people. We've understood now how you think about design and architecture and building a solution to a problem. And now we're seeing how you actually do that solution, how you really do the work. Because sometimes you can talk a big game, but can't actually do the work. So it's great when you can just advise other people because you can come up with these elaborate things that, you know, oh, you should implement a microservice, you know, system with Kubernetes and all this sort of stuff. And you're like, have you ever done that? And you're like, I've never done that. Okay, so opinions, everybody has them. Let's go ahead and figure out where the rubber meets the road here and see how you can actually implement some type of solution. But again, it should be real world because I don't want to give you a scenario where you're, you know, on at a whiteboard trying to write C sharp code that you might not even know. In the real world, you have Visual Studio to help you write that code. You have GitHub Copilot, you have the internet, you have the ability to ask questions on the internet, you have the ability to figure out and try different things. Well, that's what you should be able to do in your interview process. And you also shouldn't have a person necessarily right over your shoulder saying, Why are you doing that? Why are you doing that? Why are you doing that? Because that's not real either. Now, pair programming has its place. But for me, this is what I do. And if I'm gonna have you do work, you're gonna get paid. So that's why I still believe in a bit of writing code for an interview, but at the same time, I believe in paying you for the for the privilege of you doing that. All right, now at this stage, you're on step number 10. I do something a little bit different, but it's something that I think, again, is really helpful for real-world scenario. And that is I have the candidates, at least the ones that I feel like could be viable, I have them explain their solution to non-technical people. So, you know, in the real world, to be what happens is you have somebody that says, I need this, and it may not be a technical person. It may be the owner of the company, like me, saying, Hey, I need this built. I might not know how to do it. But if I ask for it to be built, then you need to explain to me how it works. Or if it's my team that asks, maybe, you know, Tom is my community manager and he works a lot with the community and works a lot with people, and he might ask for something to be built. Well, I need you to explain to Tom how it works and what the ins and outs of how it operates are. That's a great thing to have a candidate do because they're gonna have to do it in the real world. And if they can't explain to a non-technical person how things work, well, if that's gonna be part of their job, that's a problem. So, yes, maybe it'd be a training opportunity if the role is right for that. But if they're designed, if they should do this already, that can be a uh a red flag. So, and then number 11, I have them meet their potential team and explain the solution again. Because when you meet your team, again, you're gonna be dealing with other developers potentially. If you are, they should know who you are and how you come about uh or how you address problems and how you talk about problems and solutions and know that you're in a good fit for the team and allow them to ask questions back and and see, you know, kind of have some back and forth. This is not about, did you write perfect code? Because none of us do. This is about can you interact and can you have the the complete life cycle of a developer? Can you do all that stuff? And the way the best way to do it is to try it out. And that's how you do it. So number step number 12, make the call. Now, a lot of companies stop there. Okay, you've you found the right person you think and you hire them. Cool. Problem solved, move on, we're done. And that's really not the end of the process. Because if that's the end of the process, you may lose a good developer. A good developer may turn into a bad developer. A good developer may turn into a person who you're frustrated with and you don't want that. So the important part is that this is not where it stops. Make sure that you communicate the requirements of the position to the hiree, but also make sure that you know the requirements of the position. So it's a it's a two-way street here. Because if you hire a person to be a C sharp developer and you say your job is to write C sharp code, and then when they get into the role, they find out that their job is actually to write Python or to write scripts or to you know do server management. Well, they're not going to be as successful because that's not what they were understanding the position to be, nor were they necessarily as skilled in that position. But also, when you judge them, you should be judging them based upon what you said their role was going to be and what you hired them for. So if you hire them to be a C sharp developer, that should be the focus that you look at and say, are you doing a good job at that? Well, if you're if you don't know why you hired them, you don't remember, then you judge them based upon what they're doing, which might not be where they fit. Another part of this is check in regularly to make sure they're fitting into the role. Especially when you first start off, you want to make sure that they get in and are doing things efficiently and that they are feeling like they fit, like there's a place for them, and they're not on the outside looking in and they're not just overwhelmed. You make sure that they they fit in smoothly. This is really important, not just for you, but for them as well. Address problems when they are small. So maybe they're, you know, their desk faces a window and the the light is blaring their eyes, and that just makes them a little bit miserable every morning. Well, you know what? If you find out early, you could address that and maybe make a tweak, maybe turn things around so it's a little better, or put a shade up or something, but address the problems when they're small. If you don't like how a person chews on their pencil and you don't address it, you may get more and more and more angry until a point where you just explode and it's a massive problem just because you let a little problem fester. Don't do that. And these are just you know examples, but the reality is that there is an adjustment period when you bring someone in. And so you need to help make that adjustment period easier and smoother. Address the problems that are small, make sure they're fitting in, and then don't just focus on the needs of the company. So when you're trying to make sure they're fitting in, don't just think through are they producing enough? Hey, you're not up to speed fast enough, get up to speed faster. We need more output from you. That's not helpful. You need to make sure that you're focusing on their needs as well, because maybe their need is I don't understand this IDE, or I'm not used to this, or I don't know where to get help. And so that's why they're slower. That's why they're falling behind. And so, not just focusing on a company's needs, but their needs will help them meet the company's needs. And then utilize regular meetings to get on the same page, to help them grow and then make sure that they're happy. So, doing this will help make a developer that's pretty good better rather than making a great developer miserable. Okay, so there's a lot more to hiring good developers than just picking the right one. And there's a lot more to picking the right one than just reading resumes better. It takes a lot of work, but in the end, you can have some great success if you follow these key steps. All right, thanks for listening. As always, I am Tim Corey.

SPEAKER_01 32:32

Thank you for joining us for this episode of Dev Questions. Tim is committed to making it easier for you to become a developer. If you would like to help make more content like this possible, please like, subscribe, rate, and share Dev Questions. You can also send your questions to questions at IamTimcorey.com. Until next time, remember, you are too smart and your time too valuable to waste it making all the mistakes Tim did. When you're ready to learn to think and code like a professional developer, head over to Iamtimcorey.com and enroll in a course.