3 ms·

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

by teen 10y ago

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.

Jack000 10y ago
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.
im_down_w_otp 10y ago
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?

by teen 10y ago

Jack000 10y ago

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.

im_down_w_otp 10y ago

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?