An algorithm is not some scary robot brain thing. It is just a recipe: a list of exact steps that always gets you the same answer. "Add two cups of flour" is a step in a recipe. "Look at the middle page of the phone book, then decide left or right" is a step in an algorithm. Computers run millions of these recipes a second, and picking the right recipe is the difference between an app that feels instant and one that hangs there spinning while you wait. This page walks through some of the most common basic recipes, in plain English, from the sliding window to a handful of others you've probably used without realizing it.
Strip away the buzzwords and an algorithm is just: a clear set of steps, done in order, that solves a problem every single time you follow them. A recipe for banana bread is an algorithm for humans. Long division, the thing you learned in third grade, is an algorithm too. Computers didn't invent the idea, they just got really, really good at running them fast, over and over, without getting bored or making a typo.
The reason programmers obsess over which algorithm to use is speed. The same problem can usually be solved a dumb, slow way and a clever, fast way. Both give the correct answer. Only one of them finishes before your lunch break ends.
Say you're looking for "Spicoli" in a phone book of a million names. Linear search is starting at page one and reading every single name until you find it. It works, but if "Spicoli" is near the back, that's a long afternoon.
Binary search is the trick you probably already do without thinking: flip to the middle of the book. Is "Spicoli" before or after this page, alphabetically? Throw away the half that doesn't matter, and repeat with the half that's left. Each flip cuts the problem in half, so a million names takes around 20 flips instead of up to a million reads.
Imagine you have a long paper receipt of daily coffee shop sales for the whole year, and someone asks: "what were the busiest 7 days in a row?" The dumb way is to pick every possible group of 7 days and add them all up from scratch, re-adding the same numbers over and over as you slide down the receipt. That's a ton of repeated work.
A sliding window is a smarter highlighter. You highlight the first 7 days and add them up once. Then, to check the next group of 7, you don't recount everything, you just slide the highlighter down by one day: subtract the day that fell off the back, add the new day at the front. Same answer, way less arithmetic, because you're reusing the work you already did instead of starting over.
That's the whole trick: keep a "window" of a certain size, and instead of recalculating it from nothing every time, just adjust it as the window slides forward one step at a time. It shows up any time you're scanning through a line of things, a receipt, a sentence, a row of sensor readings, and care about a chunk of consecutive items rather than the whole thing at once. "What's the highest 3-day average temperature this month?" and "what's the longest stretch of green lights on my commute?" are both sliding window problems in disguise.
Prep work now to make every question later basically free. A prefix sum is a running total you calculate once, up front, then reuse forever. Think of a checkbook register: instead of adding up every transaction from the beginning each time you want to know your balance, you keep a running total next to each entry, so checking the balance on any given day is just reading one number off the page.
It's the same "reuse previous work" spirit as the sliding window above, but instead of maintaining one window as you go, you build the whole running total ahead of time so that any range, not just a fixed-size one, can be answered almost instantly afterward.
A close cousin of the sliding window. Instead of one highlighter that slides, you use two fingers pointing at different spots in a list and move them toward or away from each other based on what you find.
Classic example: you have a sorted list of numbers and want to find two that add up to exactly 100. Put one finger at the very start (smallest number) and one at the very end (biggest number). If the two numbers add up to too much, move the right finger left (get a smaller number). If they add up to too little, move the left finger right (get a bigger number). Keep nudging until they meet in the middle, you'll find the pair, or run out of list, without ever checking every possible pairing.
A coat check at a fancy restaurant doesn't search through every coat on the rack to find yours, it hands you a numbered ticket, and that ticket points straight to your coat's hook. Hashing is that same trick for data: run a piece of information (a name, a word, a file) through a formula called a hash function, which spits out a "slot number." Store or look up that item in that exact slot, and you skip searching entirely.
This is what powers a hash table (also called a dictionary or a map in most programming languages): looking something up is basically instant, regardless of whether you're searching through 10 items or 10 million, unlike linear search (§2) which gets slower as the pile grows.
Putting a messy stack of things into order comes up constantly, alphabetizing names, ranking scores highest to lowest, and there are a lot of recipes for it.
Bubble sort is the simplest, and the slowest: walk down the list comparing each neighboring pair, swap them if they're out of order, and repeat the whole walk over and over until nothing needs swapping anymore. Big numbers slowly "bubble" up to the top like fizz in a soda. Easy to understand, but painfully slow on a long list.
Quicksort is cleverer: pick one item as a "pivot," shove everything smaller than it to one side and everything bigger to the other side, then repeat that same trick on each side separately. It's like sorting a deck of cards by first splitting into "low half" and "high half" piles, then sorting each pile the same way, instead of comparing every card to every other card.
Recursion is when a recipe calls itself on a smaller version of the same problem. Think of those Russian nesting dolls: to open the big doll, you open a slightly smaller doll inside, which means opening an even smaller doll inside that one, and so on, until you hit the tiny solid doll at the center that just... stops. That stopping point is called the base case, and every recursive recipe needs one, or it never finishes.
Divide and conquer is the strategy built on top of recursion: split a big problem into smaller copies of itself, solve each small copy (often by splitting it again), then combine the small answers into the big answer. Quicksort (§7) and binary search (§2) are both, quietly, divide and conquer under the hood.
Backtracking is trial and error with an undo button. You try a choice, keep going as if it works, and if you eventually hit a dead end, you undo your last few choices and try something different instead, rather than giving up entirely. It's recursion (above) with the added habit of cleaning up after a bad guess.
Think of filling in a Sudoku puzzle: you pencil in a number that seems to fit, move to the next empty square, and keep going. If you later find a square with no valid number left to put in it, you erase your last few pencil marks and try a different number back where you guessed wrong, instead of starting the whole puzzle over. Solving a maze by trying a path and backing up at dead ends (§10) is backtracking too.
Picture standing at the entrance of a maze, trying to find the exit. There are two classic strategies.
Depth-first search (DFS) is committing to one path and following it as far as it goes, hallway after hallway, until you hit a dead end, then backing up to the last fork and trying a different direction. It's how most people actually solve a maze on paper.
Breadth-first search (BFS) is more cautious: check every hallway that's one step away first, then every hallway that's two steps away, then three, spreading outward evenly in all directions like a ripple in a pond, instead of committing to a single path. BFS is what guarantees you find the shortest route out, since it never rushes ahead down one path before checking the closer ones.
Dynamic programming sounds intimidating, but the idea is just: don't solve the same sub-problem twice, write the answer down the first time, and look it up instead of recalculating it. It's the difference between a student who re-derives a math fact from scratch every time versus one who just memorized the times tables.
Classic example: calculating the Fibonacci sequence (1, 1, 2, 3, 5, 8, 13...) the naive way recalculates the same small numbers millions of times over as it goes. Dynamic programming just keeps a running notebook of answers it already figured out, so each number only ever gets calculated once.
A greedy algorithm always grabs whatever looks best right now, without worrying about whether it's the best move overall, and hopes that works out. Making change for a customer is a classic example: to make $0.67, you grab the biggest coin that still fits (a quarter, then a quarter, then a dime, then two pennies) rather than carefully planning every possible combination in advance.
When programmers say an algorithm "runs in Big O of something," they're describing roughly how much slower it gets as the list of stuff you feed it grows bigger. It's less about exact seconds and more like a speedometer for "how badly does this scale up."
| Notation | Plain English | Example |
|---|---|---|
| O(1) | Same speed no matter the size | Hash table lookup (§6) |
| O(log n) | Barely slows down as things grow | Binary search (§2) |
| O(n) | Slows down proportionally | Sliding window (§3), prefix sums (§4), linear search |
| O(n log n) | A bit worse than proportional | Quicksort (§7) |
| O(n²) | Gets bad fast on big lists | Bubble sort (§7) |
| Exponential | Explodes fast, only okay for small inputs | Naive backtracking (§9) |
You don't need the math to get the point: some recipes barely notice as the pile of stuff to process gets bigger, and some recipes fall over completely. That difference is the entire reason this page exists.
Understanding an algorithm is one thing. Whether the average developer actually enjoys using it is a whole separate vibe, and the internet has feelings about it. Here's the unscientific, definitely-not-peer-reviewed temperature check, gathered from the general energy of r/programming, r/cscareerquestions, and every "just got rejected after 5 rounds" post you've ever scrolled past.
| Algorithm | Dev sentiment |
|---|---|
| Binary search | Universally respected. Everyone swears they can write it clean, first try, no off-by-one bugs. Almost nobody actually can. |
| Sliding window | Interview-prep royalty. Beloved once it clicks, resented right up until that moment. Half the internet insists it's "just a pattern," the other half still forgets to shrink the window. |
| Prefix sums | The quiet MVP nobody hypes up. Shows up, saves the day, gets no thread written about it. |
| Two pointers | Fan favorite. Feels like a cheat code once you see it, so it gets recommended in every "how do I get better at coding interviews" thread. |
| Hashing | Basically a running joke: "just throw it in a hash map" is the duct tape of software engineering, and everyone knows it. |
| Sorting (bubble/quicksort) | Bubble sort is the community punching bag, taught once, mocked forever. Quicksort gets respect, though most devs admit they've never hand-written one outside a classroom, they just call .sort(). |
| Recursion | Deeply divisive. Half the internet calls it elegant and beautiful, the other half just wants to know why their stack overflowed at 2am. |
| Backtracking | Feared. This is the "oh no, it's a Sudoku problem" reaction in interview threads. Respected in theory, dreaded in practice. |
| BFS / DFS | Chill and well-liked. Low drama, does its job, shows up in "underrated algorithms" lists constantly. |
| Dynamic programming | The most complained-about topic in every coding interview subreddit, hands down. Widely considered the final boss of "please just let me get this job." |
| Greedy algorithms | Cute when it works, chaos when it doesn't. Devs like the simplicity right up until it gives the wrong answer with total confidence. |
| Big O | Everyone name-drops it in code review. Fewer people can actually calculate it correctly under pressure. It's the algorithmic equivalent of citing a stat you half-remember. |
| Situation | Typical choice |
|---|---|
| Find one item in a sorted list | Binary search |
| Best/total/average of a moving chunk of a list | Sliding window |
| Total of any range, over and over again | Prefix sums |
| Find a pair in a sorted list matching some target | Two pointers |
| Instant lookup by name/key, no searching | Hashing / lookup table |
| Put a messy list in order | Quicksort (or bubble sort, if it's tiny and you don't care) |
| A problem that's really a smaller copy of itself | Recursion / divide and conquer |
| Try options and undo bad guesses (puzzles, combinations) | Backtracking |
| Shortest path through a maze, map, or network | Breadth-first search |
| Same sub-problem keeps popping up repeatedly | Dynamic programming |
| Simple, fast, "good enough" answer | Greedy algorithm |