I'll ask algorithmically interesting questions inspired by past problems I've solved within relevant domains. They're often solvable with some element of binary

I'll ask algorithmically interesting questions inspired by past problems I've solved within relevant domains. They're often solvable with some element of binary sorting. I don't care if someone uses a standard library or googles something, but I'll notice if they choose to use one and use it wrong. The classic example is assuming a dict in python is a tree rather than an unsorted hash map. Walking out of an interview like that is certainly a great way to not get hired. That's fine if you didn't want to work there anyway I guess, and nice for the interviewers because they learned enough to end the candidacy confidently knowing they dodged a bullet. Strong engineering teams solving worthwhile problems want to hire people that charge head first into difficult problems and get their hands dirty. If I were in a similar situation where I was asked to write an algorithm I was unfamiliar with, I would probably just say up front that I have no idea how to do that, and then start asking the interviewer questions about how it might work. I would also quickly try to identify a real world example of a problem they're hoping to solve with that algorithm, and then brainstorm alternative ways to solve that problem in ways I'm more familiar with.