Algorithms: Step-by-Step Methods for Solving Problems

The word algorithm is often used as if it means a mysterious system deciding which video or post appears next. Recommendation systems do use algorithms, but the idea is much broader and older.

An algorithm is a defined procedure that transforms inputs into desired outputs.

A cooking recipe, a method for finding a name in a sorted list, and a procedure for choosing the shortest route all have an algorithmic shape: start with information, follow steps, and produce a result.

Algorithm versus program

An algorithm is a method. A program is an implementation of one or more methods in a form a computer can execute.

The algorithm "repeatedly compare neighboring values and swap them when they are out of order" can be implemented in JavaScript, Python, Java, or even by a person rearranging numbered cards.

Code includes details that the abstract method may not specify:

• Data types
• Error handling
• File formats
• Memory layout
• User interaction
• Language syntax

Separating the method from its implementation helps developers discuss whether the approach itself is sound.

A concrete example: finding a contact

Imagine searching for "Mira" in a paper contact list.

If the list has no order, you may inspect names from the beginning until you find Mira. This is linear search. In the worst case, you inspect every entry.

If the list is alphabetically sorted, you can inspect the middle:

1. If the middle name is Mira, stop.
2. If Mira comes earlier alphabetically, discard the later half.
3. If Mira comes later, discard the earlier half.
4. Repeat with the remaining half.

This is binary search. Each comparison removes about half the remaining possibilities.

Both algorithms can be correct. One gains speed by requiring sorted input.

Correctness comes before speed

An algorithm is correct when it produces the required result for every input covered by its specification.

Testing several examples increases confidence, but examples alone do not prove correctness. Developers also reason about:

• Preconditions: What must be true before the algorithm starts?
• Invariant: What remains true after each step?
• Postcondition: What is guaranteed when it finishes?
• Termination: Why must the procedure eventually stop?

For binary search, a useful invariant is that if the target exists, it remains inside the current search range. Every update must preserve that truth.

Inputs and edge cases define the real problem

"Sort these values" sounds simple until details appear:

• Can values repeat?
• Can the list be empty?
• Are values numbers, dates, or human-language names?
• Must equal items keep their original order?
• Is all data in memory?
• Can the input contain invalid values?

An algorithm that works for ten clean integers may fail on a billion records stored across machines. The requirements and input constraints determine which solution is appropriate.

Measuring work as input grows

Algorithm analysis often focuses on how work changes as input size n grows.

Common growth patterns include:

• Constant, O(1): Work does not grow with input size.
• Logarithmic, O(log n): Each step removes a large fraction of the problem.
• Linear, O(n): Work grows roughly in proportion to the input.
• Linearithmic, O(n log n): Common in efficient comparison sorting.
• Quadratic, O(n²): Comparing many pairs of items.
• Exponential, O(2^n): The search space doubles with each added choice.

This notation describes growth, not an exact stopwatch time. An O(n) algorithm can be slower for small inputs than an O(n log n) algorithm with high setup costs. Growth matters increasingly as n becomes large.

Time and memory can trade places

An algorithm may run faster by storing additional information.

Suppose you need to check whether a list contains duplicates. Comparing every item with every other item uses little extra storage but can require quadratic time. Recording seen values in a set uses additional memory and can often finish in linear time.

There is rarely one universal "best" algorithm. The environment may prioritize:

• Low latency
• Low memory usage
• Battery life
• Network traffic
• Simplicity
• Accuracy
• Ease of verification

Engineering is the act of choosing among those constraints.

Data structures and algorithms work together

The organization of data changes which operations are efficient.

A hash table can make exact-key lookup fast. A balanced tree keeps items ordered and supports range queries. A queue naturally supports first-in, first-out processing. A graph represents networks of relationships.

Choosing an algorithm without considering its data structure is like choosing a route without knowing the available roads.

Exact answers are not always necessary

Some problems are too expensive to solve exactly at useful scale. Systems may use:

• Heuristics: Practical rules that often find good solutions
• Approximation algorithms: Methods with a known distance from the optimum
• Randomized algorithms: Procedures that use randomness as part of the strategy
• Sampling: Examining a representative subset

A navigation system may prefer a very good route found quickly over the mathematically perfect route found after the trip should have ended.

An approximate answer should still have a clear quality measure. "Close enough" must mean something testable.

Recommendation algorithms are pipelines

A social feed is not usually controlled by one line called "the algorithm." It is a pipeline of methods:

1. Gather candidate posts.
2. Remove ineligible or unsafe items.
3. Estimate likely relevance.
4. Apply freshness, diversity, and policy rules.
5. Rank the remaining candidates.
6. Measure user response and system quality.

The output depends on algorithms, data, objectives, and product rules. Changing the objective being optimized can change behavior even when much of the code remains the same.

Readable solutions still matter

The theoretically fastest method is not always the responsible choice.

For small inputs, a simple algorithm may be:

• Easier to verify
• Less likely to contain bugs
• Faster to maintain
• More predictable
• Entirely fast enough

Optimization should respond to measured needs. Complexity analysis tells developers where scaling risks may exist; profiling shows where the running program actually spends time.

How to think algorithmically

When solving a problem:

1. Define the input and required output.
2. State constraints and edge cases.
3. Write a simple correct method.
4. Explain why it terminates and stays correct.
5. Estimate time and memory growth.
6. Test representative and boundary cases.
7. Optimize only where the constraints require it.

This process turns a vague task into a procedure that can be examined.

Knowledge check

1. How is an algorithm different from its code implementation?
2. Why does binary search require ordered input?
3. What does O(n) describe?
4. Give an example of trading memory for speed.
5. Why might a simple slower-growing algorithm still be the better engineering choice for small data?

The one idea to remember

An algorithm is a defined method for turning inputs into outputs. Its quality depends on correctness first, then on how well its time, memory, accuracy, and complexity fit the real constraints.