[muse900]

I believe the hate comes from unprecedented and hard CS questions asked on the whiteboard.

I recently went to an interview that asked me to balance a binary tree on a whiteboard. It can be done, and I can do it. Thing is when you go to interview for that company that has 2 developers(small team, small company) and ask you that kind of question it puts you off thinking that those guys won't be great to work with (arrogance etc comes in mind).

I am fond of simpler questions, like you said fizzbuz etc. Obviously if you are interviewing a guy that has 2+ years of experience, he has to be able to pass the fizzbuzz test. When you are interviewing someone with 5+ years of experience for a higher up position I guess you do have to ask some harder question, but I personally think just speaking to the guy and asking him stuff about his past projects etc will give you a hint on if he has the skills he is talking about or not. Asking him to outline a hard task he took part and how he solved it is an amazing start. As a 5+ years guy personally would rumble about a few things and it would take me days talking about them. (That will give you an understanding if I've worked before or not on the things outlined on my CV).

[driverdan]

I've been coding for about 25 years. The last time I had to write any code related to binary trees was in school, 15-16 years ago.

Given enough time and debugging I'm sure I could do it. I'm not going to be successful on a whiteboard though. If I actually had to do it I'd look it up instead of wasting my time figuring it out.

Unless you're interviewing for a position where they'll have to implement binary trees you shouldn't be wasting time asking about code for them. Questions should be relevant to the position.

[ryandrake]

Additionally: Nine times out of ten, you shouldn't be implementing the binary tree in the first place. There are already tons of tested, robust libraries out there that will do it a lot better than you can, handling all conceivable edge cases, available in a variety of license flavors. Many languages' standard libraries include support for binary trees.

You want candidates who can work through the buy-vs-build tradeoffs.

Reminds me of when I was asked to implement a filesystem API in C or C++ with file manipulation and path parsing and whatnot. The best answer I can think of is usually "With no weird constraints given (is this an embedded system, for example?) just use boost::filesystem and move on with your life." Not impressed with this answer, the interviewer would continue with "assume you can't use Boost!" Next answer is: "There are a variety of filesystem abstractions already written, far better than I could whiteboard. I'd go through each one and pick the one most suitable to the project." I thought it was a trick question at first. You really DO NOT want candidates who hear that question and launch into writing code!!

[woah]

It's obvious that they're not going to use the code you wrote at an interview in production. So "just use a library" is not a relevant answer. The question was probably posed to give you an interesting engineering challenge to work through with the interviewer so that they could see your problem solving process. Instead you just argued with the interviewer.

[ryandrake]

The GP's point (which I supported) is that it's a waste of time to take a candidate through scenarios that are not at least similar to what they'd actually encounter doing the actual job.

[stale2002]

But the point is that if you cant do something so simple, like traverse a tree, then you probably don't understand how trees work to begin with.

Similarly, I've never had to implement fizz buzz for real, actual, work. But I wouldn't trust a programmer who was incapable of doing fizz buzz without importing a fizz buzz library.

[sobani]

But the earlier comment wasn't talking about _traversing_ a tree, it was talking about _balancing_ it, which is a much harder problem and one I wouldn't want to do without google either.

[rtpg]

This can also be an education problem. There can be big mismatches in what is easy and hard

If you're coming from a more FP background things like flipping a binary tree are silly obvious. If you spend a lot of time with C++, of course you know how to write a linked list with memory management. Python devs are probably way better at slicing and dicing data

There's a certain expectation of what's easy and hard, but it's really easy to have a mismatch given the diversity of education out there.

[drdaeman]

It's also that coders tend to... err... "offload" memory for the stuff they aren't immediately using on a daily basis, and only remember the general terms and names that would be enough to find and remember the details shall they be required.

Last time I've had to do something with the trees implementation details (IIRC, that was AVL trees) was, like, 5 years ago. Right now, I don't exactly remember anything about AVL trees except for they have that nice O(log n) for lookups, insertions and deletions. Would I need to code them from scratch (or remember their internal workings for any other reason, like debugging some core dump), I'd go find the algorithm description (or particular implementation's source) and do so.

At the same time, last time I've worked with balanced trees was just a few days ago, but that was Erlang's `gb_trees` module that did all the stuff and I just had to freshen my memory on the syntax details.

All I would be able to do on a whiteboard is stare for a minute, trying to remember stuff, then probably say "uh, sorry, I don't remember this stuff - haven't did that in a long while". Yes, that makes me a worse programmer, I guess, but are interviewers actually looking for those who remember everything in their head and write code on whiteboard? Looks like a weird case to me that doesn't have to do anything with reality.

[vacri]

Last year our lead tech interviewed a guy that couldn't even conceptually get FizzBuzz...