Teaching "Step-by-Step Instructions" to Architect mode (ages 15–18)

Hook & Warm-Up

Open with the lesson's hook as written, delivered as a real claim rather than a gimmick: "Algorithms are the invisible architecture of the digital world. Google processes 8.5 billion searches daily, each triggering thousands of algorithmic operations in milliseconds. Let's examine algorithmic thinking — from basic control flow to computational complexity theory."

Ask the class to estimate: "If you wanted to search through a million unsorted names to find one, and you could only check one name at a time, how many checks might that take in the worst case?" Take a few guesses, then flag that you'll come back to this exact question once complexity notation is on the table.

Note for context: this lesson sits at the "foundations" end of the AI course, on purpose. Algorithms are the substrate everything else in AI is built on — a machine learning model is, underneath, still executing an algorithm (just one whose parameters were shaped by training data rather than written by hand). Today is about the substrate, not the learning part.

For students weighing a computer science, data science, or software engineering path, it's worth naming directly: nearly every technical interview at a software company, and most introductory university CS coursework, opens with exactly this material — defining problems precisely and reasoning about the efficiency of a solution. Today isn't a detour from "real" computer science; it's the first page of it.

Main Activity

This age band can handle real computer science vocabulary. Move through it briskly rather than padding it — Architect-mode students respond better to being trusted with the real material than to a slowed-down version.

Complexity: Big-O notation

Introduce Big-O as a way of describing how an algorithm's running time (or memory use) grows as input size grows, independent of any specific computer's speed:

• O(1) — constant time. Looking up a value by its exact array index.
• O(n) — linear time. Checking every item in an unsorted list once, in the worst case, to find a target.
• O(n log n) — the complexity class of efficient comparison-based sorting algorithms, such as merge sort.
• O(n²) — quadratic time. Comparing every item to every other item, such as a naive duplicate-detection loop.

Return to the opening estimate: searching a million unsorted names one at a time is O(n) — up to a million checks in the worst case. If the names were sorted first, binary search would bring that down to roughly O(log n), about 20 checks. That gap is the entire practical reason complexity analysis matters at scale.

Be precise about what Big-O actually describes, since this is a common source of confusion even in introductory university courses: it characterizes the worst-case growth rate as input size increases, not a literal count of operations or a guarantee about any specific run. Two O(n) algorithms can still run at very different real-world speeds — Big-O tells you how each one's runtime scales as n grows, not which one is faster in absolute terms on today's hardware.

Algorithmic paradigms

Introduce three named approaches, each with one concrete example:

• Divide-and-conquer — solve a problem by splitting it into smaller instances of the same problem, solving those, then combining results. Merge sort splits a list in half repeatedly, sorts the halves, and merges them — giving O(n log n) overall.
• Dynamic programming — applicable when a problem has overlapping subproblems (the same smaller calculation gets needed more than once) and optimal substructure (the best overall solution is built from the best solutions to its subproblems). Naive recursive Fibonacci recomputes the same values repeatedly; storing (memoizing) results turns an exponential computation into a linear one.
• Greedy algorithms — make the locally optimal choice at each step without reconsidering earlier decisions, in cases where local optimization happens to lead to a globally optimal (or acceptably good) result. Dijkstra's algorithm for shortest paths is a classic example: at each step, it commits to the nearest unvisited node reachable so far.

Flag the important caveat about greedy approaches directly, since it's a common exam trip-up: the greedy strategy doesn't work for every problem — it depends on the problem actually having the property that local optimal choices compose into a global optimum. Dijkstra's algorithm has a further real constraint worth naming precisely: it correctly finds shortest paths only when edge weights are non-negative. A graph with negative edge weights needs a different algorithm (Bellman-Ford), because Dijkstra's greedy commitment to the "nearest" node can be wrong once a negative edge could make a longer-looking path actually shorter.

Real systems, stacked

