Honestly I'd suggest that the company in question takes a little bit of time to construct a toy project of medium size that's relevant to their application doma

Honestly I'd suggest that the company in question takes a little bit of time to construct a toy project of medium size that's relevant to their application domain and asks the candidate how they would solve it. This gets the candidate to talk about their problem-solving process in broad strokes, like, for example, they could ask a few questions of the interviewer, say things like "I'd break X feature into these 5 pieces, each of which are discrete functions, and I'd have to look up an algorithm to do Y for piece 3, etc." As many people here have pointed out, what you're looking for isn't knowledge of any particular algorithm, but an idea that they know how to take a problem and get it from a business objective to an operational definition of a software product. If they can do that, the implementation part can be (and often is) literally all copy-pasting stack overflow posts, and that's fine for the intents and purposes for the business. Furthermore, a process like that should, if the company already has competent engineers (And if they don't, how do they think they're going to successfully assess further additions to their team with any certainty?), allow said engineers to assess the new candidate's ability to get up to speed on their problem domain and meaningfully contribute, without relying on indirect proxies of knowledge.