Hey everyone and welcome to Developer Tea. My name is Jonathan Cottrell 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. And 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. Now, 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 obvious problems. So effectively, the evaluation process is basically to determine if the programmer can solve these very obvious problems. So effectively, the evaluation process is basically to determine if the programmer can solve these very obvious problems. So effectively, the evaluation process is basically to determine if the programmer can solve these very obvious problems. So effectively, the evaluation process is basically to determine if the programmer can solve these very obvious problems. So effectively, the evaluation process is basically to determine if the programmer can solve these very obvious problems. So effectively, the evaluation process is basically to determine if the programmer can solve these very obvious problems. So effectively, the evaluation process is basically to determine if the programmer can solve these very obvious problems. So effectively, the evaluation process is basically to determine if the programmer can solve these very obvious problems. So effectively, the evolution process is basically to determine if the programmer can solve these very obvious problems. 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. If we follow this idea of narrow problems and social interaction, 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, you know, 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 the team they've signed. So if you're trying to evaluate whether or not they've signed, with your team. So the real takeaway here is that a true evaluation relies on context. So 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 kind of black and white things that you can determine, you know, 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. But 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. Now 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. Now sometimes companies will choose to do a longer evaluation period, and that's exactly what we do at WeWork. 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 the company's 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 offering to hire you to do a longer evaluation period. This gives us much more confidence in our 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. 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 making. I hope that you have gained some ideas about how you can improve your 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.