What’s Your Greatest Weakness: The Employer-Candidate Impedance Mismatch

I recently posted about why you shouldn’t take interview rejection to heart.   I promised at least another post, if not more, to follow on that one, and here I am, making good.  This is where I question the value of interviews as we know them and describe what I consider to be vaguely depressing about the way we come into work.  Naturally, I’ll start this off with a non sequitur about circuitry.

In the world of circuitry, there’s a concept known as “impedance matching,” which, (over) simplified, says that you should match the output impedance of one component to the input impedance of the component into which the first one feeds. In this fashion, you prevent inefficiencies in or possible damage to the circuit that you’re constructing. The term was co-opted and inverted in the world of software (“impedance mismatch“) to describe the awkward transformations that occur when object oriented applications use relational databases to store information. Colloquially, you might say “you’ve got two puzzle pieces that don’t fit together quite right and you’re jamming them together.”

And so it goes, I would argue, with employee-employer matches in the corporate world. Of course, it doesn’t seem like it on the surface when you consider labor as a simple market transaction (or even when you factor in the middle-man, quasi-rent-seeking behavior of technical recruiters). A job seeker is selling labor and an employer demands labor, so the two negotiate on the price, with each trying to maximize its own interest (pay, but also benefits, days off, cultural perks, etc). Cut and dry, right?

Well, not so fast. Employers don’t make hires in a vacuum but rather they commonly hire people with some regularity and have a “general hiring strategy.” Employees do, on the other hand, get hired in a vacuum and their only strategy is maximizing their situation using rational self interest. So employees seek to maximize the perks with the best offer, but I would argue that companies in their hiring optimize for eliminating worst case scenarios rather than maximizing the upside of any individual hire. Put simply using examples and probability theory, consider the following scenario.

A company has a choice. They can hire Alice or Bob. Bob is a known commodity and a decent software developer. He’s not going to blow anyone’s socks off, but he’s not going to check in terrible code. Alice, on the other hand, is a divergent thinker and extremely creative. Based on her history, there’s a 75% chance that she will be a game-changing hire in a good way, delivering way more value than most people, improving those around her, and bringing true innovation to bear. But, there’s a 25% chance that all of the things that make her special will fail to mesh with the existing team, and there will be fireworks followed by a flameout in short order.

In my experience, most companies will tend toward hiring Bob, even though the expected value of offering the job to Alice is higher (calculated, say, by Bob having a 100% chance of delivering a 5 out of 10 and Alice having a 75% chance of delivering a 10 and a 25% chance of delivering a 0). Established companies favor avoiding disaster more than reaching for the stars. Bob has a zero percent chance of delivering a zero, so Bob it is. And so, we have an impedance mismatch between the zero sum games being played by both sides. Applicants operate in a world where each side is maximizing expected value, but companies play in a world where they are minimizing worst case scenarios.

This has a resulted in a depressing process by which job offers tend to happen — an interviewing process focused at every turn on “screening.” Take this test. Let’s do a phone screen. Come in for a first round interview. All of these activities are generally oriented around thinning the herd rather than finding the leader, and they’re also intrinsically tolerant of false negatives. Gotta break some eggs to make an omelette or, in other words, “sure, you’ll reject some qualified candidates, but you’ll (theoretically) guarantee that no complete duds will be hired.”

But once you make it past the “screening” hurdles, it switches gears and really does become a matter of selecting the preferred candidate.  That is, in most candidate searches, once all but a handful are screened, the question becomes “which of these do we like best?”  And this question is answered by talking to the candidates for a few hours and then choosing one (or perhaps more, depending on whether hiring is being done for a specific position or to compensate for attrition/allow growth).  So, let’s think about that — after a comparably objective filtering out process comes a largely subjective game of “based on a conversation of a few hours, let’s find someone to spend the next several years with.”

I have an operating hypothesis that I’m not really in any position to test for the time being.  So, be warned — here comes some frankly unsubstantiated conjecture.  My hypothesis is that this reductionist “pick the best of five” activity would be no different, statistically, than random selection of a candidate.  However much we might think that this personal interaction-based reading of the tea leaves brings the ‘best’ candidate to the top, it really doesn’t matter.  For every “bad attitude” candidate you successfully pass on, you’ll filter out “better attitude having bad day.”  For every candidate you hire because she nails the “what’s your greatest weakness” question due to cultural fit, you’ll hire someone whose greatest weakness is being a lying but convincing sociopath.  The “interview five, pick one” process strikes me as the same kind of process I go through when squinting at mutual funds for 10 or 15 minutes before deciding how to allocate my 401K.  I have no idea what I’m doing, so I just pick one and hope that everything works out.  My hasty “research” is entirely a self-administered placebo designed to make me feel better about some kind of due diligence.  And that’s how we, as a society, hire people.

So, the typical hiring process is one that is designed to first filter outliers and then secondarily to pick from the best of those still standing.  But there are two core problems.  Filtering outliers means filtering all outliers and not just the bad ones, meaning a potential drive toward mediocrity (or at least standard) and picking from among the best is essentially (axiomatically, here) window dressing on random choice.  So the candidate search, for all its clever questions, stress interviews, fancy clothes, synergies and whatever else we dream up really just boils down to “filter for slightly above average and pick at random.”  And I’m pretty sure that you could do that with submitted SAT scores and a dartboard, saving everyone time, money, and dry-cleaning bills.

Before you think I’m some kind of self-righteous voice from the clouds with everything figured out, I’m not.  I’ve conducted and participated in this process, willingly, from both sides.  I think everyone would agree that candidate selection is a reductionist activity with an insanely high margin for error and the fact that many companies have actual protocol in place for dealing with hiring misses attests to that very fact.  Gains made by introspection tend to be heuristic and not algorithmic, but I’ve played the good soldier with the rationale of “this is the worst way of doing it, except for all of the other ways I’ve considered.”

