4 Simple Steps To Solve Any Code Algorithm

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:”

4 Simple Steps To Solve Any Code Algorithm

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 enjoy the cake without the algorithm.

The same is true in computer science. Which 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 protocol 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:


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?

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.”

In solving for LeetCode #26, he 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, 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 first.

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

4 Simple Steps To Solve Any Code Algorithm

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 Leet Code 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, storytell, and prepare. But no matter what, iterate, iterate, iterate! That’s the key to becoming a master code algorithm solver. And maybe, a Jobsity developer, as well.


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. 

Jun 02, 2021
Mauricio Lopez
Mauricio Lopez

Mauricio has been at the forefront of technology for 12 years. He is constantly integrating new technologies including frameworks, CMS, and standard industry models. He is a pragmatic problem-solver and customizes solutions based on the best schema/language/application for each project. As head of technology at Jobsity, he ensures that his team is always up to date with the latest advances in software development by researching the software ecosystem, implementing several professional development initiatives, and coordinating with new and existing clients about their needs.
He holds a BA in Business and Marketing from UTEG Ecuador

Subscribe for the updates


Better hires, more work, less stress. Join the Jobsity Community. Contact Us