This may be good advice for programmers that learned in an academic setting, but as someone that taught themselves this would drive me nuts. I still struggle with abstract problem solving in problems that I haven't solved before. A lot of algorithm based interviews I'll totally flunk the first time around. Depending on the interviewers behavior I've either bailed out from there or tried to learn something.
More helpful is backing up and framing the problem to be less abstract. When learning to code, we're learning new ways to represent things that we likely already intuitively know. In that way, you're teaching expression. The two are taught very differently, imo.
As someone who is also largely self taught in cs terms, it's actually very amazing to me how even very abstract ideas which seem to be very far away from a "solution" to a "problem" often fall into place very nicely.
For example consider a unification algorithm (e.g. https://reasoning.page/29021/unification-sort-of-in-rust which is an explanation of it that I wrote). The individual parts of it do not seem that spectacular, and also seem quite abstract. It is so simple (in my mind) that it could not possibly be correct. However, there is an emergent property when the interactions between the different parts of the program are taken together.
More helpful is backing up and framing the problem to be less abstract. When learning to code, we're learning new ways to represent things that we likely already intuitively know. In that way, you're teaching expression. The two are taught very differently, imo.