DaedTech

Stories about Software

By

Hiring is Broken… And It Isn’t Worth Fixing

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 tl;dr.  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).

TriviaInterview

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. You need[sic]

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.

Juggler

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.

Handling Interview Bureaucracy

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.

AirportMetalDetector

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 from 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).

Stop Hiring

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 explain 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.

  • dave falkner

    You’re so picky. In the future I’m tempted to require >70% test coverage and an SSD in my workstation, or at least permission to supply my own. Given these elements, I’ll take it! 🙂

    • Velho Joel

      Yes you are hired if you’ll buy the SSD yourself.

      • dave falkner

        I’ll just grab one from my stack of spares at home and will see you first thing Monday morning.

        • Velho Joel

          I know what you did there, you wanted orange juice without the bulp! You are fired

    • In my travels, > 70% test coverage makes you pretty picky as well. 😉

      • dave falkner

        I’ve worked a good number of shorter term contract engagements in recent years and can say the same for my area. 70% is sadly, pretty much unheard of. Interviewed at once place that said they had something in the 90%s range, but no job offer. In hindsight maybe I should have gotten on my knees and begged. That might make a good LinkedIn profile heading: “Your Test Coverage % is the Same Chance That I’m a Good Fit for Your Team.”

    • IMHO, under 80% means poor coverage, and over 80% means POSSIBLE good coverage. It’s still possible to have 100% and skip a lot of scenarios that break..

  • Nathan Armstrong

    Sounds similar to the sentiments presented in ‘Peopleware’.

    • Never read it, but added to my Amazon list since I’m doing a good bit of research in this arena. Thanks.

  • Kerry Patrick

    I’m a regular reader, and I just have to say, this post is especially well-written. A serviceable burger indeed. How soon until your book is finished?

    • Thanks! I’ve stalled a bit on the book of late, but I have actual, concrete plans to remedy that. I’m wrapping a consulting engagement right now and have specifically stopped taking new ones until I ship the book and one other thing. So my hope is in the next month or two. (Famous last words, but I do have a commitment device now)

  • My company has been hiring to the core product team exclusively through multi-year internships for over fifteen years, with amazing results. Of course, this practice fits mature companies better than startups.

    • It’s encouraging to hear that, and I take your point about mature companies… but I’d like to see a startup model go this way as well. I could easily rant on this subject and the idea of bootstrapping versus funding in general, but I’m going to control myself for the moment.

  • kavis art

    The thing is, for many real-world problems at Google, knowing how to solve so called “trivia” problems actually matters. For example, understanding how to calculate the total number of unique paths, or finding Nth ranked element in an unsorted list as fast as possible is actually relevant in problems that Google has to solve. Source: I interviewed at Google and was rejected, and have several friends who work there.

    • kavis art

      One more thing – they do treat you as a corporate cog, with isolated responsibility and very modular projects.

      • I think that, for a company of Google’s size, that’s pretty much inevitable. A lot of perks to be had there, but being a big fish/unique snowflake can’t possibly be one of them.

    • I’m hoping, based on your/their experience, you can clarify something for me. Is it common for people to have to produce a standard solution to these problems (e.g. “figure out how to sort in n*log(n) time)” or to produce, with a great amount of R&D effort, unprecedented optimizations (e.g. “come up with a sort that beats Quicksort in 80% of starting scenarios”)?

      I ask because one of those would seem… strange. Forcing people to re-solve problems. The other one would seem to go way deeper than the kind of, “let’s see if you remember this from college” superficial examination than would happen in an interview.

      I guess that’s long form for, “in what way are they routinely solving problems like this?”

      • Indeed, even your project contains such task/problem (what is unlikely to happen), it will be solved just once (yes, 1 time).
        The rest of the code/work would be about the rest of the tasks/problems. I’d say 99.998% of time would be spent somewhere else. So you’re interviewing people to work on 0.002% and ignoring the rest?
        Em… I think we need to interview your manager’s manager replacement.

  • cwlocke

    Great post. However, I don’t think Erick of Google is saying, “now wait just a minute — it’s obviously not broken because it did select me.”

    I think he is saying. “You were invited to play this game. You knew the rules and accepted the challenge and now you want to complain about the rules not being fair? Too bad!”

    I think it is a valid reaction (even if it isn’t a good process). Complaining about the rules or the score of a fair game after you lose is just being a whiner.

    • Thanks!

      And, I actually find Erick’s position relatable. (Sad, but relatable, particularly since I’ve spent no small amount of time hiring developers) Even if he had time and wanted to, and sought to make it his crusade, I doubt he’s in any position to change Google’s hiring process a whit.

  • Tom Lagier

    When I recently went through this process, I agree that I felt a lot of “I shouldn’t have to do all of this tangential learning just to get a job! It should be based solely on my skills, experience, and personality!”

    However, I forced myself to do it and was successful having done it. I made it more palatable to myself by focusing on three things (which may or may not be true).

    1. Most of the algorithm type interviews rely on the same, fairly limited question pool. Thus, learning algorithms for interviews is generally applicable across companies, and should serve me well when I want to interview in the future.

    2. Learning algorithms is a means of demonstrating dedication and work ethic – everyone knows that memorizing trivia is not a true indication of software development ability. It is, however, an indicator of your willingness to sit down and force yourself to learn something difficult which can be a critical on-the-job skill.

    3. It is a way that I can differentiate myself from other candidates by time investment. Many other avenues for this exist, and many of them are much more interesting than revisiting college coursework; none of them seem to be both universally accepted by the hiring process and odious to my competition.

    I should note that I’m relatively young, I did not kill myself studying, and I did not get a job at a top-tier company (I currently work at a mid-stage startup). However, I am very happy with my position and career prospects and I think that my investment into algorithms did and will continue to pay off long-term.

    No-one thinks the SAT is a perfect method of determining a college freshman’s academic abilities, yet the preparation process is institutional and rarely questioned. I think the same principal applies to developer interviews – if you’re looking for a new job, you’re going to need to sink some time into re-learning your CS201 basics, along with polishing up your personal site, LinkedIn, and GitHub.

    Could it be better? Probably. Is it utterly failing an entire generation of software developers? I don’t think so. You just have to be willing to suck up your pride and prepare in the ways you’re expected to … if you want the kind of job that hires this way. There are alternatives (such as smaller companies, consulting, and early-stage startups); they all have their own up- and down-sides.

    • Dan Jacob

      > It is, however, an indicator of your willingness to sit down and force
      yourself to learn something difficult which can be a critical on-the-job
      skill.

      That sounds a little bit like “we did it because we had to, so you’ll damn well do it too”. After all we used to force kids to learn Latin to pass their university entrance exams, even they’d forget all their Caesar and Catullus five minutes thereafter. If you’re going to ask trivia, though, why not at least something tangentally relevant to the day to day job? If Sahat is a JS developer, ask him about how a browser renders a page, or the right HTTP error code for a given situation, or a comparison of 3 or 4 client side authentication models.

    • First off, thanks for taking the time to comment in detail — this is almost a mini-blog post 🙂 It’ll be hard to address all points in a single comment, but I’m interested in the conversation.

      Regarding the SAT for screening college applicants, I’m not in love with that process either (and I say this as someone for whom standardized testing proved an enormous advantage when I was younger. In other words, like the job interview, it’s rarely questioned and, like the job interview, I think it needs to be.

      Second, regarding the notion of creating a barrier to entry to filter candidates, I think that’s actually a pretty rational approach. It’s also why, when I’ve historically been responsible for creating developer job interview processes, I’ve been an advocate of having applicants write a small application of some sort. It weeds out people who aren’t actually that interested, and it generates sample work product that I can discuss with the prospective employee.

      That said, I question the value of “unbounded study” as the barrier to entry. There’s no success criteria or definition of done that way, and you don’t know if applicants actually worked or just got lucky in which chapter of their Algorithms text book they happen to glance at. (I actually once delighted an algorithm trivia interviewer because I was getting my MS at the time and had just happened to read a whitepaper on R-Trees, which I used during the interview process, thus blowing his mind — nothing awesome that I did, just right place, right time).

      And, with regard to it proving that someone is willing to sit down and force yourself to learn something… not to be fatuous, but doesn’t any undergrad degree in computer science already demonstrate this?

      I will concede that it sounds like you certainly realized an ROI for your time spent boning up on algorithms. I imagine that a lot of people do, and I don’t think applying to or working at these companies is a poor decision. What I’m advocating for is almost along the lines of a boycott, I suppose. In other words, if I were anti-big-box retailer, I might say, “there’s nothing wrong with you as a human for buying tater tots at Walmart, but I think we should all stop buying tater tots at Walmart.” If that makes sense…

      Not sure if i covered it all, but I did my best.

      • Dan Jacob

        A boycott is all well and good if we’re talking about not buying tater tots. But most developers don’t have the luxury of not applying for any company where there is an outside chance of them being hired.

        I have a feeling that there is a huge disconnect between the US – in particular the tech hubs such as SV and NYC – and the rest of the world when it comes to the hiring. In Europe for example – with a couple exceptions such as London or Berlin – the hiring market for developers is truly dire.

        Furthermore, not all programming positions are
        created equal. If a job asks for “2+ years Rails experience”, well, that counts me out (yes I could learn Rails over a couple weeks. But where’s that 2+ years experience going to come from?). The number of positions where I score 100% in buzzword bingo is very small, and I’ve noticed it’s not even worth applying for jobs where I don’t. So even if I apply
        for US-only jobs, the pool of positions I have a real chance of even getting to the interview stage is vanishingly small. I’m not about to make it even smaller by boycotting potential employers.

      • Tom Lagier

        I think your basic point here is that things are not going to change for the better unless the generation of developers that currently has issue with the way that development hiring is done acts as the the agent of change. I think that’s absolutely true – if you’re not willing to stick up for what you believe, people are not going to change their systems to accommodate you no matter how much visibility there is (twitter, blog posts) into the issues with the system.

        At an individual level, I think there are some issues with that approach, at least for many of the individuals most expected to perform well on algorithms.

        1. How many options do you need to have available to you in order to have the luxury of sacrificing some because you do not like a standard hiring practice? I think that you need to be negotiating from an advantageous position in order to do this – you need to be interesting enough to the type of companies unlikely to use trivia as a key component in their process that you can reasonably expect to get a job with one of them. I would argue that that requirement rules out a large number of {average, junior} developers.

        2. What if the sector of companies you are interested in working for or that has the type of work you like to do simply not allow for this option? It’s okay if you say “well, I didn’t want to work for that sort of company anyway”, but I think there are many attractive companies that are not likely to be receptive to this tactic.

        I think that it is fairly unlikely to elicit true change without some sort of strong statistical backing and a tested superior strategy. The onus is on hiring managers to stop, re-evaluate their process, and really think hard about the best way to filter candidates in a way that is both efficient for both parties, and more representative of actual on-the-job talent and culture fit.

        It is vital to come up with a strategy for hiring that is a) no less efficient (number of new hires generated in a time period) than the current, imperfect solution and b) creates stronger new hires (based on whatever metric).

        The data for both of those points is available, I think that it will take a concerted effort to expose exactly how inefficient the current system is, and how much better new hires perform under a new system in order to actually enact any tangible change.

        Thanks very much for your article, BTW. I really enjoyed reading it, and your message to recruiters. I’m just wary of potentially sacrificing my chances at a company that would be a good fit based on my distaste for current hiring practices!

  • Dan Jacob

    Hold on. If I understand correctly, if you just end up hiring “people
    you know” then not only college kids then a whole lot of people who
    don’t happen to have great networks are going to be excluded.

    This all sounds great if you live in one or two tech hubs around the world,
    but if you happen to live out in the boondocks then it’s another matter
    altogether. Personally as a remote worker and immigrant I know I’d
    never be employed in tech again, as the nearest meetup is in the other
    side of the country and there are no decent companies in my area.

    I share Sahat’s frustrations as I realize
    how worthless a set of Github projects and blog posts are in furthering
    your career, but I am puzzled by his masochistic charge at the windmills
    of mindless bureaucracies. I know my limitations (yeah I can do a
    half-decent BFS implementation off the top of my head but they’d
    probably trip me up on some other trivia) and will stick to small to
    medium sensible companies. But if my career depended on being in some
    inner circle of confidants I’d just leave tech now and find something
    else to do until retirement.

    • No worries, I’m not advocating something that would impoverish all of the world’s developers outside of San Francisco and New York. For what it’s worth, I work entirely remotely (when I’m not traveling) and I’m doing my best not to spend my time in any major hubs, either.

      When I talk about companies growing without doing the “interview a stranger” thing, I’m including more growth models than most people would probably think of off the top. For instance, “employee refers his neighbor/buddy” comes to mind, but not “employee refers his high performing college lab-mate that lives halfway around the world.”

      But there’s another element to this as well. Companies, even juggernauts like Google, need you more than you need them. By 2020, the world is project to have a *million* more programmer jobs needed than programmers to fill them. So companies that need help and shouldn’t do it by hiring strangers, will need to come to *you*, wherever you happen to be. And they’ll need to figure out how to get to know *you*.

      Most of my posting/writing tends toward being developer populist with a realpolitik flavor. Believe me when I say I’m not advocating for anything that cuts a world needing our labor off from our labor.

  • An interesting take on the problem. But if you hire only by word of mouth you just get the most able social navigators. That ain’t automatically a bad thing but it doesn’t always correlate with technical skill either. What if there are way too many great developers that are way too anxious to make this a generally good hiring strategy?

    • Social ability (“pleasantness to work with factor” if you will) would certainly play a role, but I’d say not an outsized one. Imagine that you’re working for an organization and they say, “your team needs to grow — can you find us someone?” Are you going to hire a smooth talking deadbeat or are you going to hire someone you’ve worked with in the past and can count on to deliver?

      • I was thinking something more along the lines of “Found some friends at a local tech event, and now I’m referring them. But turns out, not all of them can deliver. Though they sure are nice people.”

        If you make “only people you worked with” a rule then it’s different sure, but in the same vein, people would be incentivized to recruit for friendship not for delivery skill. Unless you make a it a point to punish people that vouch for hires that turn out to be bad.

  • How Google wants to hire is of course google’s business. But there’s a lot of wannabe Googles out there that aren’t quite Google that are imitating what Google does not because it is particularly effective but because they can pretend to be more like Google that way.

    One of the problems is that in IT companies are trying to recruit people that are essentially extremely high in demand. From that point of view the question if the candidate is suitable for the company is less relevant than the question whether the company is a good match for the candidate. In my experience hiring good people, a key thing is really selling the job to the candidate. In other words, it is a sales process that involves selling a job vacancy to a suitable person. In the process you get to know them and you mostly talk about their needs and interests. Few companies do this right. For starters, letting HR people or recruiters loose on candidates before they’ve met anyone that can actually talk business sends the wrong signal: you are not important to us. Good people get asked and won’t come begging to your temple of HR.

    • I completely agree with all of your points here. I’ve spent a lot of time in the last few years trying to hire developers, participating in hiring processes, and even designing them, and it amazes me how developers on the whole don’t appear to realize that they’re holding all of the cards. To your points about first contact not being with the HR machine and about selling the company, I’ve been playing with ideas around automated utilities to find people who write the kind of code that I value, and then offering introductions like “hey, the way you implemented that new ORM was pretty impressive — want to chat about it?”

  • Taylor Huston

    This post is significantly better written than the one that inspired it, but my sentiment remains the same (copypaste of my response to original post).

    Life is a video game. Well really a series of minigames. Some of the minigames aren’t as fun as others, but you have to pass them to move on. Right now you’re on the ‘get hired as a developer’ minigame. You beat that minigame by memorizing things like Algorithms and Data Structures.

    Yes it’s stupid. Yes it’s not something you’ll ever actually do on the job. No it’s not a real indicator of your actual programming ability. But it’s what you have to do to beat this part of the game and move on. And, yes it sucks, but it’s not THAT hard in the grand scheme of thing. Basically what’s happening is someone is saying “we’d like to hire you for a job that pays significantly above the national average, is safe, low stress and generally pretty easy when you think about it. All we ask in return is that you brush up on some things that you have already had to learn anyway.”

    I would also argue that it’s at least partially about seeing how driven you are. Everyone knows that you’re probably going to get asked Algorithm and DS questions in an interview. There are literally several very popular books entirely dedicated to that fact. So you can either have a self-centered, egotistical, “I don’t think I should have to know this and I know better than everyone else so I am not going to learn it” attitude, or an open, eager “I really want this job and I know they will probably ask me some of these kinds of questions, so if I have to take a week to brush up on these concepts I am more than willing to do so attitude.” Which do you think makes for a more attractive potential employee?

    Maybe it’s because I am still relatively new to the industry, still trying to “break in”, but if the only hoops I have to jump through to land a fantastic, well paying job all involve me just brushing up on stuff I SHOULD already know, well, I mean, come on. Maybe when one day I get to the point where I am such a special snowflake programmer that I shouldn’t need to go through an interview process. But in the meantime, I am like most programmers (and really most job seekers in this not-so-great economy general), I realize that it’s a dog eat dog world out there, no one is going to just hand you what you want. You have to earn it, you have to work for it. If that involves going through a few obnoxious interviews, so be it. It could be a LOT worse.

    Never forget that there are people out there busting their ass 80 hours a week digging ditches just to get by.

    • I’m glad if you thought it was well-written. As for offering the same comment to me as to Sahat, I understand your points, but, apart from sharing an opinion that megacorp hiring leaves a lot to be desired, he and I don’t have a ton in common.

      It’s been years since I was a line-level developer, and, back when I was, I didn’t struggle to get job offers following interviews. I’m not criticizing the hiring process from a place that’s personal to me at all — I’m criticizing it because I think it’s extremely ineffective.

      Interestingly, the thing that exposed just how random and ineffective this type of interview is wasn’t me failing one — it was me *nailing* one. I wrote about it here, if you’re interested: http://www.daedtech.com/best-way-hire-developers/

      If I’m the best candidate you’ve ever seen because I happened to read some bit of arcania last week, your talent acquisition process is FUBAR, and it’s only a matter of time before that leads to the sort of brain drain that inevitably plagues big companies, leading them into “irrelevant” and then “sold off for parts” statuses.

      In short, what I’m advocating for here, in this post (and more broadly in life), is that companies rethink the entire process of sifting through piles of stranger resumes and LinkedIn profiles, and attempt to pan for metaphorical gold in the river.

  • Noam

    I think any developer that studied computer science, should know how to write bfs even without studying for an interview. I think it’s very simple.
    maybe it’s just me.

    • Seems like a simple construct, but then, after all the CS course work I took, most of them do, once I shake off the rust. Truth be told, I wasn’t actually contemplating the particular algorithm review being asked for. (I don’t consider is overly relevant)

      • Noam

        I think it is a simple coding question. I like to ask coding questions in addition to knowledge questions. I noticed that people already memorize the “what is the difference between interface and abstract” questions.
        that’s why I like to give 1-2 simple coding questions. I had somebody saying that asking about linked list is hard. linked list…go figure.

        DFS or BFS are not hard. recursions is something I rarely use in my real work, but it’s a simple concept that I think any developer should understand.

        bottom line – you will be asked coding questions in some places. if you are not strong in recursions, just spend an hour and be ready.

        • Just out of curiosity, are you talking about a phone screen here, or an introductory part of the interview?

          As an aside, with managed and interpreted languages dominating the landscape these days, is linked list something that gets a lot of play anymore? (Meaning, if you spent a lot of years in the C/C++ world worrying about memory allocation, the heap, and the stack, it’d be a no-brainer, but I wonder if, for some, it’s now a historical curiosity)

          • Noam

            this is on site interview. I start with warming up question. interface vs abstract. value type vs ref type.
            questions that you might say “who needs to know that?” but I think that in today’s world, in the copy & paste from stackoverflow, I got to start with the basic .net questions.

            next I move to coding. it could be simple traversing on a binary tree, list or even fizzbuzz. again, nothing crazy. finding out if there’s a cycle in a linked list should be very easy for a senior developer (I would say every developer with more than one year experience).

            I also like to ask about current projects and design questions. I expect that from a senior developer.
            if I see ‘unit test’ on the resume, I will ask about that. I had one guy with ‘unit test’ all over his resume. guess what? he never heard of Mock.
            some people will load their resume with keywords without even actually having a real experience.

            so I guess you can say we never use linked list, but it is one way to know if the person you are interviewing is capable of facing a challenge and deal with it.

          • Oh, FWIW, I wasn’t intending the question about Linked Lists to be Socratic or suggestive. I was more just musing, as in, “that reminds me of programming 10 years ago” which made me wonder if people just starting in the industry now even know what that is.

            With regard to the unit test candidate… I have encountered a lot of people who use the term to mean “after I make changes, I run the application to see if the result is what I expect.” I’m wondering if that was the case…? Dunno, though. Pretty bad however you slice it.

          • Noam

            the unit test example is an example of something to talk about with the candidate if I see it on the resume. I won’t ask about it if it’s not on the resume. but if it’s 5 times on the resume, for every job the candidate had, I think it’s a good subject to talk about and see if the candidate understand.

            overall I try to get a mix of few things (and this is for a senior):
            1)general (easy) .net questions.
            2)coding.
            3)design.
            4)questions about his current or past projects.

  • Eric,
    Thank you for your post. I find the problem very interesting and I like the way you think.
    I would like to expand some of your ideas, but first a few observations.

    1) What we are discussing here is a first world problem. We have it really good. Our hourly rate is very high, there are tons of jobs available to us, we can work remotely, work flexible hours, climb the corporate ladder or stay at our current level. We get learning on the job at a click of a mouse, and we have time to read and comment on posts on how hiring is broken while we work.

    2) The basic assumption of the entire discussion is that there’s such thing as win-win outcome for the hiring problem which will leave everyone happy: The company shareholders, the current workers, the candidates who got the job and the candidates who got rejected. This assumption is flawed. Job market is a competitive field and losers will be sore because losing sucks.

    Having said that, I agree with you that it’s not worth it to fixing hiring process in any company except your own. Moreover, it’s not worth it to discuss it with others as well. Because hiring is a competitive process and if my company can hire smarter then it will win in the long run and why would I want to tell my competitors how to steal my best people and keep them?

    And finally, if we would forget for a second that we are discussing OUR jobs, OUR interviews and OUR industry the whole picture could become much more clear.

    Let me retell the story with a few substitutions.

    There was a pizza bus boy who used to work in Dominoes. That bus boy was an awesome individual. He loved cooking at home. He cooked alone and with friends and shared his culinary creations to neighbors for free. He wanted to get a job in New York city, went to a few places, didn’t get a job. The kitchen workers were jerks. He didn’t like the questions. Now he’ll keep cooking for free or will try to get a loan to open his own pizza shop. The Pizza industry is good, but the hiring process there is awful. Let’s fix it.

    My point here is: who are we to tell pizza shop owners how to hire their staff? They stay in business somehow, it’s their business after all.
    All we can do as bus boys is find a place that will help us pay the rent. And while we do it, we’ll gradually get better at interviewing.

    • Hey, Alex. Glad you liked the post and the topic. It’s actually pretty easy for me, personally, not to let my positions be colored with a horse in the race, since it’s only my industry (I don’t have a salaried job nor do I want one, so I don’t sit on the candidate side of interviews).

      The topic of hiring and whether or not it’s a zero sum game is an interesting one. I think it’s almost a tragedy of the commons situation. Getting hired at a given company as a backfill is a clear cut case of a zero sum game. There is one position and, say, 10 candidates, and one of them getting the job means the others don’t. It gets a little less clear when the company is in growth mode or staving off attrition and there are a nebulous number of openings.

      But hiring in the industry is hard to couch as a zero sum game. This is where the tragedy of the commons comes in. I go around helping companies in various ways as an IT management consultant, and I can tell you firsthand that there are countless companies out there with developer job openings that simply do not get filled. By anyone. The positions just sit open for months or years, and the work doesn’t get done. These companies simply cannot find anyone who knows how that is willing to come work for them (because of location, industry, domain, comp, whatever).

      So, taking the industry as a whole, developer A getting a job is more or less irrelevant to developer B. I would also argue that, from the company’s perspective, getting fixated on which particular person they hire is an activity with negative marginal returns. They’d be better served just to pick at random and let their developers get back to work. (But that’s a whole separate post, if not a book that I happen to be writing 🙂 )

      • Erik, thank you for the reply. Your perspective as an IT management consultant is very interesting.

        In a way, hiring scene is very similar to a dating scene. On one hand, everyone is waiting for Mr/Mrs Right, but on the other hand no one wants to be Mrs/Mr Right. However, overtime some people do mature eventually. And what they eventually learn is that marriage is not like dating. A successful marriage requires a growth mindset but most people approach dating with fixed mindset.

        The main limiting factor of companies who can’t fill their developer openings is fixed mindset and the hiring process is just a tip of the iceberg. ( I’m pretty sure that’s what your book will be about ). I wish you great success in fixing the fixed mindset of your customers. We all know it doesn’t happen overnight but we also know that there’s no other way to make things better.

  • Bethly

    “Rather, what if you simply placed a creative constraint on the organization that it could not grow by hiring strangers or unknown commodities?” would be even more discriminatory than our current process. It prioritizes fitting in over any particular skills, and having free time to network and write external code over professional work.

    • Regarding the networking/external factor, I’m not talking necessarily about hiring people on the conference circuit. I would envision “known commodities” including, and, in fact, relying mainly on people with whom members of the team had worked in the past and would vouch for.

      As for discriminatory, I could see that happening, particularly if those being relied upon for leads had come from monocultures and enjoyed them. So, if we accept as axiomatic that the existing process of stranger hires and trivia interviews is also discriminatory (for which claim there is ample evidence, that includes things like natural bias to hire taller or thinner people, to say nothing of gender/ethnicity biases), what alternative constraint would you propose?

      (I’m asking earnestly and not rhetorically — I’m doing a lot of research on this subject and am interested in ideas)

  • Matthew

    Thanks for this article. Fantastic writing!

  • Spinoza Senpai

    It occurs to me that much of the process may not be about one’s qualifications, but about whether a superior power relationship can be established with you. These corporations look for docile, exploitable employees. This may not be fully conscious and is probably just an evolution of sorts. Just a thought. Great article, BTW.