Teaching "Step-by-Step Instructions" to Hacker mode (ages 11–14)

Hook & Warm-Up

Open with the lesson's hook, delivered straight — this age group responds better to being treated as capable of the real idea than to a cutesy setup: "Every app you use, every game you play, every search result you see is the product of algorithms. Let's learn what algorithms actually are, why specificity matters, and how they power everything from Google to TikTok."

Ask: "Raise your hand if you've ever wondered why your For You page shows you exactly the videos it does." Follow with: "That's an algorithm. So is a traffic light. So is your phone's autocomplete. By the end of today you'll be able to say precisely what makes something an algorithm — and precisely where 'algorithm' stops and 'AI' begins."

Frame the stakes honestly: understanding algorithms isn't just a CS topic — it's understanding the systems that already shape what information reaches them every day.

If the room is quiet at "For You page," push a little: "Some of you probably know your feed shows different things to different people. Today we're going one level deeper than 'it's an algorithm' — we're going to look at what actually has to be true for something to count as an algorithm at all, and where the line between a plain algorithm and something you'd call 'AI' really sits."

Main Activity

This age band gets a more formal definition than younger students, so start there before working through the lesson's scenes. Expect the whole activity, including both exercises below, to run 25–30 minutes.

Defining "algorithm" precisely

Write on the board: an algorithm is a finite, ordered set of unambiguous instructions for solving a problem. Break down the three parts with the class:

• Finite — it has to actually end. An algorithm that never terminates isn't useful (or, in computing terms, it's a bug — an infinite loop).
• Ordered — the sequence of steps matters, not just which steps are present.
• Unambiguous (definiteness) — each step has exactly one clear meaning; there's no room for the executor to interpret it differently.

Now connect it to the sandwich example from the lesson: "Put peanut butter on the bread" fails the unambiguous test, because it silently assumes "open the jar first" — a step a human fills in automatically and a computer does not. Have students identify which of the three properties (finite / ordered / unambiguous) is being violated in two or three of the app's own "what goes wrong" examples.

Push on the "finite" property with a concrete failure case, since it's the one students are least likely to have thought about: ask "what would 'sort this list' look like as an algorithm that never terminates?" A student-generated answer is usually something like a step that says "keep comparing pairs of numbers forever" with no stopping condition. This is a real, common category of bug — an infinite loop — and it's worth naming that a program that never finishes is often just as broken as one that gives a wrong answer, even though it never technically "fails."

Real algorithms, named

Work through the app's "Real Algorithms" scene with actual names and mechanisms attached, at a level appropriate for this age group — accurate but not exhaustive:

• Search (Google): Google's search algorithm evaluates billions of pages to return results in roughly half a second. Its original core technique, PageRank, ranks a page's importance largely by analyzing the structure of links pointing to it — a page linked to by many other important pages ranks higher. Modern search uses many additional signals beyond PageRank, but that link-analysis idea is the historical foundation worth naming.
• Game AI: Enemy characters typically follow conditional rule algorithms — "if the player is near, chase; if health is low, retreat" — which is a simple decision structure, not machine learning.
• Social feeds: Platforms like Instagram or TikTok rank posts using algorithms trained on your engagement history (what you've liked, watched, or lingered on) to predict what you're likely to engage with next. Worth flagging honestly: the exact ranking formulas are private company secrets, so what's taught here — and what's confirmed publicly — is the general mechanism (predicting engagement from past behavior), not the precise weighting any platform actually uses today.
• Traffic lights: A fixed-timer algorithm — green 30 seconds, yellow 5, red 30, repeat — with no data and no adaptation involved.

Use this moment to draw the algorithm/AI line explicitly: all four are algorithms. Only the search and feed-ranking systems typically qualify as AI, because their behavior comes from patterns learned from data rather than being fully hand-written in advance. Game AI in most titles is closer to the traffic light — a fixed, if more elaborate, rule set — despite the name "AI" in the field of game design.

Applied exercise

In pairs, have students write pseudocode (plain-English, numbered steps — no programming language required) for a simple algorithm: sorting five index cards with random numbers into ascending order, using only "compare two cards" and "swap two cards" as allowed operations. This previews time complexity without naming it yet — ask pairs to count how many compare/swap operations their approach took.

Once a few pairs have finished, poll the room for how many compare/swap operations each pair's method used on the same five cards. There's usually real variation — one pair might land on 10 operations, another on 6 — even though every pair solved the correct problem. Use that gap to introduce the idea, without heavy formalism, that "correct" and "efficient" are two separate questions: an algorithm can get the right answer every time and still be slower than another algorithm that also gets the right answer every time. That's the seed of time complexity, which the quiz names directly.

Discussion

• "What's the difference between a rule-based algorithm (traffic light, most game enemies) and one that's 'AI'?"
• "If a social feed algorithm is trained on your past behavior, whose 'fault' is it if it shows you something harmful — yours, for engaging with similar content before, or the algorithm's, for optimizing for engagement?"
• "Why does 'the steps have to be unambiguous' matter more for a computer than for a person?"
• "Can you think of an algorithm you rely on daily that you'd never have called an 'algorithm' before today?"
• "What would happen if Google's search algorithm ranked pages randomly instead of by relevance?"
• "Two algorithms both sort the same list correctly. Does it matter which one you use? When might it matter a lot, and when might it not matter at all?"
• "If a game's 'AI' is really just fixed if/then rules, why do you think it's still called AI in marketing?"

These land better as a genuine back-and-forth than as a quiz — several don't have a single correct answer, and that's intentional. The engagement-algorithm question in particular tends to produce a real split in the room, which is worth letting run for a minute or two before moving on.

Quiz Walkthrough

Wrap-Up & Extension

Close with: "Algorithms aren't a niche computer science topic — they're the reason your search results, your game, your feed, and even the traffic light on your walk home behave the way they do. Today you learned to name the difference between a fixed rule-based algorithm and one shaped by learned data, which is exactly the line between 'algorithm' and 'AI.'"

Extension activity (20–25 minutes): Have students research (or, without internet access, hypothesize from what they already know) one algorithm behind an app they use daily — a maps app's route-finding, a music app's "Discover" playlist, or a shopping app's "recommended for you" — and write a short explanation covering: (1) what problem it solves, (2) what data or rules it likely uses, and (3) whether they think it counts as AI or a simpler fixed algorithm, with a one-sentence justification. Have a few volunteers share out.

If you have extra time: Revisit the sorting exercise from the main activity and ask pairs to try a second, different method for the same five cards — if they started by scanning for the smallest remaining card each time, have them try instead always comparing and swapping neighboring pairs. Compare operation counts again. This sets up, without naming it, the distinction between algorithms that trade off differently as the amount of data grows — something Architect-mode students will name explicitly as Big-O notation.

A closing note worth saying out loud: the honest answer to "is this algorithm AI?" is sometimes genuinely unclear, even to people who build these systems, because a lot of real products blend fixed rules with learned models in the same feature. Encouraging students to sit with "I'm not sure, but here's my reasoning" is a more accurate outcome than pushing every example into a clean yes-or-no box.