The hard part is realizing that the problem you're solving efficiently maps to a dynamic programming algorithm. You have to spot the opportunity for sub-problem reuse, or else the solution looks something like cubic or exponential (etc.)
> You have to spot the opportunity for sub-problem reuse
Which sounds exactly like what developers do in non boring parts of our job. If anything, the problem is that tests are being tightly timed, while time budget for real world task of this kind is usually more generous. On the other hand business time that company spends with inefficient solution or without one costs a lot of money so I can't blame companies for wanting employee who at least on toy problems can do that quick.
> You have to spot the opportunity for sub-problem reuse
Which sounds exactly like what developers do in non boring parts of our job. If anything, the problem is that tests are being tightly timed, while time budget for real world task of this kind is usually more generous. On the other hand business time that company spends with inefficient solution or without one costs a lot of money so I can't blame companies for wanting employee who at least on toy problems can do that quick.