Programmer hiring is broken because of whiteboard interviews | Hacker News Reader

Programmer hiring is broken because of whiteboard interviews

medium.freecodecamp.com

13 pointschetanahuja7 comments

"I would argue most of the people who reject whiteboard interviews can't actually code"

A comment like this currently on top of this post just shows how broken the whole thing is. Of course the fact that this rejection of whiteboard interviews is coming from people who're doing the hiring (like myself), rather than interviewee's doesn't seem to make a whit of difference to the commenter.

I'd say it's broken because often hiring is done without an actual need, and just to hypergrow because that's what you're supposed to do. Even when there is a legitimate need there's usually zero understanding on the part of the organization or hiring manager how to scope that need and understand what kind of person can fill that need, and thus no idea what a good assessment or process for assessment even looks like.

Whiteboarding interviews are terrible, but they're symptomatic of a process and ethos that is far, far more broken than simply demanding an absurd dog and pony show to be carried out under ridiculous conditions.

I see this same opinion posted over and over again. I would argue most of the people who reject whiteboard interviews can't actually code. Because if they could, they could learn these algorithms in 2 weeks and be a bette coder for it, like everyone else who goes through them. The idea that you don't need to understand space/time complexity in day to day coding is ridiculous.

the problem isn't the algorithms but the whiteboard.

in my last interview I couldn't remember which of the various top/parent/offset variables defined the distance from the top of the document to the top of the viewport. It's a trivial thing that you can just google so I just used a placeholder. One interviewer was fine with it and another wasn't.

coding on a whiteboard from nothing but memory under time constraint has nothing to do with actual coding and amounts to a hazing ritual imo.

When I'm asked these questions I either provide a solution in Haskell or Erlang to highlight how dumb of a dick waving contest they are and/or I cite the PhD research that went into the thing they're now taking for granted as being "obvious".

I once asked an interviewer who claimed to be a distributed systems engineer to write out the fast paxos protocol or sketch out the operations and structure of a DVVset. They had no idea what I was talking about. Should they have been fired on the spot?

I can "code", and I still reject the premise and supposed utility of these dumb assessment methods on the grounds that I know they're dumb, I know they don't work, and I know this because I bothered to dig into the research on the subject of proficiency assessment.

Also, knowing space-time complexity isn't even remotely useful by itself. It's much more valuable to also understand average and worst case complexity, and how they impact a given use case, but when I ask the interviewers about this, they almost never know the answers, and they clearly don't think they're unfit for their own job, so which one of us is right?

It's our greatest collective failure as an industry that we hire people for a job based on testing their skills on a completely unrelated task. A task that they'll never actually carry out in any job anywhere.

I was thinking, the problem that your new hire can't code, is the least of your worries.

Reply on news.ycombinator.com