(While this is a general discussion, I have "doing well on interview questions" as an instrumental goal; the discussion below is somewhat skewed due to that).
I noticed one of the common failures to solving problems (especially under time constraints) is trying to solve the problem prematurely. There are multiple causes for this; awareness of some of them might reduce the chance of falling into failure mode, others (at least one) I do not have a solution to, and a procedural solution might not exist other than the magic of experience.
Here is my list of the first kind (awareness-helps group):
- Jumping into the problem before completely understanding it: this could be due to perceived time pressure (e.g. test, interview). This *could* be rational, depending on the "test score" function, but could be a serious failure mode if done due to stress.
- Using a cached solution instead of trying to solve the problem. The statement of the problem can trigger "cached thoughts" despite (possibly intentionally, in interview) being more subtly more difficult than a well known problem. In one instance I actually misread the statement of the problem because it sounded like one I knew of before.
- Another problem with a cached solution, even if it is the correct one for the problem at hand, is that you might believe that you know it without actually doing the "retrieve from disk"; consequences might be looking bad when asked follow-up questions on an interview or inability to build on the problem if it's a part of a greater structure.
- Besides cognitive mechanics, there might be a desire to blurt out a cached solution because it makes you look knowledgeable. A status claim might be instrumentally useful ("this looks like a min-spanning tree algorithm!"), as long as you properly calibrate your level of confidence and don't fall for the trap.
This brings me to the last failure mode which I do not have a solution for (which is why I am posting ;). If I avoid the traps above, I should have a pretty good understanding of the problem. I think this is a kind of crucial point, as I by definition, do not know what to do next. This uncertainty is scary and might push me into trying to immediately solve it, very similar to 1 above. While you might be able to avoid acting on this by being emotionally reflective (which has the instrumental side effect of appearing more confident) I still do not know what exactly should be done next. Giving some time for unconscious processing seems necessary even on a smallish (interview-question-size) problems, but how much time? And what should I be doing in this time? Meditation? Drawing the problem? Trying to solve sub-problems? Writing down lists of whatever-comes-to-mind? I can use the time constraint-expected size of communicating the solution (in proper format, e.g. C++ code) as an upper bound; but there is a moment when I have to sigh (optional) and take a shot at solution. I do not have anything better to go by than gut feel here.
(Even after the plunge, there is a chance of getting stuck, which is where Meta-thinking skills come in)
Personally I use a completely different strategy when faced with a problem that can't be adequately understood just by studying it for a short time: I go ahead and attempt solutions, and use their shortcomings as a way of arriving at a better understanding of the problem.
Obvious caveats:
This doesn't work with a problem where you can't know that an attempted solution doesn't work until it's too late.
You have to be able to throw away solution drafts, not just theoretically willing if presented with ironclad proof of their inadequacy, but as a matter of routine practice.
And in fact, prototyping solutions to programming problems is an extremely good way to explore the problem well enough to have a better understanding of what is actually required, and what the best way to tackle it is.