You can't hire programmers like this

As a programmer, finding a job can sometimes seem like a daunting task.

Seriously, let me take the word “seems” out of that sentence. It’s just miserable! A lot of people have complained about being terrible at hiring — we don’t have any reliable way to identify people who can code and write well. It’s true, we as an industry are terrible at it. Even among the most common demographics of developers (American, male, white, relatively young, and from middle-class backgrounds), we absolutely fail at identifying, and we do even worse when it comes to a wider range of people. But we have to expand because even if we don’t have morals, we have a quantity problem, there are more jobs than the “elites” mentioned above, there are only so many middle-class American twenty-something white men, and half of them won’t even apply for your equity-only “drone delivery for Uber, 23andme, Twitter, Clash of Clans” company because they’re starting their own company in another Starbucks across the street from the one you started. On the other hand, there are simply too many qualified women, non-white, foreign people who want technical jobs and don’t get them.

But the applicant side (the one I’m working for now) is also having a hard time. The difficulties faced by the recruiter are precisely the reason for the painful process.

Education sucks

One of the things we tried was looking at academic qualifications. But we are not good at teaching programming in schools. Most universities can't decide whether the computer science courses should be an extension of the math department or the engineering department. As a result, they end up with a weird fusion of neither, or they teach programming, but the language and technology are years behind the existing norm, or they make students memorize lists of algorithms and their complexity, which makes students mistakenly think that programming is just rote learning and then becoming an automaton that can output the correct algorithm name and pseudocode. Because what companies really want is a repeater, right? Just build a repeater for data structures, and maybe a repeater for sorting algorithms, and you can probably save a lot of interview time.

I'm convinced that the current education system and its flaws are responsible for the software hiring horror stories we hear. People with CS masters who can't seem to write code from scratch are not bad; it's more likely that their education devalues ​​actual programming and focuses on theory. People who post "please write me good code" on mailing lists and forums are not bad; it's more likely that their education is based on memorization and test-taking. Also, if you've never read the story of the famous physicist Feynman visiting a university that adopted this approach, I highly recommend it.

That was still the stage of programming teaching: we knew we needed programmers, and we didn't have enough programmers to write code, let alone teach more programmers, so this rote learning phenomenon was widespread because it was the best we could do now. We just hoped that the students we "taught" would run to watch the Ruby on Rails tutorial, then accidentally see the GitHub documentation, and magically learn real software development, architecture, and best practices from it. Because everyone knew that they couldn't learn this in school.

Meanwhile, on the flip side, most of the technically talented people I’ve worked with had no college background in software engineering or computer science; many didn’t write code for the first time until they were almost done with school (shameless bias: I didn’t start “programming” in the usual sense until I was almost done with college, and I didn’t start doing it for a living until a few years after I graduated). A lot of really talented people get filtered out by the “undergraduate degree in computer science” requirement, which is a problem that happens when recruiters don’t set job requirements carefully. Even if recruiters bother to add “or have comparable experience,” they still get filtered out, because the degree on a resume seems to be the first thing recruiters and HR use to screen candidates for actual technical people.

I have a degree in philosophy, by the way. Not to brag, but a lot of really great people in software that I know and respect have the same background.

So using education as a screening criterion doesn’t work very well; companies suffer because having a CS degree doesn’t mean one is ready to sit down and write code; and job seekers who are ready to write code suffer because not having a CS degree is still a drawback, and going back to school for four years for a degree isn’t easy. And there are 50,000 coding bootcamps/training classes started every femtosecond, and people coming out of them have degrees in philosophy, literature, theology, history, and semiotics of modern A-line poetry, but when they go through the bootcamp, they’re probably at least as good as CS students, because CS courses are basically terrible, and people who take the initiative to join coding bootcamps are usually smart and motivated. And if they can learn to disassemble A-line poetry, it’s basically confirmed that they can write a CRUD application using your JavaScript framework, because that JavaScript framework was just released last week, so there aren’t many people who have more than a day or two of actual experience with ReAngleBoneASS.

Coding interviews suck

Since academic qualifications are unreliable, another way to identify people who can code is through a coding interview. The job applicant talks to someone within the company (usually over the phone or video chat) and is asked to write code that solves a problem. If you are still curious, I will tell you that we are not good at selecting people who can code this way. In short, these interviews are unreliable because they are too short, too contrived, and too oppressive.

To elaborate: I know multiple top talent who were rejected for jobs they were absolutely qualified for because of coding interviews like this. I tend to think of them as the latest version of the "ask a riddle" trend that was popularized by Microsoft because every company wanted to be as big and successful as Microsoft. Now people hear that Google does coding interviews, and see Jeff Atwood's FizzBuzz test, and every company wants to be as big and successful as Google, and resonate with Jeff Atwood's hiring horror stories, so now everyone is doing coding interviews. But they still suck. Maybe it's because Google supposedly uses whiteboards, while other companies use phones.

