There is no way you were asked to implement any of those in an interview.

For quad-trees and oct-trees--they are fairly common in gaming and not a particularly time consuming to implement.

For Red-Black and B-Trees, I've never heard of anyone being asked to implement the entire thing from scratch, but significant portions sure. Also explaining the implementation of significant portions.

Here's a similar post from 2015 by tptacek

>You're a 55-year old engineer who graduated from school in '81. You're being interviewed by a 24-year old engineer who graduated 2 years ago. You're asked, in an "algorithm interview", to explain some detail of the implementation of an AVL tree.

>In reality, despite the fact that they're covered in CS courses, virtually nobody uses AVL trees in industry. In fact, people barely use balanced binary trees at all, and when they do, they use red-black trees, and they use someone else's implementation, because they're a bear to debug.

>The 24-year old has an advantage with this question because they were recently taught about, and perhaps had to do exercises/homework/tests based on, AVL trees.

>That this happens is stupid, because it's very unlikely that conversance with AVL trees is going to make much of a difference to your on-the-job performance. Almost all the narratives you can come up with about this involve reading tea leaves and are shot down easily by better selection/hiring/interviewing techniques that answer questions more directly.

>This line of questioning can go too far; I don't, for instance, think knowing the big-O characteristics of an AVL tree is unreasonable (it's a balanced binary tree, and you should have the complexity of operations on those in resident set throughout your career).

Here's another coment from tptacek in the same thread. If you don't know who he is--you definitely want to hire him if you can. Him failing out of your hiring process would be a travesty.

>I was asked to do Bellman-Ford. I bombed that question, and was so shaken that I bombed the rest of the interview as well.

>The irony was, I'd just spent the preceding 2 years writing multicast link-state routing code. I could have coded a decent C++ Bellman-Ford in a couple hours, but couldn't pull it out of my head on the spot in an interview without babbling. (I tried to dodge by describing link-state LSP forwarding and then Djikstra, but wasn't given credit for knowing the more sophisticated algorithm).

>Algorithm interviews suck. We should stop doing them entirely.

Those are exceptions, if it was common to get these kinds of questions I would have gotten at least one like that at one of the many interviews I've been in. Getting rid of coding interviews won't stop some interviewers from being jerks. I much prefer being rejected for bombing a coding interview, than killing it and then getting rejected because of the behavioral interview, where someone 20 years younger than me acts like they can figure me out by asking me a bunch of silly questions.

First you deny the experience then when presented with evidence--the types of interviews people complain about are just rare.

>Getting rid of coding interviews won't stop some interviewers from being jerks. I much prefer being rejected for bombing a coding interview, than killing it and then getting rejected because of the behavioral interview

The same thing applies to your point. Coding interviews don't replace those issues they just add another hoop. What do you think behavioral questions, lunch interviews, and culture fit are?

>where someone 20 years younger than me acts like they can figure me out by asking me a bunch of silly questions.

Based on what I've observed this is what currently happens. 99% of companies have a terrible process for developing questions and evaluating responses.

And programming is pretty much the only field where it's the norm to be interviewed by someone much younger than you.