When I was working at Ooyala I used to do the typical data-structure interviews (trees, graphs, etc), until one time an interviewee asked me: "Do you guys use all this in your day to day?" I felt ashamed to have to answer "not really", which I did.

After that, I started asking for answers to problems that I really had in the day to day. Some of them actually had real complexity (like doing binary search to overcome a buggy HTTP request items pagination library).

I think the main problem with data-structures and algorithms questions is that, the person that originally envisions a question, understands the "soul" of the question and how to vouch the candidate as she solves the question. However, when someone else takes that question to apply it, he only sees whether the answer is right or wrong, without looking at the resolution process.

>> I think the main problem with data-structures and algorithms questions is that, the person that originally envisions a question, understands the "soul" of the question and how to vouch the candidate as she solves the question. However, when someone else takes that question to apply it, he only sees whether the answer is right or wrong, without looking at the resolution process

In addition, I think that when someone asks a binary tree traversal problem to a candidate, the interviewer starts fretting over trivial edge cases, function signatures and coding style etc.

Whereas, if you would have asked a distilled version of that pagination problem, I would be so excited to have a chance to solve that problem and we could focus on my ability to solve that problem instead of my coding style on a whiteboard.