Want to see an example of a very qualified person who was rejected for a coding interview? He was rejected because the interviewer mistranscribed the Bash script he was reading over the phone, which of course caused the script to break. I am absolutely not kidding or exaggerating, and I really can't find any other way to describe it except "insane". If he had used a whiteboard, he would have been accepted.

In fact, I’m pretty sure I blew a coding interview (at least I haven’t heard back from the company yet). Remember I’m not a fresh graduate. I’ve been developing web applications for over a decade now, working on systems of all sizes; I’m a core team member of a very important web framework, and probably the world’s expert on it; I actually wrote the book on using it (one of the first), get hired to teach it, and give keynotes at conferences about it. I once went without much sleep, staring at a running program the entire time, trying to figure out Django’s legacy systems, discovered that my spirit animal is a slow loris, and a while later when my consciousness was stuffed back into my body like Gandalf, I fought back with just two lines of code, fixing five different bugs “deep in Django’s belly”. I’m pretty good at this, if you haven’t noticed yet I hope you’ll remember that.

I hope you're paying attention, because I'm pretty sure I botched a coding interview recently.

I won’t mention the company’s name because it’s not relevant to this post. I won’t post the question they asked because that’s also not relevant. It wasn’t as easy as FizzBuzz, but it was still easy enough that I could come up with multiple solutions off the top of my head. The interviewer rejected my preferred approach (probably because it called standard library functions directly and couldn’t show I could solve it manually), so I tried another one. I happened to make a small mistake when I was reconstructing the solution from memory because I was overconfident and wanted to talk to the interviewer about something else, so I thought I knew how to solve this problem just from memory, so why not just get through the question and talk about something I really cared about.

By the way, I made a minor typo in that I added a value to the wrong loop variable. Single-letter variable names are terrible, even in a dumb program you write to impress the interviewer; in other words, the code works, but the results are wrong.

But when the program finished running and spit out the wrong result, all my confidence was gone, and I thought to myself: "Oh my God! Why is it wrong? I should have known this." Then I debugged it frantically, tried to explain my approach to the interviewer and answer their questions, read the code, looked at the results, and added debug statements to check the intermediate values. The whole atmosphere was: "Oh! Just a reminder, this will determine whether you can get the job you want, so don't feel any burden."

So even though I fixed it, it took me longer than normal, which made me wonder if I might be the next Atwood-style failed hiring story. "Yes, there was a person with ten years of experience, a so-called 'expert', who made it through the first two phone interviews, but he couldn't even write this super simple function and had to work really hard to find his mistake. It's really cool to use this question as a filter!"

If you've ever felt terrible after a technical interview, if you've ever felt like you were a complete failure, a piece of shit, didn't deserve the position, and just wanted to live away from computers, technology, and the recruiting process that made you feel that way: I wish I could say that things are getting better. What I can say is that you're not alone. My own arrogance and impatience to get it over with and move on was a big part of what got me fired up in that interview.

But that doesn't make the end result any easier to live with, and it probably doesn't make these interviews a powerful tool for companies; they seem to inevitably crowd out qualified candidates simply by their very nature. Namely: inexperienced candidates are more likely to lack confidence and draw a blank, or spend so much effort trying to come up with something to wow the interviewer that they end up floundering and looking incompetent, while experienced candidates are likely (as I did) to see these interviews as annoying formalities that they just want to get through as quickly as possible (when scheduling a programming interview, I even joked with the recruiter that I could write FizzBuzz in at least six languages, so they could just tell me which one they wanted), and the results will only live up to the ancient Greeks' expectations of overconfidence.

As a candidate, this interview sucks. The pressure and lack of room for error always make people feel physically ill. Coding interviews are just as bad for the mental abuse. Is this really a simple "prove you can write a for loop" question? Or is this a trap question with a deeper problem that the interviewer wants you to discover and explain?

Is this really just about basic programming skills? Are there some well-known algorithms or techniques that your lack of a CS degree would have taught you so well that they could be used as a codeword for software Freemasonry? Are you supposed to demonstrate your mastery of the language and tools, or do they want you to speak your mind to show that you can analyze the problem? Would the interviewer be more impressed if you could type “FizzBuzz” in an A-line poem?

These thoughts will haunt you the entire time. They will paralyze you, drain your confidence and thinking ability, and make you look completely incompetent. But that's what big companies do, they're big and rich and successful, so everyone else will do it, leaving behind a sea of ​​brain-paralyzed, unconfident, hesitant zombie programmers who just yell "recursion depth exceeded" in a flat tone, and those companies just complain the entire time about why they can't find talent, and then can someone please clean up these zombies?

Everything sucks

I've been on both sides of the hiring process many times, and I've been through all the interviews in this thriving software industry (I seem to average about one job every five years, which gives me some interesting memories of each phase). And all I've learned is that we do a terrible job. There's a famous "demarcation problem" in the philosophy of science (which I studied a little in school): how to distinguish between real science and pseudoscience that's packaged in terms that look like real science. There's still no magic bullet for this problem.

