4 Simple Steps To Solve Any Code Algorithm

If you’re involved in coding, development, mathematics, or computer science, you’ve certainly been faced with this daunting task before: how to solve an algorithm. Algorithms are the backbone of software development and the essential function of computer programs--they are, in essence, the directions that the developer gives to the computer which tells it what to do.

One good definition of what this looks like comes from MyCodingPlace.com: “In computer science, an algorithm gives the computer a specific set of instructions, which allows the computer to do everything, be it running a calculator or running a rocket.” Or as TechTerms puts it: “An algorithm is a set of instructions designed to perform a specific task.“

Writing an algorithm is writing directions. Even baking a cake can be written out as an algorithm--or a set of directions. Let’s borrow the MyCodingPlace example. Try to follow along at home:

1. Preheat the oven
2. Gather the ingredients
3. Measure out the ingredients
4. Mix together the ingredients to make the batter
5. Grease a pan
6. Pour the batter into the pan
7. Put the pan in the oven
8. Set a timer
9. When the timer goes off, take the pan out of the oven
10. Enjoy!

While the last step is clearly the most important, every step is necessary in order to ensure a computer (or very unclear person) knows what to do when tasked with baking a cake. You can’t solve the problem without the algorithm, and you can’t enjoy the cake without it either!

The same is true in computer science. This is why many developers are tasked with solving algorithmic problems as part of their applications when looking for software dev work (Jobsity does this to a very rigorous degree).

Because of that, there are a number of protocols and systems for thinking you can follow in order to break down and solve a code algorithm, and we’re going to explain some of them here.

Think Like A Mathematician

In 1945, famed mathematician and Stanford professor George Pólya wrote what many still consider to be the preeminent text on how to solve algorithms. He called it “How to Solve It,” and his method is still helpful when seeking to break down an algorithm into its component parts in order to solve it quickly, correctly, and efficiently.

For Pólya, the best method was the simplest one. He broke the process down into four steps, which are as follows:

1. First principle: Understand the problem.
2. Second principle: Devise a plan.
3. Third principle: Carry out the plan.
4. Fourth principle: Review/extend.

Understand the problem

Let’s be honest: if you don’t know what you’re solving for...you might get lucky and solve it. But chances are you won’t. This step may seem to be the most basic, but it’s also perhaps the most important.

Jared Neilson has a tip for how to navigate this stage when solving code algorithms: “If you're a good developer, you'll realize that the best solutions emerge from listening to your customer tell their story [and] many algorithms are disguised as story problems.”

In his explanation, he lays out an algorithm along the lines of a reframed story in order to understand better the acceptance criteria:

GIVEN < APPLICATION >
WHEN < I DO THIS >
THEN < I EXPECT THE APP TO DO THAT >

source: https://jarednielsen.com/algorithms/

So if “the farmer who needs to get duck, corn, and fox across the river” but he “can only carry one of these at a time,” and “if left alone, the duck will eat the corn and the fox will eat the duck,” how can we understand the problem with this simple story protocol? First, he recommends reading the problem. Then you have to make sense of it.

GIVE three items that will eat each other
WHEN I ferry one item across the river
THEN the other two are safe

source: https://jarednielsen.com/algorithms/

It might seem crazy, but the story helps you understand what your problem is. Then you can focus on solving it -- or almost.

Devise a Plan

For Neilson, the “plan” stage is also called the pseudocode stage, which is the time when you take your story and make it into code. But if that’s not simple enough, we can look at Ezra Schwepker’s explanation of a pseudocode solution to fill in the blanks.

For Schwepher, writing pseudocode is another way of saying “write out a human-legible description of what our approach will be.” He goes on to describe this pseudocode as providing “a meaningful roadmap that you can refer back to if you find yourself lost deep in the particulars of implementation.”

Pseudocode helps take you away from the “set of rules” approach of looking at pure numbers and to remember that coding is a human’s way of talking to a computer.

In solving for LeetCode #26, Schwepher writes his pseudocode this way:

// removeDuplicates :: (Array) -> number
// if array is empty or has 1 element, return array length and exit
// iterate through array
//     compare each element to the next element
//
//     repeat until false:
//        if the next element is the same as the current element
//        remove the next element
//
//     move on to the next element in the array
//     stop once the second to last element has been reached
// return array length

source: https://dev.to/moresaltmorelemon/algorithm-problem-solving-strategies-21cp

While pseudocode isn’t exactly a plan with a finite number of steps, it is a roadmap, and this roadmap can become your plan going forward.

Carry out the Plan

This is the step where you look at your understanding (story) and your plan (pseudocode) and you begin to build it into actual code.

This part of the process isn’t going to be linear, it’s going to be iterative. In order to “carry out the plan” successfully, you’re going to have to play around, dig deep, make mistakes, and work around them. Eventually, you’ll find the solution, but not without getting your hands dirty with a few edge cases first.

Here’s an example of how James Dorr solved for LeetCode 130:

And here’s his iterative and complicated thinking behind this solution:

“I...put in comparisons at the beginning of the ‘if’ statements because I knew JavaScript would throw an error or give the wrong information if the indices were negative or higher than the length of the arrays. But how would the indices be past safe ranges if this function was only run on Os that were in the interior, not on the border?

The intent was to eventually iterate over an array and add all of the O neighbors to that array, thus moving across the ‘board’, finding the group of Os that the original interior O belonged to. Then, if any of the Os were on the exterior, that original O could stay. However, this got confusing and ugly quickly, so there must be a better way.”

For Dorr, when the solution gets too confusing, he recommends you return to step three and work again in your planning and pseudocode stage, until you’ve sketched out a new approach, and then you can head back into the code and start chipping away at it again.

Learn Through Doing

The final stage is to get to work! Visit LeetCode on your own, or find another code algorithm to explore, run through the above steps and see if you can manage to solve it. If you can’t, explore what resources are online to help, and then dig back in. Plan, story tell, and prepare. But no matter what, iterate, iterate, iterate! That’s the key to becoming a master code algorithm solver. And maybe you’ll be doing your own mobile development as a Jobsity developer before too long as well!

--

If you want to stay up to date with all the new content we publish on our blog, share your email and hit the subscribe button.

Also, feel free to browse through the other sections of the blog where you can find many other amazing articles on: Programming, IT, Outsourcing, and even Management.

Interested in hiring talented Latin American nearshore developers to add capacity to your team? Contact Jobsity: the nearshore staff augmentation choice for U.S. companies.