Hiring Is Broken and It Isn't Worth Fixing
Hiring Is Broken and It Isn't Worth Fixing
Erik Dietrich explains why the hiring system for programmers is broken and has a very simple suggestion for someone navigating it.
Join the DZone community and get the full member experience.Join For Free
Engineers build business. See why software teams at Atlassian, PayPal, TripAdvisor, Adobe, and more use GitPrime to be more data-driven. Request a demo today.
Usually I fly home from client sites late in the day, but the whims of fate had me driving home instead, early (for me, anyway) this morning. The end result was a pocket of uncommon free time this evening, before resuming long days and seemingly non-stop travel on the morrow. Naturally, I wasted this free time poking around the internet.
My travels led me, via Twitter, to this blog post entitled, “F*** You, I Quit — Hiring Is Broken.” Apparently, this led to some heated, sometimes-angsty debate on Hacker News, where the original piece earned a good number of points. And, why wouldn’t it? “Hiring is broken” would serve as a rallying cry for those who don’t play the interview game well, while seeming a shot across the bow of those who do and are now on the other side of it.
Read the article, please. You need to for context, because when I reference it further, it’ll just be a reductionist. I’ll come back to that. First, I’d like to address one of the few points that almost everyone seems to agree on, before they get down to armchair dissection of Sahat’s character and market worth.
The hiring process is imperfect deeply flawed (if not broken), but no one knows how to fix it.
Except, that’s not actually true, because I know how to fix the interview/hiring process. It’s actually pretty easy. Just stop doing it. If the value proposition you’re offering to prospective laborers is so weak that you have to solicit and subsequently torture strangers, you should prioritize fixing your organizational mess above making the mess larger (or, in the case of attrition, before doing the same thing again).
I’m honestly not kidding, but let me come back to the mindless growth point later.
A Sort of Impedance Mismatch
Let’s return now to the post and the tl;dr. Here’s my summary of Sahat’s essential complaint.
I’ve built some open source tools, shared some tutorials, and built a following in the programmer community, all of which constitute a form of social proof and demonstrated value to the industry. But when I go to apply for jobs at a lot of organizations, particularly large ones (only Google is mentioned by name), none of this seems to matter. They could learn about me if they looked at any of this, but they don’t. My experience interviewing across the board has been so depressing — so assembly-line and bureaucratic — that I’m ready to give up. I don’t think that I’m all that great a programmer, necessarily, but clearly people out there value what I do, and there’s clearly a programming shortage, so something doesn’t add up.
The conclusion here is that the hiring process is broken. Companies need talent, he has talent (which he feels is at least somewhat demonstrable by his community presence), and there’s a recruiter-driven, bureaucratic mass in the middle preventing a happy match.
I’m going to post part of the first comment that shows up in response to Sahat’s post, from Erick, a software engineer at Google.
I don’t have time to read your github projects, or your blog, or your existing code, or your meticulous attention detail in your commit messages. I get a resume in, I look at it for 10 minutes, if it’s sane I set up a phone screen. ONLY to prove that you can pass the most basic coding test.
Once we meet in person, you need to show me that you can code and articulate a design to a problem. The format sucks, sure. But you need to be prepared. I’m not going to spend 2 hours reading your blog for every candidate that I interview. I don’t have time for that.
(As an aside, this is an example of a defender of the hiring process conceding that it’s not actually all that great—in this case, “the format sucks.”)
This comment got 64 hearts on Medium, whatever that means. I’ll assume it’s upvotes, and so I’ll assume that this is a popular counter-point to Sahat’s popular post. And it sort of encapsulates a basic valuation of the process. Sahat (having been spurned) says, “Your hiring process is broken because it didn’t select me.” Erick of Google says, “Now wait just a minute—it’s obviously not broken because it did select me.” I get that they’re not actually saying this consciously, but there’s clearly skin in the game on either side.
But let’s look a little beyond that at the personas and see that they’re both right. Sahat has poured a lot of work into open source and community contributions, and people around him have expressed that they derive benefit from this. At the very least this means that Sahat can ship software and mentor newbies. That’s what companies are looking for, but instead of spending half an hour looking at his body of work, they spend half an hour peppering him with trivia. It wastes his time.
Erick is busy and he’s being saddled with dozens of resumes to sift through on top of his job writing software. And, you can bet that happens in his nominal free time—Google doesn’t hire chefs and masseuses and jugglers and whatnot out of the goodness of its heart, but because it wants employees to spend lots and lots of hours at the office. Google is a megacorp that probably needs to feed 1,000 newbies a day to the internal machinery, so his job isn’t to look for unique snowflakes but to thumbs up a handful of these things and go home. Google jobs are in high enough demand that, even if some recruiter does initially reach out to you, the onus is on you to prove yourself, since there are 200 people just like you, competing for this role. Read your github profile? You’re wasting his time.
And herein lies the impedance mismatch. Interviewees want to be evaluated and match-made as individual humans while interviewing organizations (large ones, anyway) want to evaluate people as livestock commodities. Who’s right? Well, I dunno—it depends whether you’re looking for a meaningful connection or for a serviceable burger.
This is shaping up to be a long post, as mine often are, but I do promise to come back to my opening concept of not hiring. But first, I want to talk about the trouble I have with Sahat’s perspective. It has nothing to do with him thinking these interviews are stupid—he’s absolutely right about that. It has more to do with his choices, such as knowing about Google’s process and doing it anyway. Why do that at all? And why do it again and again at other large orgs and at startups imitating large orgs with their hiring processes.
So if you’re in Sahat’s position, here’s my advice for you, and I’ve blogged about this before. Don’t take interviews with Google and other megcorps with this style of interview. Seriously, just don’t do it. At one time, these companies were scrappy, little startups with game-changing innovations. Now they’re more like government agencies than world-beating innovators.
I mean, seriously, listen to Erick’s description of Google’s hiring process. When I’m hiring programmers, I don’t have time to look at your background and see if you’re good at programming—I just get resumes, scan them for keywords, set up a phone screen and administer the trivia. Is it just me, or are you half expecting him to tack on, “Look, buddy, I don’t care about your ‘civil liberties’—there’s a lot of people behind you, so just take off your shoes and belt and go through the metal detector.” But instead of asking you to put all of your liquids in 3 ounce containers, he just concedes that the process sucks.
And that’s where you want to work? At an organization so innovative that the best they can do when it comes to hiring developers is to act and talk like a government-sponsored bureaucracy? Yup, everyone knows it’s stupid, but the process is the process and that’s that. Good grief. If you want to work at Google, forget the DMV out front—keep working on the open source stuff until they buy you out, and then negotiate form a position of strength.
But, even if you know enough to avoid silly interview processes by preceding reputation, that doesn’t insulate you against all of it. Start by telling recruiters, up front, that you don’t do trivia interviews and the like. Be firm and explicit about this, as in, “If they start asking me to describe merge sort, I’m going to thank them for their time and tell them I need to go.” You need to make it clear to the recruiters that it will be embarrassing for them if they don’t facilitate this requirement of yours. If you want to see this in action, here’s a page to which I refer recruiters, which contains a list of requirements for me to consider agreeing to an interview or a gig with a company. On of the requirements is as follows.
For interviews, no brain-teaser-oriented interviews or algorithm-centric interviews (see “The Riddler” and the “Knuth Fanatic” from this excellent video about interviewing anti-patterns). I strongly prefer code reviews and evaluation of my public code samples and am just not interested in discussing why manhole covers are round or in reliving college coursework from 15 years ago.
Finally, if you’re already in the interview and this stuff starts flying at you, then excuse yourself. A lot of people say this, and I think they’re mustering some bravado and creating the impression that they would stand up, harrumph, and declare, “this is beneath me, and I say good day to you, sir!” That’s silly — it’s just bridge burning. Don’t do that. But don’t keep going. Instead, be apologetic, diplomatic, and earnest, and do it all while subtly shifting the power balance.
“Alright, why don’t you head on up to the board and show me how you’d balance a binary search tree.”
“Hmm… you know what? I’m really sorry, but I think maybe we got our wires crossed somewhere here. I’ve had experience on the hiring side of this sort of interview style in the past, and I’ve seen it result in some really sub-optimal matches, so I’ve adopted a policy of having certain deal breaker cues in the interviewing process. So at this point I can safely say I’d be unlikely to accept an offer, and I really wouldn’t want to waste any more of your time. To make up for the time I have wasted, I’d be happy to put you in touch with people in my network that I think would be a better fit for this style of organization.”
Let’s review. What you’re really saying (very nicely) is “you need to work on your hiring process, so I’m not interested in working here, but I can probably scrounge up a few of the kind of C players that would be a better fit for you.” You’d be amazed at how quickly people reassess you and alter the narrative of what’s happening to save face. It’s unlikely that they’ll reverse course and make you an offer, but you’re turning an impression of “meh, that loser didn’t make the cut” into “crap, I’m going to run to do some research on hiring best practices…just to prove that guy wrong, of course, but, seriously, ohmygod, are we doing it all wrong?” (If you’re a regular reader, what’s actually just happened is that you’ve refused to play the sucker’s/idealist’s game of “trivia contest” and offered an assessment of the organization that’s above the interviewer’s paygrade, which is some opportunist-fu that will blow the idealist’s mind).
Hopefully, if enough people stop lining up for the airport security screening process that is hiring at big tech companies, the emerging labor shortage will cause them to grow up and innovate when it comes to staffing developer talent. But, I wouldn’t count on it. The interview in its current incarnation has as much momentum as it does ineffectiveness, and I don’t expect it to die the death it should anytime soon.
So let me instead, put on my organizational hat and be philosophical. As I said in the beginning, I think the solution to broken hiring isn’t to fix it, but to stop it. And, by “it” I don’t mean to stop bringing on new people, but rather to stop asking strangers to submit pieces of paper full of exaggerations for your review so that you can bring them in cold, grill them for a few hours, and then welcome them to the family. Wow, it sounds almost…stupid, when you describe it as exactly what it is.
Rather, what if you simply placed a creative constraint on the organization that it could not grow by hiring strangers or unknown commodities? I’ll grant you that this is an incredibly tall order, and the easiest thing in the world would be to list all the ways it could never work or all the concessions that would be needed. You’d have to grow a lot slower! Yes, probably, but I don’t know that growing like an out of control virus is the only way to succeed. You’d lose out on entry level talent! Maybe, or maybe part of your operations would be getting to know college kids. You’d be hiring based on nothing more than someone’s word! Well, you’re already doing that, but with someone that no one knows. And the list goes on.
I think of this in the same way that I think you’d have seen the Tesla a lot sooner if someone had waved a wand and said, “Starting in the year 2000, cars can no longer be powered by gasoline.” When the status quo isn’t causing an international panic or creating an obvious and massive market opportunity, people are pretty comfortable with it. But if you imposed a constraint on yourself (ala Tesla), you might be amazed at what you could accomplish.
As I’ve started to expand in detail in my book, I’m more and more convinced that the next decade will show us a massive drop in the numbers of software developers working for megacorps and for non-software companies. The fact that the hiring process for developers, at scale, is garbage is just one reason, but it’s an important one. It’s so important, in fact, that let’s stop trying to fix the hiring process and start trying to figure out how to replace it.
Published at DZone with permission of Erik Dietrich , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.