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