Destroy all hiring processes
Finding work as a software person kind of sucks sometimes.
Actually, let me strike the “kind of” from that sentence. It just sucks, full stop. Plenty of people have complained that being on the hiring side of the equation is terrible — we don’t have any reliable ways to identify people who know how to code and do it well. And it’s true: we, as an industry, suck at this. Even among the most common demographics for developers (American, male, white, skewing young and middle-class background), we are absolutely abysmal at this, and we only get worse when trying to draw from a broader population. Which we have to do, because even if we don’t have a sense of ethics we do have a problem of numbers, and more desks and seats and spots than people to fill them, and there really are only so many middle-class white American male twenty-somethings out there, and like half of them aren’t even applying for that equity-only position at your drone-delivery-for-Uber-for-23andme-for-Twitter-for-Clash-of-Clans because they’re starting their own in the Starbucks across the street from the Starbucks where you’re starting yours, while the supply of women, non-white people and non-Americans who are competent and want jobs in tech and don’t have them is much, much larger.
But it sucks just as much from the trying-to-be-hired side (where I am right now). And many of the things that don’t work for hiring are also things that make the process suck for candidates trying to get hired.
Education sucks
One way we’ve tried to do this is to look at education. But we suck at teaching people how to program in school. Most universities can’t decide whether their curriculum for things involving computers should be an extension of the math department or an extension of the engineering department, so they end up doing this weird mix of both that really turns out to be neither, or they’re teaching some programming but the language or the techniques are years behind current best practices, or they’re having people memorize tables of names of algorithms and their big-O characteristics, which leads into a belief that memorizing a bunch of that stuff and being an automaton who spits back the correct algorithm name and a pseudocode implementation is all there is to programming. Because what companies really want is to hire a Fisher-Price See-‘n-Say toy, right? Probably a lot of interview time could be saved by just developing a See-‘n-Say for data structures and maybe another for sorting algorithms.
I fully believe that the styles of education we have, and their failings, are responsible for a lot of the horror stories we hear from software recruiting. People who have a master’s degree in CS but seemingly can’t code their way out of a paper bag probably actually aren’t bad; more likely they had an education which de-emphasized practical hands-on programming in favor of heavy theory. People who post “please give me the code” questions on mailing lists and forums probably actually aren’t bad; more likely they had an education which was based around memorizing and regurgitating stock answers to stock questions. If you’ve never read Richard Feynman’s story of touring a university where this method was being used, I highly recommend it, by the way. That’s still kind of the stage everyone is at with teaching programming: we know we need programmers, and we don’t have enough programmers to do the programming, let alone to teach more programmers, so there’s a lot of this rote-memorization-without-understanding floating around because that’s all we can really manage to do right now and we just kinda hope that some of the people we “teach” programming to will go out and read a Ruby on Rails tutorial and stumble across GitHub’s documentation and magically learn actual software development and architecture and best practices from that, because God knows they’re not going to learn it in a school.
Meanwhile on the other side, most of the best people I’ve worked with in tech had little or no university background in software engineering or computer science at all; many didn’t even write a line of code until they were mostly or completely done with school (shameless bias: I didn’t start “programming” in the sense most people would use the term until I was most of the way through my college education, and didn’t start doing it for a living until a couple years after graduating). Which is a problem for anyone listing a job who isn’t careful in their requirements specifications: a lot of really great people will get weeded out by any filter that demands “Bachelor’s degree in Computer Science”. They’ll even get weeded out by something which goes to the trouble of specifying “or equivalent experience”, because it seems that the degree listed on the CV is a common first pass filter for recruiters and human-resources people to start weeding out applicants they won’t pass on to the actual technical folks.
I have a philosophy degree, by the way. Not to be smug about it, but several very good people I know and respect in the software field came to it from that background.
So education as a filter doesn’t really work; it sucks for companies, because having a CS degree is no indicator of someone’s readiness to sit down and start coding, and it sucks for candidates who are ready to sit down and start coding because not having a CS degree is still a liability and it’s not like it’s cheap to just go back to school for four years and get one. Plus there are fifty thousand coding bootcamps being booted up by their bootstraps every femtosecond, and the people coming out of those have degrees in philosophy and literature and theology and history and the semiotics of modern Linear A poetry, but when they get through the bootcamp they’re probably going to be at least as qualified as the people who did CS degrees, because the CS curricula tend to be pretty bad and the people who self-select into coding bootcamps tend to be pretty smart and motivated, and if they could learn to do deconstruction of Linear A poetry, it’s a safe bet they can learn how to build a CRUD app with your JavaScript framework, because a week ago that JavaScript framework hadn’t even been released, so it’s not like there’s a ton of people out there with more than a day or two of ReAngleBoneASS experience anyway.
Coding interviews suck
Another way of trying to figure out who can code, since educational background doesn’t work, is the coding interview, where the candidate talks (usually via phone or video chat) to someone at the company, and is asked to solve some problem by writing out the code for it. We suck at figuring out who can code from those, just in case you’re curious. The short version of the argument here is that these interviews are too short and too contrived and pressured to be reliably useful.
The long argument begins with the fact that multiple top-tier people I know have been turned down for jobs they were eminently qualified for, solely on the basis of these interviews. I tend to look at them as the current version of the “ask a riddle” fad that was popular years ago because Microsoft did it, and every company wanted to be as big and successful as Microsoft. Now, people have heard that Google does coding interviews, and people have read about Jeff Atwood’s FizzBuzz test, and every company wants to be as big and successful as Google, and sympathizes with Jeff Atwood’s recruiting horror stories, so now everybody does coding interviews. But they still suck. Maybe it’s because Google allegedly used a whiteboard, and the other companies are using phones.
One of those eminently-qualified people who got turned down based on a coding interview? He was turned down due to a transcription error from reading a Bash script to the interviewer through the phone, which of course caused the script not to work properly. I am absolutely not joking about or exaggerating that, and there is no word to describe it other than “insanity”. With a whiteboard he would’ve passed.
In fact, I’m pretty sure I failed a coding interview recently (I haven’t heard back from the company since then, at least). And keep in mind that I’m not someone fresh out of school looking to break in. I’ve got over a decade of experience in Web development, at all sorts of different scales; I’m a member of the core team for a very important piece of Web application software and likely one of the world’s top experts on it; I’m someone who literally wrote the book (well, one of the earliest books) on how to use it and occasionally gets paid to teach it to people and invited to give keynote addresses at conferences about it. I once went without sleep for a little while, spent the whole time staring into the soul of a running application trying to trace the behavior of Django’s old forms system (they were called “manipulators”, and were every bit as alien and organ-harvesting as the name implies), found out my spirit animal is the slow loris, and later when my consciousness was reinserted into my body, Gandalf-style, I came back with a two-line commit that fixed five different deep-in-the-guts-of-Django (sung to the tune of “Deep in the Heart of Texas”) bugs. I’m kind of good at this stuff, and in case you haven’t noticed I’d like you to be aware of that.
I’d like you to be aware of that because I’m pretty sure I failed a coding interview recently.
I won’t name the company because it isn’t that relevant. I also won’t name exactly what the problem was they posed, since that really isn’t relevant either. The problem wasn’t quite at the FizzBuzz level, but it was pretty simple and it was one that I knew how to solve in multiple different ways off the top of my head. The interviewer ruled out my preferred method (probably because it offloaded work to a standard-library function instead of showing I knew how to do it manually), so I fell back to another approach. And promptly made a small error in reconstructing it from memory, because I was overconfident and wanted to talk to the interviewer about other stuff, so I figured why not get this out of the way since I know how to do it from memory, and then we can move on to the things I actually care about.
For the record, I had a tiny typo which meant I added something to the wrong loop variable. One-character variable names are bad, even in toy programs you write to appease the interviewer; in this case it meant the code ran, but produced the wrong result.
And when it ran and spat out the wrong result, all my confidence went out the window, and was replaced by OH GOD WHY ISN’T THIS WORKING I AM SUPPOSED TO KNOW THIS, followed by frantic debugging while trying to explain to the interviewer what I was doing and answer their questions while also reading the code, reading the output, dropping in debug statements to see intermediate states and OH BY THE WAY THIS IS TO DETERMINE WHETHER YOU GET A JOB YOU’RE REALLY INTERESTED IN, SO NO PRESSURE OR ANYTHING, and though I fixed it it took way longer than it should have, and left me wondering if I’m just going to wind up as an example in an Atwood-esque tale of failed recruiting. “Yeah, this guy with ten years’ experience, some so-called ‘expert’, got through the first couple phone screens and then it turned out he couldn’t even write this super simple little function and had to scramble to figure out what he did wrong. I’m sure glad we use that as a filter!”
If you’ve ever felt bad after a technical interview, if you’ve ever felt like you just completely failed and were worthless and didn’t deserve a job and wanted to go live in a cave somewhere far away from the computers and the technology and the processes that made you feel this way: I wish I could say it gets better. All I can say is you’re not alone. My own hubris and impatience in wanting to get the task done and move on was a big part of my downfall in that interview. But that doesn’t make the end result feel any better, and probably doesn’t make the interview itself any more useful of a tool for the company; these interviews seem like they’ll inevitably exclude a lot of worthwhile candidates simply due to their properties. To wit: less-experienced candidates are more likely to be under-confident, blank or try too hard to come up with something brilliant that will wow the interviewer, and end up struggling and looking incompetent, while more-experienced candidates are likely to (as I did) see this interview as an annoying formality to get through as quickly as possible (when it was scheduled, I even joked to the recruiter that I could write FizzBuzz in at least half-a-dozen languages, so they should just let me know which they wanted), with the kind of results the ancient Greeks taught us to expect from careless overconfidence.
And as the candidate, well, they just suck. The amount of pressure and the lack of room for error can and does make people feel physically ill. And the things coding interviews do to your mind are equally awful. Is this really an easy “just prove you can write a for loop” problem? Or is it a trickier question concealing some deeper problem the interviewer wants you to notice and talk about? Is this just looking for basic coding skills? Is there some named algorithm or technique you’re supposed to dimly remember from the CS degree you don’t have, to act as a sort of Software Freemason secret handshake? Are you supposed to be showing that you know the language and the tools, or do they want you to think out loud to show you can reason about the problem? Will it impress the interviewer more if you make it print out “FizzBuzz” localized into Linear A?
These kinds of things sit in the back of your mind the whole time. They can paralyze you, sap away your confidence and your ability to think clearly, and leave you looking and feeling utterly incompetent. But $BIGCO does this and they’re big and rich and successful, so everyone else is going to do it too, and leave a bunch of paralyzed, confidence-sapped, second-guessing, third-guessing and seventy-fourth-guessing programmer corpses in their wake, all of them just loudly saying in a flat voice “MAXIMUM RECURSION DEPTH EXCEEDED”, and the companies will be complaining all the while that they just can’t find good people, and could someone clean up all these corpses, please?
Everything sucks
I’ve been on both sides of the interview process at various times, and I’ve been through interviews at multiple stages in the recent growth and expansion of the software industry (I seem to embark on a job hunt about once every five years, on average, which provides interesting snapshots of the state of things). And all I’ve learned is that we mostly suck at this. Philosophy of science (which I spent some time on in school) famously has the “problem of demarcation”: how to separate things which actually are science from things which come wrapped up in correct-looking science words but really are something else entirely. So far there is no easy silver bullet there.
Software development also faces a problem of demarcation, but ours is slightly different: we need to know not just who already can code, but also how well and, among the people who want to but can’t yet, how close they are and how much help they’ll need to get there (in other words, not just “who can we hire”, but “who can we hire into junior vs. senior positions” and “who can we bring in as an intern or suggest a useful program for so we could hire them in the future”). There isn’t an easy silver bullet here either; if there were, we’d have it by now, because a lot of smart people have put a lot of their time and effort into finding it.
Thus far, everything I’ve seen work once turned out not to work some other time. That includes looking at GitHub or equivalent to get an idea of ability; using networking and referrals to identify pre-vetted people; using conversational story-swapping interviews (i.e., interviewer and interviewee talking about things they’ve seen and done and how they went about solving problems); coding interviews; “magic-word” interviews (I once took part in an interview where the goal was literally to see if the candidate “said the magic word”, to show that they knew the problem domain we were talking about); high-pressure interviews; low-pressure interviews; sample contracting periods; internship-to-hire programs; team-immersion interviews; pair programming; hackathons; one-on-one interviews; panel interviews; you name it, it’s been tried and probably has failed at least as much as it’s succeeded.
So it’s not great for the employers. And did I mention it sucks for the candidates, too? So many of the processes are largely impersonal and suffer from extreme disparities in the positions of interviewer and interviewee. At times you don’t even know someone’s evaluating you (especially if a public profile on a site like GitHub is the first screen in the process), and too often the people doing the technical/coding interviews see them as a chore that takes time out from things they’re actually interested in, so there’s little in the way of preparation or looking to see who a candidate is or even what position they’re interviewing for (I’ve certainly had that happen to me multiple times, and I can say that an interviewer who can’t be bothered to even glance at a candidate’s CV is not going to be an interviewer who inspires the candidate to want to work with them). Even beyond that, there’s a strong adversarial element to even the best tech interviews, and that’s not super pleasant either.
But a candidate who doesn’t do a pre-interview cram session on the company’s tech stack and probably also on a bunch of tech-interview cheat sheets covering sorting and search algorithms and how to regurgitate the big-O characteristics of verifying Fermi’s estimate of the number of piano tuners in Chicago is just utterly screwed. Because while the interviewer doesn’t have to know anything about the candidate or the position, the candidate has to know as much as possible just on the off chance the interviewer decides to ask about the piano-tuner thing.
I know that in theory the impersonality and detachment is a side effect of how many people apply for tech jobs; it wouldn’t be possible to make the process feel personal and also get through all the applications that come in. But it sure does leave a bad taste in the candidate’s mouth, and I wish I knew of a way to do it that would let me feel like I’m interviewing as a person to work with other people, instead of feeling that Interchangeable Cog #7365 is interviewing me for the position of Interchangeable Cog #9540, and has limited time because of all the other Interchangeable Cogs in the queue to be interviewed. Plus, you only get stock options if you’re one of the first five thousand cogs.
And that’s without getting into person-to-person variation, like people who do well in contrived interview situations versus people who don’t (neither of which is an indicator of how someone will perform in the actual job environment; if it is, somehow, then it’s a useful technique to interview for a job I would never want).
What to do
Honestly, I don’t know. Tech hiring sucks for everyone involved, and there isn’t an easy fix for it. There aren’t even easy stopgap measures to see us through to when there will be a fix. But there are some things I’ll mention anyway, just because it feels wrong to spend 3,000 words complaining and not offer something.
It seems that the instant a company is big enough to have a dedicated recruiting team or department, the recruiters become a sore spot for both candidates and current employees. Turnover seems awfully high, which means a lot of recruiters a candidate talks to have just finished getting hired themselves. That has a negative effect on their responsiveness and their ability to convince people you’re worth working for, and slows down the entire hiring process. If you’ve got a revolving door in your recruiting team, find out why and fix it and make sure the people you get and keep there know your company, know what you’re looking for, and won’t leave people on either end (candidates or the teams looking to hire) hanging. I’m looking at you, unnamed company that hasn’t even dropped a “here’s the status” email for a week after the last phone call.
When you’re having developers conduct interviews, schedule them responsibly. You’re already taking time out of their day and forcing an expensive couple of context switches on them; make sure they have enough time not just for a 30-minute phone call but also to look over the candidate’s CV, GitHub, etc. and find out the details of the position they’re interviewing for. Talking to someone who can start out with “I see you worked on/contributed to (project)” and segue that into how it relates to the company and the job under discussion is a little thing, but little things go a long, long way. Also make sure the people doing your interviewing want to be doing interviewing; when I’m talking to someone who obviously wants this to be over so they can go back to Real Work™, I can tell and it’s not a good thing.
Instead of doing a coding interview, look at samples of the candidate’s code if available, or throw them a description of a small bug you recently had and ask them to explain how they’d tackle it. Bonus points if you can choose something based on the role you’re interviewing the person for. Let them explain it over the phone if they want, or write it up and email it to you if they’d prefer. I know people who can write articulately and intelligently but will freeze up if asked to actually explain something out loud, and I know people who who are great at explaining things in a conversation but are terrified of writing even short bits of prose; unless you’re hiring specifically for a job that requires specific speaking/writing skills, don’t force one or the other. And if you must do a coding interview, make it realistic in terms of the time they have to do it and the pressure they’ll feel — your developers probably don’t fix bugs by dictating the answer over the phone to a stranger within a 30-minute window scheduled for them by someone else, so your candidates shouldn’t be forced to either. Plus, you can spin it to your developers who hate doing interviews as “it’s not an interview, it’s a code review”, and everybody knows code reviews are Agile™ and Lean® and other buzzwords, like “electrolytes”. Code reviews: they’ve got what developers crave!
And above all else, be human. We aren’t machines; we just make machines do interesting things. Sometimes we even make them do the correct interesting things. But we are ultimately very much human, and right now there’s a gigantic gaping lack of humanity in recruiting and hiring processes. Be human to your fellow humans, and all the other things will probably get a lot easier.
Also, if you are a human in search of a human to make machines do interesting things for you, I’m still looking for the right humans to do that with, so feel free to get in touch.