Not just "practically zero" - but like, "for sure zero". As in, there is absolutely zero chance you would need to solve a problems like this (or Sudoku, etc) in the course of actual engineering work.
It's a bullshit question, essentially.
You're better off giving someone a more realistic take home test and have them walk you through it during the interview. You'd get a better feel for what their "real" code looks like when they're under less pressure, how they communicate while presenting their solution, etc.
I'm assuming you were hired to write code, so I suspect your ability to write code in an interview is at least somewhat relevant.
I agree that, if you're hiring someone who will primarily be managing others or, maybe, architecting some systems, without doing the actual implementation (which, btw, I think is a suboptimal way of doing things), then you shouldn't test their coding. But if you're hiring someone to code, you need to check they understand how strings, memory, dynamic programming etc works.
> Testing whether I can find the longest palindrome subsequence of a string optimally via a tabular or memoized dynamic programming solution in 20
In contrast, at another interview I got given a take-home assignment that I almost didn't want to do because it felt like the kind of work I would do in my day job and I didn't want to do that in the evening or my time off. That task, on the other hand, probably measures infinitely better how effective I am on the job.