Algorithmic Problem Solving

From Problem to Plan

Writing code isn't the hard part of programming. The real challenge is translating a vague problem into a precise, logical plan that a computer can execute. This process is called algorithmic thinking, and it's a skill you use long before you type a single line of code.

The first step is always problem decomposition. You break a large, complex challenge into smaller, manageable sub-problems. Think of it like planning a cross-country road trip. You don't just get in the car and drive. You first figure out the major stops, then the daily driving legs, then where you'll get gas and food each day. You solve the big problem by solving a series of smaller ones.

In programming, we formalize this plan using —a simplified, human-readable outline of an algorithm. It's not tied to any specific programming language's syntax. Instead, it focuses purely on the logic. Let's say our problem is: "Given a list of numbers, find the largest one."

Instead of immediately writing a for loop in Python or Java, we'd first draft our plan.

FUNCTION find_largest(numbers_list)
  IF numbers_list is empty, return null

  SET largest_so_far = first number in list

  FOR EACH number in numbers_list:
    IF number > largest_so_far:
      SET largest_so_far = number

  RETURN largest_so_far

This plan is clear, logical, and can now be easily translated into any language. It forces you to think through the edge cases, like an empty list, and define your steps clearly before committing to actual code.

Is Your Plan Efficient?

Just because an algorithm works doesn't mean it's a good algorithm. A plan to walk from New York to Los Angeles will get you there, but a plan involving a flight is much better. In computing, we measure this efficiency in terms of time and space.

Time Complexity: How does the runtime of an algorithm change as the input size grows?
Space Complexity: How does the amount of memory an algorithm needs change as the input size grows?

To talk about this, we use , which describes the upper bound or worst-case scenario for an algorithm's growth rate.

Imagine our find_largest algorithm. If we double the number of items in the list, we double the work we have to do. The effort scales linearly with the input size. We call this $O(n)$ , where $n$ is the number of items in the list. If we had an algorithm that compared every number to every other number, its work would grow much faster—quadratically. We'd call that $O(n^2)$ .

An $O(n^2)$ algorithm might be fine for 10 items, but it could become unusably slow for 10 million items. A good programmer aims for the most efficient algorithm possible.

Choosing the Right Tools

Your choice of data structure has a massive impact on your algorithm's efficiency. Let's tackle a new problem: "Given a list of a million transactions, find out if a specific transaction ID already exists."

A simple approach would be to iterate through the list from the beginning, one by one. This is an $O(n)$ solution. In the worst case, you have to check all one million items.

# O(n) approach using a list
def does_id_exist(transaction_list, target_id):
  for transaction_id in transaction_list:
    if transaction_id == target_id:
      return True
  return False

We can do much better. By first organizing our data into a (also known as a dictionary in Python) or a Set, we can make lookups incredibly fast. These structures use a special function to convert each item into an index, allowing them to find an item in what is effectively a single step.

This changes the lookup time complexity to $O(1)$ , or constant time, on average. No matter how many transactions we have, the time to find one stays the same.

# O(1) approach using a set
def does_id_exist_fast(transaction_list, target_id):
  transaction_set = set(transaction_list) # O(n) to build once
  return target_id in transaction_set      # O(1) for each lookup

While there's an initial cost to build the set, any subsequent lookups are dramatically faster. If you need to perform many checks, this is a huge optimization.

Loops or Leaps?

Two common ways to perform repetitive tasks are iteration and recursion. Iteration uses loops (for, while) to repeat a block of code. Recursion involves a function that calls itself, breaking the problem down into smaller versions of itself until it reaches a base case it can solve directly.

Let's calculate a factorial, like $5!$ , which is $5 \times 4 \times 3 \times 2 \times 1$ . An iterative solution would use a loop.

def factorial_iterative(n):
  result = 1
  for i in range(1, n + 1):
    result *= i
  return result

A recursive solution defines the problem in terms of itself: $n! = n \times (n-1)!$ . The function calls itself with a smaller number until it hits the base case, $0! = 1$ .

def factorial_recursive(n):
  if n == 0:
    return 1 # Base case
  else:
    return n * factorial_recursive(n - 1) # Recursive step

Recursion can make code for certain problems, like navigating tree structures, more elegant and easier to read. However, it often uses more memory because each function call adds a new layer to the and can be slower than its iterative equivalent. Choosing between them is a trade-off between clarity and performance.

Now that you have these tools—problem decomposition, efficiency analysis, and different implementation strategies—you can start tackling complex problems methodically. Let's see how well you can apply them.

Quiz Questions 1/6

What is the primary purpose of writing pseudocode before starting to code in a specific programming language?

Quiz Questions 2/6

You need to write a function that checks if a specific transaction ID exists within a list of one million unsorted transactions. What is the time complexity, using Big O notation, of the simplest possible approach, which involves checking each transaction one by one?

By breaking down problems, analyzing efficiency, and choosing the right data structures and logic patterns, you move from just writing code to engineering effective and scalable solutions.

Practical Programming Fundamentals