1. 6
  1.  

  2. 6

    No dispute that whiteboard coding is a poor, even counterproductive, selection process. That said, if three interviewers in a row asked me to implement breadth first search, you know what I’d do? Memorize how to implement breadth first search.

    1. 3

      I’m actually very good at whiteboard coding and brainteasers, so this isn’t my issue. However, I really dislike the whole “1000 bad passes is better than one bad hire” attitude (if a single bad hire can do that much damage, your management is pathetic and should be fired wholesale) and the mentality that candidates (and employees) are essentially disposable and can be discarded for stupid reasons.

      1. 1

        1000:1 ratio is quite the exaggeration. I’ve never seen a company that unbalanced.

        I would say the cost from a bad hire is not the direct damage they do, but the opportunity cost of not having a good developer for three months because the req was filled. (One month for them to start, one month to notice they’re worthless, one month for performance improvement plan.)

        The interview is a selection process, which is hopefully biased towards good hires. Perhaps 9/10 are good. There’s also some unknown to us number of bad passes. There’s also the ratio of bad hires and bad passes. Let’s work with an assumed ratio of 1:1. Each bad hire sets us back three months. Each bad pass sets us back however long it takes to find another good candidate. Maybe two weeks? A month at the outside? So we benefit by tightening the selection process to reduce bad hires. Maybe somewhere around 6:1 is the “ideal” ratio.

        1. 1

          I would say the cost from a bad hire is not the direct damage they do, but the opportunity cost of not having a good developer for three months because the req was filled. (One month for them to start, one month to notice they’re worthless, one month for performance improvement plan.)

          Salary is peanuts. The cost of a bad hire is in morale, management overhead, organizational complexity, and technical debt. The ones who are fired within 3 months don’t do much damage. The problem is that many never get fired, or get fired after years, because they’re good enough at politics to keep themselves afloat.

          Also, severance is cheaper than a PIP (morale issues when a “walking dead” employee comes in for a month). In any case, the cost of a merely useless hire is probably $50,000 all-in for a company. Again, chump change. The cost of a really terrible hire goes into the millions. That I’ll grant. I don’t know that the obnoxious practices that are becoming standard (I’m more against back-channel reference calls, which is likely illegal, than whiteboarding) do much to prevent the really bad people from getting in. If anything, they make the problem worse.

      2. 2

        I never really understand the hate on whiteboard coding. My guess is that most people are using it to actually judge the code rather than as an opportunity to ask the candidate to describe how they think and solve a problem. In the hiring that I am doing, the actual quality of the whiteboard code is evaluated but has a pretty low weight. I also make sure a candidate is aware that they will be doing some whiteboard coding an give them the opportunity to prepare for it. Some portions of the interview I do is a metainterview of informing a candidate what they are expected to do in the interview and evaluating if they prepared appropriately for it. For another example, I make it clear beforehand that they will get questions about fundamental algorithms and datastructures. I’ve read many people throwing a fit about them saying they will never have to implement a tree in real life, which is probably true, but if given the task “be prepared to answer questions on these things” I’m evaluating if they actually took that task seriously and did some work around it. Again, weighted, so it’s not a make or break, but with the caveat that it’s impossible to run the experiment again, the people I’ve hired have worked out pretty well. I would say 3 out of 4 people I’ve hired have not actually gotten the correct answer in the interviews I’ve given them but were able to elucidate their thought process. But maybe I’m going about it wrong and just don’t know.

      3. 2

        The problem is ultimately a similar problem to standardized testing - I’m terrible at tests (and interviews). They give me awful anxiety, and they don’t accurately reflect a real world application of my skills.

        This is particularly true in the case of an interview. That being said - interviews should be given and designed around understanding how a candidate thinks/works and every effort should be made to make them feel like this is a team effort and not an adversarial experience where their fate lies in the hands of the interviewer.

        Either way - the system is boned, and that is especially true at the big corporation level.

        1. 2

          Cross-posted to Reddit:

          I’m coming late to this party, but the conclusion that I’ve come to is that the software industry is badly managed because, since it what we do was so productive for such a long time, it has tolerated a lot of mismanagement. When software works, it pays off so handsomely that companies can tolerate a lot of failure and still succeed. (A VC bubble helps.) The surplus generated by software’s obscene productivity has not been paid back to engineers, but spent on executive indulgence and broken processes.

          Most good engineers I know bat about .075 to .100 when it comes to interviews, as soon as they’re a few years out of college. (For college kids who aren’t expected to know any better, it’s 2-3 times that.) This is in reference to qualified, smart, effective people– not unqualified perennial candidates (although there are plenty of those, and they end up somewhere). Companies believe that false negatives are OK and that 1000 bad passes are better than 1 bad hire. (Of course, that’s ridiculous. A bad pass means there is some likelihood of a bad hire.) They’re also so flush with cash that they can afford to expend an enormous amount of employee time on interviews, and therefore they can pass (or even fire people) for stupid reasons. (Trust me, we’ve all been rejected for horrible reasons.)

          As programmers, we generate a ridiculous amount of value for our employers. And what do those employers do? They hand it over to executives and they invest it in mismanagement and waste. This allows them to run these absurd hiring processes that have false-negative rates that any other industry would consider unacceptable.

          It’s weird that for corporate executives making millions per year, an “interview” is a 2-hour lunch; for programmers writing 250 lines per month of new code in the bowels of giant companies, it’s 5 hours long and involves homework exercises and sometimes even back-channel reference calls.

          Also, when executives say, “Good people are our most valuable asset”, what they mean is “People like me”, and of course they’re going to say and believe that because it justifies their own astronomical salaries. That may or may not be correlated with anything else.

          1. 1

            Per usual with your comments, they are well-worded and I am in agreement the a majority of it, but here and there I find a detail calling out to me for a followup. In this case:

            It’s weird that for corporate executives making millions per year, an “interview” is a 2-hour lunch

            What data (or even just anecdotes) lead you to believe this?

            And should you happen to be privy to it (e.g. in the case of an anecdote), how have the companies that hired based on a 2-hour lunch interview fared under said executives? I ask due to a few anecdotes of my that run contrary.

            Apologies if I’m picking at something that wasn’t meant to be a major point, or was meant as hyperbole.

            (Edited for some phrasing, and improper formatting in my quote)

            1. 3

              Apologies if I’m picking at something that wasn’t meant to be a major point, or was meant as hyperbole.

              It’s semi-hyperbole. It’s not like anyone who can keep himself together for 2 hours can just decide to be a corporate executive. It’s that people who are born into that class (the good-ol'-boy network) don’t have to do more than have a lunch to get CEO-level jobs, whereas for the rest of us it’s a lot more difficult, even to get average jobs.

              Organizations tend to develop an effort thermocline: the level at which jobs become easier with increasing rank instead of harder. What one learns over time is that society itself has an effort thermocline. Programming jobs are about as high as one can get without developing the political skills to cross the effort thermocline, so they’re a lot harder than executive jobs where you basically get to define how you’re evaluated and write your own performance review (unless you flame out politically).

          2. [Comment removed by author]

            1. 4

              Yeah, my main problem with code tests isn’t that they exist. It’s that you have to do a code test for every single company and they all have idiosyncratic, weird expectations. I’ve seen people get rejected over the smallest, stupidest things in their code samples. (Granted, this is because they’re usually read in a bad mood, because most submissions don’t work or aren’t very well done.)