Ideally, both hirer and hiree would obtain perfect insight during the interview, and an alignment of skills, personalities and potential could be determined and made obvious to both parties.
We cannot obtain such insight, and yet hiring decisions are still made every day. Some work out, some don't.
As in most things, companies must optimize toward some strategy that produces results consistent with their priorities. If each of your programmers must be able to define - not just implement, but actually recall - breadth first, depth first, big-o notation, and others, I suppose your strategy will have to include such questions. What better way to determine whether your candidate can memorize definitions than to ask them for them?
But some parts of the common technical interview exist simply because the interviewers themselves aren't aware of any better strategy to obtain the insight that really matters. Is your culture easy-going? Do you need a certain kind of creative influence on your team? Is it really true that your programmers need to program algorithms at all?
My point is really quite simple: to alleviate the feeling that we're passing over good people, we should alter the interview process to give the candidate ample opportunities to show us they're a good fit (and that we're a good fit for them. For the record, I never accept offers from companies that ask me lexical structure or algorithm questions, especially if those questions are posed by peer-level interviewers - it suggests a non-performing competitive rather than cooperative atmosphere). We should identify, if we can, the priorities of our team, and then attempt to find a strategy that is optimized for presenting the candidates we're seeking in a favorable light.
(I'm leaving this comment because you've written a post that is less about improving the recall or application of algorithms, and more about helping a candidate show you they're capable.)