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

"whiteboard hazing"

there are two types of whiteboarding questions. The kind that's a perfectly reasonable thing to ask (i've had people ask me to develop some simple system... which I think is reasonable, because i'll do that as part of the job)

but then there's the solve x algorithm questions. Which ultimately is an exercise in memorization. At this point I've just accepted that i'll have to do that.



The best argument for whiteboard algorithm questions is that they (to some degree) filter out people who think that whiteboard questions are "an exercise in memorization".

I mean, whether or not the company actually values the underlying non-memorization skill is another question (as someone who is very strong in that skill, I think that most companies/roles do not have a use for that, and should not test for that).

But the main argument against whiteboard coding applies equally to both kinds of questions. That argument is that it's a psychologically unrealistic environment, and that the main signal you get from such questions is whether or not the interviewee is psychologically comfortable under this particular artificial form of pressure. Does this generalize to other types of pressure? Does it generalize to the work environment at large?

I mean, me personally, I love whiteboard questions of either kind. Wheee. But I'm not convinced that the tech sector should use my hobby as the ultimate test of employability.

(PS: and for good engineers who are bad at whiteboarding in interviews, I'm available for coaching, heh)


I say this every so often and get blasted for it, but... if you don't want to whiteboard code in an interview, bring your development environment with you. It's at least worth a try.


> That argument is that it's a psychologically unrealistic environment

I feel the same way about algorithm puzzle type interviews.


That last part is a book or course Inwould buy


When you figure out how you can memorize your way through Google's interview process, please give me some advice. I study algorithms constantly out of interest, and still only managed to do well enough that they gave me another try a week later.

Do I think algorithm questions predict how well you do on a job? No. However I certainly don't think they are just memorization unless you mean memorizing run time of various data structure operations, but that's actually useful to know.


Careercup.com If you can ace Algorithms 101 exam, you can get hired. It is a measure of intelligence and ability to learn (and for older folks, free time to refresh) but it doesn't have much to do with job performance.


I don't understand what the fuss is all about... Just learn to invert binary trees, shouldn't be that hard...


Unfortunately I already use CareerCup.com and aced my algorithms final when I was in school. However, it's not like you can just memorize the stuff you see on CareerCup since it's unlikely you'll be asked a question you saw on there, unless it's a relatively easy/popular one.


> Do I think algorithm questions predict how well you do on a job?

Personally I prefer (as both interviewer and interviewee) a weekend project style format -- pick your IDE, language, have time flexibility, etc.


I think OP was perhaps referencing the human interaction that happens after you put something on a whiteboard with their "hazing" comment.

We've all been in that interview with the one jerk engineer who seems to want to hear themselves talk more than honestly walk through a problem. (Hint: it tends to be the person who offers "Well, that's not the way I would have done it" as a negative and without further explanation)


Honestly neither are great ways to interview someone. The first is better, sure, but it doesn't actually tell you if they're a good programmer.

The only thing I've found that does work is asking them about problems they've encountered/solved before, and then maybe have them write out something from them on the board. This gives pretty decent insight into their problem solving process.


>but then there's the solve x algorithm questions. Which ultimately is an exercise in memorization. At this point I've just accepted that i'll have to do that.

Pedantic (but hey this is HN), but I don't think algorithms are a question of memorization all the time. Sure, "implement quicksort" is a bit silly, but "rotate this binary tree" is eminently reasonable as a shibboleth to comfort with data structures

Agree about it not being super useful for a lot of interviews though.




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

Search: