I won't argue that being able to apply different patterns to problems is incredibly useful, but a lot of these are also fairly domain-specific. It really depend

I won't argue that being able to apply different patterns to problems is incredibly useful, but a lot of these are also fairly domain-specific. It really depends on what your typical work is like. I've worked on teams that dealt with messaging queues and associated backend systems. In those cases it was rare, if ever needed at all, to see or use any kind of graph searching algorithms. Sometimes some forms of memoization were helpful when it came to system issues that required a meaningful but efficient backfilling strategy. But they were almost never in the same form that typical DP interview problems are. I would argue many of these patterns can be helpful to test candidates with but only depending on what roles they're interviewing for. I've seen more "trivial" problems that test for the same kinds of answers that interviewers usually want anyway. Usually the messaging is something like "we want to test that you can write code. We want to test that you can iterate over and consume/aggregate some data. We want to test that you can evaluate this codes performance." You can do all those things with simpler classes of problems than some of the brain teasers I've seen. And I don't mean the usual stuff like how many tennis balls fit in a school bus, but leetcode style, overly complex problems.