I still don’t have a particularly concrete solution, but I do have the beginnings of some ideas.  Github is quickly becoming an industry standard place to say, “look what I can do, left to my own devices.”  Stack Overflow is a place where not only can developers showcase their knowledge and accumulate points, but they can prove to would-be employers that their peers consider them to be knowledgeable.  Blogs are somewhere that interested employers can go to see whether a candidate would be a good fit in a waterfall shop. Coderbits pulls a lot of theses sources together into a single point of information.  These sources of information are freely available, asynchronous, and aggregate.  My life is summed up much better in these venues than it is by me sitting in a conference room, wearing a suit, and talking about a time I faced and overcame a challenge.

But I think there’s room for additional improvement as well.  How better to know whether a candidate will do well on a project than putting that candidate onto that project?  What I’m about to talk about is not currently tenable, but imagine if it were.  Imagine if there were a way that an organization could structure its work in such a way that onboarding time was virtually nil and so prospective developers could be tossed an assignment and get started on contract.  Is it working out after a week?  Great!  A month?  Great!  Now it’s been six months?  Great — let’s move to a more permanent W2 arrangement and thus from dating to marriage.

Employers could dispense with the prognostication games and tests and simply shuffle ‘candidates’ in and out, keeping the ones that were the best fit while passing on the ones that weren’t.  For candidates, this is great too.  You’d no longer be faced with these, “do I take this huge, life changing leap or pass and watch my situation deteriorate?” decisions and be able to generate income while shopping around.  A mutual feeling out period would allow a fit based on experience, rather than conjecture and games.

There are two enormous hurdles to this.  The first is the problem of benefits and the mind-numblingly unfortunate practice of health insurance being tied to employment.  If the USA has a spasm of collective sanity in this regard, perhaps that problem will go away at some point.  The second problem is actually making it viable for organizations to take on developers and have them go from unknown to “writing productive code” in a single day.  And solving that problem is also non-trivial.

But personally, I’d like to see more discussion around hiring processes that involve trial periods and shortening of obligatory worker-labor consumer relationships.  This isn’t to say that I think everyone should endure the stress of a job search on an almost constant basis, but rather that I think it should be easier for people and organizations to move seamlessly into arrangements that are better fits.  We should dispense with the pretense that indefinite stays are the norm and recognize that it’s going to vary widely by individual taste and personalities and projects involved.  In the end, moving in a direction like this could conceivably do wonders for morale across the industry and go a long way toward eliminating institutional knowledge hoarding in favor of beneficial cross pollination.

Update: This post has been in my drafts folder for a week, but I happened recently to stumble on this video:

“Pick the fourth resume from the top.” I’m not alone in my hypothesis that random selection would be a reasonable replacement for conversational interviews.

  • Pingback: The Baeldung Weekly Review 27

  • http://www.koenmetsu.com/ Koen Metsu

    Couldn’t this problem be solved with your idea of Free Agency (http://www.daedtech.com/notes-on-job-hopping-part-4-free-agency) ? Afaik, freelance work already is much more like this: jobs are set for 3-6 months, after which extending that period is possible.

  • http://www.daedtech.com/blog Erik Dietrich

    Certainly, it can. But a lot of people don’t really consider that a viable option — risk averse people, people who need medical insurance, etc. I’ve been trying to think of a way for this paradigm to emerge without it requiring a leap that’s really scary for a lot of people.

  • peterho

    Where I work we do resume screening and then a rather short first interview. If we move forward after that we do a 4h programming task in our office. The task is to construct a small program using the language and tools that you’d be using in the job on a laptop that we provide. Almost everyone working here have done the test (at some point).
    This is great to screen of programmers who can’t write more than Hello World, although somewhat costly in terms of our time. We also think we get a real feeling of what the person will be able to do on the job, and that has proven to be quite accurate. But, we do are aware that we single out people that can deliver on this test (and thus is some sort of cultural fit), and may remove other candidates that would have been able to contribute to the actual work. And I bet there are a ton of programmers that will flunk our test but still be very productive elsewhere.
    As Joel Spolsky said, a programmer should be smart and get things done. That is what we think we can find with this 4h test.
    Regarding outliers, we have found some very positive ones in the test, and those we hire (after a second and third interview where we just make sure they’re not sociopaths, hoping we can do that). But then again, we might miss some others.
    Long comment on a great post!

  • http://www.daedtech.com/blog Erik Dietrich

    Thanks! Glad you liked the post.

    And, for what it’s worth, what you’re describing that you do in your interview process is sort of a tiny, quick version of what I had in mind. You’re dispensing with the trickery and what not and focusing your hiring process around whether the prospective candidate can actually write software and do so effectively in your environment. I am definitely a proponent of the programming task/exam approach as a way to evaluate programmers. And the “sociopath check” makes sense too — meeting the person isn’t horribly time consuming on either end, and at least lets you see if someone is capable of controlling themselves in a professional setting.

  • peterho

    (Of course I like this method because I myself was hired with it and therefore did well on the programming test ;-)
    I think the key is in the task. Having a rich task with many different problems and challenges. I don’t think the classical interview coding problems say much of anything. Even if you do 10 of them.
    Even better to do what you describe of course.

  • http://www.daedtech.com/blog Erik Dietrich

    Yeah, the longer the task, the better (at least purely from an evaluation perspective). I’m not big on “programming problems,” per se. If I’m going to be hiring people to write code, I’d definitely prefer to see them write code in as close an approximation to their eventual job as I can.

  • Pingback: The Tipping Point | Code Ukemi