Hacker News new | ask | show | jobs
by ryandrake 3382 days ago
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!!

1 comments

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.
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.
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.

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.