A Recursive Approach to Problem Solving

When solving a problem, you always want to break it down into a smaller subset of related problems. That said, it’s often difficult to know where to begin, and also in some situations, ONE SOLUTION might solve many problems. There seems to be a disconnect in identifying which “sub problems” to solve and whether or not those are the correct ones to solve . The idea that I explore in the post below is that you know your first input and your final output.

[INPUT, ...unknownNumberOfSteps, FINAL_OUTPUT]

The idea is that while you may have no idea what the intermediary steps are, you can identify what is the last step you need to get the output. In other words… something like this…

[INPUT, ...unknownNumberOfSteps..., [NEW_PROBABLE_INPUT, FINAL_OUTPUT]]

What would then follow is treating the “NEW_PROBABLE_INPUT” as the new output to aim for… going on the assumption that if you can get to the “PROBABLE_INPUT” then you will have made it to the final output.

Like so…

[INPUT, ...unknownNumberOfSteps..., [NEW_PROBABLE_INPUT, FOCUS_ON_THIS_OUTPUT], FINAL_OUTPUT]

And so on…

[INPUT, ...unknownNumberOfSteps..., [NEW_PROBABLE_INPUT, FOCUS_ON_THIS_OUTPUT], FOCUS_ON_THIS_OUTPUT, FINAL_OUTPUT]

Until you get to something like this:

[[INPUT, FOCUS_ON_THIS_OUTPUT], FOCUS_ON_THIS_OUTPUT, FOCUS_ON_THIS_OUTPUT, FOCUS_ON_THIS_OUTPUT, FOCUS_ON_THIS_OUTPUT, FOCUS_ON_THIS_OUTPUT, FOCUS_ON_THIS_OUTPUT, FOCUS_ON_THIS_OUTPUT, FOCUS_ON_THIS_OUTPUT, FOCUS_ON_THIS_OUTPUT, FOCUS_ON_THIS_OUTPUT, FOCUS_ON_THIS_OUTPUT, FINAL_OUTPUT]

In short: the idea is to narrow your focus to a concrete problem. However, my assumption is that it is a benefit to the problem solver to use the above approach first as pseudocode, or as a way of articulating the problem. After doing several tests of this myself, I’ve found that I can become distracted if I go straight to the code, and end up tackling a suboptimal solution that is not actually a direct path to the original input.

---

EXTENDED (or… “in other words” regarding the above approach):
NOTE 1: the following questions are designed to help you iterate to better solution faster. Being able to make use of the following questions depends on 2 things: 1) familiarity with built-ins, loops, “recursive iteration”, and 2) a repertoire of “built-in combos” for modifying data; built-in combos being syntactical patterns that are handy in a variety of situations. The thinking behind the approach that follows is: language familiarity is low hanging fruit. You might not get the best solution, but being able to translate ideas into code should make it possible to whip up an approximation of anything: binary tree, linked list, graph… anything.

A diagram is included at the bottom, as well as a sample walkthrough.

—The Steps—

STEP ZERO: When beginning this approach for a coding interview. You will have sample input and expected output. Once you’ve clarified what the expected/desired output should be, you can then begin.

STEP ONE: Can I get the desired output in “single attempt”?
a) If YES … ask yourself whether or not you could use a built-in, a loop, or something recursive… which would be the best? Once you identify the approach you attend to take, consider three variations. For example: if you were planning to use a built-in, and you thought “sort” would be the way to go, take a moment to think what map or reduce might look like. The reason to consider several solutions at once is: you will be able to more immediately refactor towards a final solution, ruling out dead-ends immediately, or discovering problems you had not considered.
b) If NO… ask “Why not?” (because a little digging might turn that “no” into a “yes”). If the NO turns into a YES, revisit Step 1. If the NO remains a NO, go to Step 2.

STEP TWO: Given that I cannot get the desired output in a single attempt, what is a possible input that would allow me achieve the final desired output from step zero/step one in a single attempt?

STEP THREE: Confirm that you’re correct. If you can “iterate on” the dummy/intermediary input to get the final result, then treat your dummy/intermediary input as the new desired output and repeat the previous steps. Continue repeating the steps, until you no longer need to have a dummy/intermediary value, but are confronting the initial input.

To summarize: If you’ve worked backwards, choosing “dummy/intermediary” inputs to replace the original input, and then treating each of those inputs as an output to work towards, you should reach a solution that you can refactor.

IN A DIAGRAM: (see below).