Software development faces the same demarcation problem, but ours is a little different: we need to know not just who can already code, but how well, and among the aspiring people who can't yet code, how far they are behind and how much help they need to get there (in other words, not just "who can we hire", but "who can we hire for high and low positions", and "who can we hire as an intern and then recommend for good training and then hire later"). There is no silver bullet here; if there was, we would have found it long ago, because many geniuses have spent a lot of time looking for it.

So far, I've found that what works always fails at other times. That includes reviewing GitHub or something similar to assess ability; using relationships and references to find people who have proven themselves; conversational, life story interviews (where the interviewer and the candidate talk about things they've seen and done, and how they solved problems); coding interviews; "keyword" interviews (I was in an interview where the goal was really just to see if the candidate "named the keyword" to see if they really knew the field); high-pressure interviews; low-pressure interviews; short contract probation periods; intern rehire programs; team integration interviews; pair programming; hackathons; one-on-one interviews; many-on-one interviews; you name it, it's been used and has a success rate of only about half at best.

So it sucks for employers. Did I mention it sucks for candidates too? Too many processes are seriously unfair, and then made worse by the gap between the interviewer and the candidate. Sometimes you don't even know you're being evaluated (especially when the process starts with a GitHub profile screen), and the person who's brought in to run the technical/coding interview often sees it as a time-wasting chore and doesn't take the time to prepare or even get to know the candidate or what they're interviewing for (I've been in this situation a few times, and I can honestly say that an interviewer who doesn't even bother to read a candidate's resume is not going to make a candidate want to join them). On top of that, even the best technical interviews have a very adversarial element, which is also very uncomfortable.

However, as a candidate, it would be outrageous if the candidate did not prepare in advance if he did not cram the company's technical structure before the interview, and maybe add some technical interview experience, including sorting, search algorithms, and how to calculate the complexity of Fermi's algorithm for estimating the number of piano tuners in Chicago. Because even if the interviewer does not know the candidate and the position at all, the candidate must do enough work, and the interviewer may really ask the tuner question.

I know in theory this dehumanization and disconnect is a side effect of too many people applying for tech jobs; you can't have it both ways to humanize the process and process all the applications. But it definitely leaves job seekers with a bitter taste in their mouth. I wish I could feel like I was being interviewed by someone who would become a colleague, rather than being interviewed by Interchangeable Cog #7365 for Interchangeable Cog #9540, who then has limited time because more Interchangeable Cogs are waiting in line to interview. And you only get equity if you're one of the first five thousand.

This completely ignores the fact that people are different, some are good at formal interviews, and some are not. (Neither of these things tells me how well the person will do in a real job setting; if they did, then to some extent these interview techniques could be used to apply for the kind of job I don't want.)

So what should we do?

Honestly, I have no idea. Technical recruiting sucks for everyone involved, and there are no easy fixes. Not even quick fixes that will keep us going until a fix is ​​found. But I’ll mention some things anyway, just because it looks terrible to write a 3,000-word rant without offering suggestions.

Once a company gets big enough to have a dedicated recruiting team or department, HR becomes a pain point for both candidates and existing employees. What I mean by this is that many of the recruiters that candidates are dealing with have only just found a job themselves. This slows down their ability to respond and convince others that the company is worth joining, slowing down the entire recruiting process.

If your recruiting team is a revolving door with people coming in and out, you should find out why and fix the problem, make sure you put people there who really understand the company and the talent you are looking for, and don't leave either party (the candidate or the team that needs to be trusted) waiting in vain. I'm talking about you, company X that hasn't sent a "hiring status" email a week after the last call.

When you rely on developers to interview, schedule it responsibly. You're already taking up their time and forcing them to switch focus; make sure they have enough time to not only do a 30-minute phone call, but also to go through the candidate's resume, GitHub, etc., and learn the details of the position they're managing. It's a little nice to talk to someone who can say "I noticed you did/contributed to (project)" and relate it to the company and the position, but little niceties can go a long way. Also make sure the interviewer wants to be an interviewer; I can tell when it's clear that the other person just wants to get the interview over with and get back to "the big picture," which is bad.

Don't do a coding interview, if you can, look at some code the candidate has written, or describe a small bug you recently encountered and ask them how they would solve it. If you can work with questions related to the position, even better. Give the candidate the choice of explaining it over the phone or writing it down and emailing it to you. I know people who can write god-level code but can't explain it well, and I also know people who are good at explaining but are afraid to write even a little code; unless your position requires special speaking/writing skills, don't lean towards either side.

If you must have a coding interview, keep the time and pressure to a reasonable level - your developers may not be able to solve a bug in 30 minutes with a stranger's phone dictation software output, so don't force the candidate. Also, you can change the mindset of developers who hate interviews: "This is not an interview, it's a code review." Everyone can "electrolyze" code reviews into keywords such as Agile™ and Lean®. Code reviews have the elements that developers crave!

Most importantly on top of all of this, please humanize it. We are not machines; we just make machines do interesting things. Sometimes we can even make them do the right and interesting things. But we are human, and there is a huge gap in the humanization of the hiring process right now. Humanize the humans, and everything else will be much easier.