[narribbi]

Balancing a binary tree is just an algorithm, like there are so many. As a programmer, you have to design algorithms on the fly, quite a few of which may actually be harder than just balancing a binary tree. Algorithms emerge automatically from designing data structures; when you end up manipulating these data structures. In turn, data structures emerge naturally from trying to model particular problems. There are too many branches in mathematics modeling too many types of problems than anybody could know them all.

In that sense, asking a developer about how to balance a binary tree, is a dumb interview question.

He should only know, if he happened to have worked on exactly that type of problem, only yesterday or so.

The question is rather: If the following is the description of the algorithm to balance binary trees, show that you understand it by dealing with the details in the following examples.

[meheleventyone]

I like your post and just wanted to add on top of this that some algorithms including those sometimes asked in interview questions take/took months or years of effort to come up with. You chase down blind alleys and have insights along the way that come from being deeply immersed in a problem. Which is why interview candidates change these "tests of problem solving skill" into tests of knowledge by cramming.

[kkielhofner]

Often times the right answer is (and should be) "show me you can find and use a use license-compatible library that typically has orders of magnitude more testing in the real world than something you feel the need to re-implement from scratch right now".

The dirty secret is 90% of what happens in the real world (and on HN) is a solved problem that needs to be applied or re-applied. Someone has done it before and they've done it better than you will.

[sirclueless]

There's a difference between "I know how to do this but it would be a buggy mess and require a week or two of effort, therefore I shall use a library," and "I don't know how to do this but this library seems roughly applicable so maybe it will work."

The former is a healthy and pragmatic use of your most valuable resource -- time. The latter is a cop-out. If no one actually understands what is going on at a deep level in the library, the result is likely to be an over-engineered mess. It might be that you're doing the most efficacious and appropriate thing for the task, but it might not. And with many such decisions made over the course of a project, some of them are bound to be wrong unless someone can reason about them and explain their purpose.

I find this is most important when refactoring or updating code. Some junior engineer down the line will encounter some code he doesn't understand, and track down the guy who wrote it, and at this point there is a world of difference between that guy saying, "Yeah, we needed a data structure that does X and Y so we used that library," and "Uhhh, not sure why we used that library, does anything break if you remove it?"

[detaro]

Followed by "show me you can debug and fix said library when we find it it's slightly broken for our use case"