Make the point that any single app a student uses is composed of many algorithms working together, not one: a maps app layers search indexing, a shortest-path algorithm (Dijkstra's or the heuristic-guided A* over a road-network graph), and real-time traffic weighting; a search engine layers an inverted index for fast lookup with relevance ranking (historically PageRank's link-structure analysis, now one signal among many); a social feed layers a candidate-generation step with a ranking model trained to predict engagement, sometimes using collaborative filtering (recommending based on what similar users engaged with) blended with deep learning models trained directly on engagement data.

A* is worth a brief separate mention since it directly extends Dijkstra's algorithm: it adds a heuristic — an estimate of remaining distance to the goal, such as straight-line distance on a map — to guide the search toward the destination faster, rather than exploring outward equally in every direction the way plain Dijkstra's does. It's the more common choice in practice for point-to-point routing (one start, one specific destination) precisely because that heuristic lets it skip exploring large parts of the graph that Dijkstra's would still check.

Emphasize the throughline back to the lesson's core idea: however sophisticated the system, every layer is still, underneath, executing finite, ordered, unambiguous instructions. What machine learning changes is who wrote the instructions — a human for a hand-coded sort, versus a training process that derived a model's parameters from data. The instructions still execute exactly as specified either way.

This is also the moment to be honest about a limitation of today's material: algorithmic complexity theory has real depth this lesson only touches — NP-completeness, the P vs. NP question, approximation algorithms for problems that don't have known efficient exact solutions. None of that is required to understand today's core ideas, and it's fine to say so plainly if a student asks; naming the boundary of what's covered is more useful than implying today's lesson is the whole subject.

Applied exercise

Have students trace, by hand, how merge sort would sort a 6-number list, and separately how Dijkstra's algorithm would find the shortest path across a small 5-node graph you sketch on the board with edge weights. This is enough to make "divide-and-conquer" and "greedy" concrete rather than abstract before the quiz.

Discussion

• "Why does an algorithm's Big-O complexity matter more at Google's scale (billions of searches) than it would for a to-do list app with twenty items?"
• "Greedy algorithms don't always produce the globally best answer — can you think of a decision-making situation (in life, not code) where the 'locally best choice at each step' approach could backfire?"
• "If a recommendation algorithm's training data reflects existing biases, what happens to its output — and whose responsibility is that?"
• "The lesson calls algorithmic literacy 'increasingly civic literacy.' What's an example of an algorithm shaping what information reaches large numbers of people?"
• "If you're weighing a computer science, data science, or software engineering path, which part of today's lesson connects most to what that career would actually involve day to day?"
• "Dijkstra's algorithm assumes edge weights are never negative. Can you think of a real-world 'distance' or 'cost' that could reasonably be negative, where that assumption would break down?"
• "If you had to defend, to a skeptical adult, the claim that 'algorithmic literacy is civic literacy,' what's your strongest one-sentence argument?"

Quiz Walkthrough

Wrap-Up & Extension

Close with: "Every system you interact with online is a stack of algorithms — some simple and fixed, some shaped by machine learning trained on data, all of them still, underneath, executing precise and finite instructions. Understanding that stack is foundational whether or not you ever write code professionally, because these systems increasingly shape what information reaches you and everyone around you."

Extension activity (25–30 minutes): Have students pick one algorithm mentioned today (PageRank, Dijkstra's/A*, collaborative filtering, or a sorting algorithm) and write a one-page technical explainer aimed at a non-technical adult — parents, a school board, a local official — covering what problem it solves, roughly how it works, and one real consequence of that system's design choices (for search: what "relevance" leaves out; for feed ranking: what "engagement-optimized" can incentivize). This doubles as a portfolio piece for students building out an AI-literacy or computer-science portfolio.

If you have extra time, or for students specifically considering a CS or software engineering path: Have them implement one of today's algorithms (merge sort or a basic Dijkstra's over a small hand-entered graph) in whatever programming language they're most comfortable with, or in pseudocode if they haven't started coding yet. Actually tracing the recursion of merge sort, or the priority-queue behavior of Dijkstra's, on a computer rather than on paper tends to make the complexity discussion from earlier in the lesson concrete in a way that talking about it alone doesn't.