I don't think that's accurate - your example is closer to asking a programmer to take a typing test and hire them based on wpm. Both are hitting keys on a keyboard after all.

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.

I don't agree, of all the jobs I had, I've never had to do anything close to a typical coding puzzle. There are much more real-world scenarios you can test people on.

I think it depends on where you are located, the culture, how competitive the current market is, etc. In the early 2010's, it seems the US had a shift towards these sorts of "puzzle" interviews. Before that it was more laid back, maybe a take home test as part of the filter...

We might be arguing besides each other. The puzzles I'm arguing for are e.g. simplified toy versions of problems solved in the existing code base. That solves a real-world problem, so it fits your requirement.

That's not a puzzle, it's an exercise. A puzzle is what the OP describes:

> Testing whether I can find the longest palindrome subsequence of a string optimally via a tabular or memoized dynamic programming solution in 20