Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

How often, in your day job, is it a necessary job-related task for you to be pop-quizzed on the Big-O characteristics of half a dozen data structures and then have to draw out manipulations of a binary tree on a whiteboard?

Somehow we decided to never test for the things we actually do at work, and instead to invent an entirely new discipline (whiteboard interviewing) and test for competence at that, in hopes it would translate to doing well on the job.

Thus far the empirical evidence is not particularly great that testing for the skill of whiteboard interviewing translates to success on the job, and there's a growing body of evidence that it excludes the most desirable people (since experienced high-quality candidates are likely to have been out of school, or whatever they used to learn "fundamentals", for long enough that the things tested in a whiteboard interview are not close enough to the top of their minds to consistently pass).



I mean, I think the whiteboard thing is pretty lame, and would prefer to give and get coding tests on my own machine and environment.

But yeah, I expect someone to be able to tell me what the complexity of various algorithms when shown them is and how to manipulate common data structures. At the very least one ought to be able to walk a tree don't you think? My front end engineer has to walk a tree of JSON on a project right now. I'm glad she can do it.


And yet... this attitude is how we get stuff like the Homebrew guy tweeting that Google is happy to be internally dependent on his software while also saying he's not qualified to write software for Google, because their tech interview excludes him.

(Google's interview process, in my experience, can be gamed heavily by just memorizing a dynamic-programming solution to the longest-common-subsequence problem; they love popping that one out in interviews, even for job descriptions which have no reasonable need to ever be able to regurgitate it onto a whiteboard on command)


> can be gamed heavily by just memorizing a dynamic-programming solution to the longest-common-subsequence problem;

Funny, I actually implemented this about a month ago but I can't remember how it works now.


As far as I remember, the guy comes from the team that didn't understand what the heck are digital signatures for in package management. They refused to acknowledge the problem that they hosted everything through raw HTTP with no signatures whatsoever. This may be a hint that he indeed was not qualified.

Not to mention that people constantly complain about how Homebrew works with its dependency resolution, compared to how people rarely complain about Yum/DNF or APT.


So what, we just let everyone who says they can code in? That's how fizzbuzz was born.


Stating for the 1e100th time in discussions of this topic: whiteboard interviews do not test coding ability and do not usefully distinguish people who are able to code from people who are not. So any argument proceeding from the assumption that doing away with them equates to no longer testing for ability to code is invalid and contains a known-false assumption.


Yes I agree with this. I even stated as such, that I give and prefer to get coding tests using an actual computer. I'm not talking about those.

f I ask someone the complexity of searching a binary tree, or show them a double for loop with that iterates over the same collection in each loop, and ask them the complexity of that, I expect them to say logn and n^2. Bonus points for addressing best, average, and worst case performances and what kind of data drives those.

If I ask someone to write a small program at their own laptop to parse an integer, I expect them to be able to do that. This shows the absolute bare minimum in competency at the job you'll be asked to perform.


I can't say I ever get quizzed on it. But avoiding On*n solutions is something we have to do everyday.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: