I hear what you're saying, I do. But if the candidate knows what an optimal solution is, and that optimal solution takes several hours, maybe you're asking a q

I hear what you're saying, I do. But if the candidate knows what an optimal solution is, and that optimal solution takes several hours, maybe you're asking a question that is too big? For example, asking someone to write a self balancing binary search tree in an interview might be too much. And asking a question that ultimately demands using a self balancing BST might be a bit much. It's like asking a question that really needs an associative array, but then imposing the rule that associative arrays aren't available. How about simply asking the candidate about binary trees, if they've used them, and what they've used them for? Last week an interviewer asked me about if I was familiar with the Egg Dropping problem (https://brilliant.org/wiki/egg-dropping/ https://brilliant.org/wiki/egg-dropping/). I wasn't, but I remember saying something like, "I haven't done this one before, but I'm pretty sure it's going to take O(log n) guesses to find the max floor from which you can safely drop the egg." The interviewer asked me how I'd implement it, and then we got into the weeds when I started asking for what the requirements were. He wouldn't share any information about inputs & outputs, so I just started writing the dumbest thing possible, predictably coded myself into a corner, and burned a potential interview win-win on learning how answer that kind of question for that kind of interviewer.