Lesson 1 of 30
An algorithm is a set of steps for getting something done — like a recipe. By the end of this lesson, the word will stop sounding scary.
9 min read
Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.
This topic is about judgment and practical tradeoffs more than a single right answer — a mock interview is the better way to test yourself on it.
Be interviewed on this →Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.
Sign up freeWhat interviewers actually ask about this, and what a strong answer has to cover.
A strong answer covers
Likely follow-ups
If the word "algorithm" makes you a little uneasy, you're not alone. Most people hear it and picture a chalkboard full of equations. That picture is wrong, and it's the reason a lot of people feel behind before they've even started. This whole track exists to fix that picture, one small piece at a time.
Here's the real definition: an algorithm is a set of steps for getting something done, written down in order. That's it. A recipe is an algorithm. "Preheat the oven, mix the dry ingredients, add the wet ones, bake for 25 minutes" — four steps, done in order, that reliably get you a cake. You've been following algorithms your whole life without ever calling them that.
Directions are an algorithm too. "Turn left at the gas station, go two miles, turn right after the church" gets a stranger to your house every time, as long as they follow the steps in order. Nothing about that requires math. It requires being specific and being in order.
In programming, an algorithm is the same idea, just aimed at a computer instead of a person: a precise, ordered list of steps for solving one specific problem — finding the biggest number in a list, checking if a password is correct, putting names in alphabetical order. Code is one way of writing an algorithm down. It's not the only way, and it's not the hard part. The hard part — and the part this track will build up slowly — is figuring out the steps in the first place.
// The task: find the biggest number in a list.
// The "recipe," in plain English, before any code:
// 1. Guess that the first number is the biggest.
// 2. Look at each remaining number, one at a time.
// 3. If one is bigger than our current guess, update the guess.
// 4. When we've checked every number, our guess is the answer.
function findBiggest(numbers) {
let biggest = numbers[0]; // start with a guess: the first number
for (let i = 1; i < numbers.length; i++) {
if (numbers[i] > biggest) {
biggest = numbers[i]; // a bigger number showed up, update the guess
}
}
return biggest; // whatever survived all the comparisons
}
console.log(findBiggest([3, 7, 2, 9, 4])); // 9
Every line in that function maps to a step in the plain-English recipe above it. That mapping — plain words first, code second — is a habit worth keeping for the rest of this track.
Every lesson after this one is really asking one extra question about algorithms: not just "does it work?" but "how much work does it take, and does that change as the input grows?" That question is called Big O, and it's next.