Hey, everyone and welcome to Developer Tea. My name is Jonathan Cutrell and today I'm going to be talking about the flawed process that we are currently using to hire people. You know, when you hire a programmer, you're hiring a person that is coming onto your team to produce something, of course, producing code is important. But you're also hiring a person that comes in to fix things when they break. These are two different modes of thinking for programmers to engage in. The first is a mode of construction and constructing with a high level of quality and constructing with the future in mind. There's a lot that goes on when you are constructing something. There is a lot to the process of construction. There's tons of books about this. Probably the most famous one is code complete. It talks a lot about the construction process. In fact, it uses the construction industry, the building construction industry as a metaphor for the software construction process. But the problem with hiring is that construction is really the only thing that we focus on. And even more narrowly, we focus on the construction of something very small that has obvious parameters. I'll admit that this is kind of a broad generalization. Not everybody hires this way. And certainly not everybody believes that this is the only important part of the hiring process. But very often, this is the way that we expect hiring to happen. We provide the candidate with some sort of limited scope problem to solve in front of us, whether that is writing out a search algorithm on a whiteboard or perhaps explaining to us how they would write a particular SQL query. And really any question of this flavor that has very obvious parameters, very obvious outcomes that you are trying to achieve, or very obvious problem statements. Typically, these kinds of questions are paired with some sort of social evaluation to determine if the person will be able to get along with the people that work at the company that they are applying to work at. So effectively, the evaluation process is basically to determine if the programmer can solve these very constrained narrow problems and if they can get along with the people at the company that they are applying to work at. And this is flawed for two major reasons. I'm going to take a quick break for a sponsor, DigitalOcean is our sponsor today. And then we're going to talk about what those two reasons are. But first, I want to tell you about DigitalOcean. DigitalOcean allows you to spin up an SSD server in less than one minute. Now you've heard me talk about this on the show before, but I wanted to tell you we actually had a person in our Slack community on SpectadoFM slash Slack if you want to join that Slack community and come in and talk about this kind of stuff with us. But we had somebody come and tell us that they are really happy that we suggested DigitalOcean to them. They actually went through the process of launching their server on DigitalOcean. You can launch a server on DigitalOcean in less than a minute. It's $5 a month. That $5 gets you 512 megabytes of memory on a single CPU, 20 gigabytes of SSD disk space and a terabyte worth of transfer. Of course, if you use the code Developer Tea, you can get a $10 credit at checkout, which is effectively like having two months on that first tier. Or if you bump up to the second tier, which is $10 a month, you get a gigabyte of memory, you get 30 gigabytes of SSD disk space and your transfer doubles to two terabytes. So that's $10 a month. You can get a month of that free using the discount code Developer Teaat checkout. So make sure you check out digitalocean.com. This is perfect for any of the side projects that you're thinking about working on and launching on your own or your personal portfolios. All of those things you can spend up a server in less than one minute to go ahead and get that stuff started. Those projects that you've been waiting on starting, that is a perfect way to get started on those projects. So let's get back to our discussion about what is flawed with our hiring process. The last thing that I said was that the hiring process is based on the idea that our potential candidates, they only need to be able to solve really narrow problems. This is how we're evaluating them at least. They only need to be able to solve narrow problems and get along with the people that they're going to be working with in the future. And certainly this could produce some reasonable outcomes and some reasonable conclusions about the candidates that you are considering hiring. But there's two fundamental flaws with using these two metrics as the only evaluation tools for determining future candidates for your team. And I've already hinted at the first one, that is this process doesn't evaluate whether the person is good at fixing existing problems. Or I guess the more accurate way of putting this is this process isn't good at evaluating seeing if a person can articulate what the problem is. Instead, it gives them a well articulated problem to begin with. But the reality is this is skipping probably the most important step in problem solving, and that is defining the problem itself. We should absolutely be evaluating whether potential candidates can define a problem well and then solve that problem. Whether this is something to do with fixing a bug on your server or perhaps there's a cis-admin issue and they need to track down the credentials necessary to log into the server, this is how developers spend most of their time when they are trying to solve a problem, defining what the problem is, and then determining the path towards a solution. If all of our evaluation problems are already well defined, then we're completely skipping the evaluation of the person's ability to define problems. And that's really the first fundamental flaw. If we follow this idea of narrow problems and social interaction as our only evaluation tools, then we totally skip whether or not a person can define a problem. And the second issue is really quite similar to the first, and that is that we are completely ignoring the working context of the individual once they get into their position. Now this concept of evaluating inside of a given context is true both for code and for social interaction or co-worker interaction. If you give somebody a problem that is well defined already, then they don't have to go through the process of determining the context. They don't have to go through the process of determining a sliding scale of solutions, for example. If the context is that this application that we are supporting as a company is being deprecated soon, well then a quick fix is more likely to be acceptable than a full-on solution, a well-designed solution that is intended to be built upon in the future. These kinds of decisions are the kinds of decisions that you're going to want your employees to be able to make. The same is true with trying to evaluate whether or not the potential candidate is going to get along with the team that you have already built. If you try to evaluate this based on out of context questions about how the person reacts in a given situation, you're not given enough information to determine whether or not that person will actually get along with your team. The real takeaway here is that a true evaluation relies on context. Here's the practical fix. If you want to evaluate somebody in context, then give them a real problem to solve in the context of your team as a part of their evaluation. Of course, there are plenty of interview steps that you could take before you get to this point to determine if this person is even a realistic candidate for you. You could talk about basic skills, basic experience and perhaps salary requirements, all of the black and white things that you can determine. Absolutely, this is a person that we are interested in or absolutely this is a person that we can't or we won't hire. Once they've made it to the stage where you have enough interest in them to actually evaluate them, then sure, some of those problems, some of those pre-baked problems, some of those can be useful in determining how a person goes about looking at a problem. If you want to know the full picture of how they're going to work on your team, put them on your team for a few days. Allow them to actually solve a problem in the context that they're going to be solving a problem in if you decide to hire them. One word of caution or maybe a caveat here is that if you ask a person to work on your team for a day or two days or maybe a week even, then you should either be willing to pay them or sign some sort of contract that says you are not going to use their work for your own financial benefit that this is intended to be an evaluation only. This is kind of a good, faith way of letting the candidate know that your intention is not to get a week of free work out of them. Sometimes companies will choose to do a longer evaluation period and that's exactly what we do at Whiteboard. We actually do a significantly longer evaluation period to see how somebody works over the course of a project. This also gives us time to determine if the person's values line up with companies' values on longer term execution strategy of a given project as well. This gives us much more confidence in our hiring decision making process. If you're a developer that is looking for a job, I would recommend that you ask the companies that you are hoping to work at, that you ask them for this evaluation period. This gives you a chance to prove that you are a great worker that you are a great problem solver. Ultimately, we can have a better, more holistic hiring process that goes beyond just answering simple questions on a Whiteboard or answering simple questions about how we deal with people. It goes into a much more scientific way of evaluating how well we work in the actual context that we're going to work in. Thank you so much for listening to this episode of Developer Tea. I hope that if you are a hiring manager or somebody who is in charge of hiring, that you have gained some ideas about ways that you can improve your hiring process. I hope that if you're looking for a job that you have gained some ideas about how you can make your potential employer feel much more secure about their hiring process and their decision in hiring you. Thank you so much again for listening to Developer Tea. If you've enjoyed this episode, make sure that you subscribe to Developer Tea. Leave a review and then check out the show notes at spec.fm. Thank you and until next time, enjoy your tea.