openskills.info
Course catalog
Open Course

Algorithms Fundamentals

Algorithms are step-by-step procedures for solving computational problems. This topic covers how to analyze their efficiency, understand common strategies like sorting, searching, divide-and-conquer, and dynamic programming, and choose the right approach for a given problem based on time and space constraints.

itComputer fundamentals

Don't Panic — Algorithms Fundamentals

You will almost certainly never write a sorting algorithm. That is not a reason to skip the subject; it is the reason the subject looks the way it does.

The paying skill here is recognition rather than implementation. Sorting routines get written by the people who maintain standard libraries and by almost nobody else; the everyday work is noticing that a problem is an old problem in unfamiliar words — this scheduling mess is a matching problem, this deduplication is a union-find, this "best combination of things" is a knapsack and so has no fast exact answer.

An algorithm is a recipe precise enough for a machine to follow and finish: fixed steps that turn an input into the result somebody wanted. Note what the definition leaves out — the code. Sorting cards, routing a van and ranking search results all sit inside it.

What eventually gets typed in Python is one rendering of something that exists independently of Python — which is why pseudocode exists, so people can argue about the method without arguing about semicolons.

Two questions come before speed, and both get skipped. Will it be right on everything the specification allows through, and is it guaranteed to finish? A handful of passing tests answers neither. The tool for the first is a loop invariant: something true when a pass begins, still true when it ends, and strong enough at the exit to hand you the answer.

Cost is described as a growth shape rather than a duration — linear, linearithmic, quadratic. Big-O notation is the shorthand for those shapes, and it says how the work grows as the input grows, not how many seconds anything takes.

Underneath sits a pattern worth carrying: binary search beats scanning a list item by item only because it demands more of its input, namely that the list already be sorted. Buying speed with structure recurs across the whole field and is never free, because something upstream must maintain the structure.

Nearly everything you meet is one of a few strategies. Brute force: correct, slow, a respectable baseline. Divide and conquer: split, recurse, combine. Greedy: take the best local choice, then prove that rule actually solves the problem, because for many problems it does not.

Dynamic programming: solve each repeated subproblem once and reuse the answer. Backtracking: choose, discover the choice was wrong, return to that decision, choose otherwise. Recursion is not on the list — it is the mechanism several of them run on.

Here is the part that catches people out. The asymptotics are often the wrong guide at the sizes real programs handle. Constants and memory locality dominate below a few thousand elements, which is why no serious library ships a textbook sort: CPython's Timsort handles any array under 64 elements with a plain insertion sort, on the stated reasoning that it is hard to beat once you count the overhead of trying something cleverer.

Two operational notes. Quadratic behaviour enters real code in one shape — a loop over a collection whose length somebody else decides, containing a lookup nobody measured — so hunt the nesting and ask who controls the outer length.

And where input is attacker-controlled, typical-case speed becomes an attack surface, because the worst case is now something an adversary can simply request.

The paradigms sit side by side in the Slides, the fastest way to see how few of them there are, and the growth shapes are tabulated on the Cheatsheet. Field Notes covers how this surfaces in code already running.

Where this skill leads

Relevant careers

See how this topic contributes to broader role-level skill maps.

Sources