Table of Contents
Sorting Algorithms Unplugged Kids Can Run With Cards
Sorting algorithms unplugged kids can run with a deck of cards: tally every comparison, watch merge sort beat selection sort, and meet the real limit.
Ten cards, face down, and one rule: you may only ever look at two at a time, and every peek gets a tally mark. Sort them by one method and you will use exactly 45 comparisons, every time, no matter how lucky the shuffle. Sort them by another and you will use about 22. Scale up to a full deck and the gap becomes 1,326 against 249. These sorting algorithms unplugged kids can run on a kitchen table are the real thing, not a metaphor for the real thing, and the tally marks are the evidence.
Key Takeaways
- You’ll sort ten face-down cards three ways while counting every comparison, then repeat with twenty cards to see how the counts grow.
- The concept is algorithmic efficiency. Two methods that both finish the job can need wildly different amounts of work.
- Numbers to count: selection sort always needs exactly n(n−1)/2 comparisons, which is 45 for ten cards and 1,326 for a full deck. Merge sort needs about 25 and 249.
- Best for ages 8 to 14. Younger children can run the methods without the tallies.
- The usual trap is peeking. One glance at a card you were not comparing destroys the count, which is also why computers measure comparisons rather than seconds.
What You’ll Need for Sorting Algorithms Unplugged Kids Can Run
| Item | How much | Where to get it | If you don’t have it |
|---|---|---|---|
| Playing cards | One deck; you’ll use Ace to 10 of one suit first | Games cupboard | Index cards numbered 1 to 10, or Uno cards |
| Paper and pencil for tallies | 1 sheet per method | Stationery | Phone notes, though paper tallying is faster |
| A clear table | 1 | Kitchen | The floor works, with a flat surface |
| Sticky notes | 4 | Desk drawer | Scraps of paper to label piles |
| Timer | Optional | Phone | Not needed; comparisons matter more than seconds |
Time: prep 5 min, experiment 40 min, cleanup 2 min Cost: nothing, assuming you own a deck of cards Mess level: low, and no screens involved
Do the Experiment
Step 1 — Set the rule that makes it an algorithm
Take Ace through 10 of one suit, shuffle, and lay them face down in a row. The rule: you may turn over any two cards, compare them, and turn them back down, and every comparison gets one tally mark. You may move cards around freely. No remembering is allowed beyond the order you have physically arranged.
Step 2 — Run selection sort and count
Scan for the smallest card by comparing the current smallest against each remaining card in turn, then swap it to the front. Repeat for the rest. Count every comparison. Do the arithmetic afterwards: 9 comparisons on the first pass, 8 on the second, down to 1, which sums to 45.
Step 3 — Run insertion sort and count
Reshuffle. Pick up cards one at a time and slot each into its correct place among the ones already in your hand, comparing as you go from the right-hand end. Tally every comparison. This one varies with the shuffle, which is itself a result worth noticing.
Step 4 — Run merge sort and count
Reshuffle. Split into two piles of five. Sort each pile the same way, by splitting again, which means piles of three and two, then two and one. Then merge two sorted piles by repeatedly comparing only their top cards and taking the smaller. Count every comparison, including the ones inside the small piles.
Step 5 — Double the problem to twenty cards
Use Ace to 10 of two suits, treating suits as a tie-break. Run selection sort and merge sort again and count both. Selection sort should land on exactly 190. Merge sort should come in near 65 to 70.
Step 6 — Break the rules on purpose
Reshuffle the full 52-card deck. Deal into four suit piles, then deal each suit pile into rank order by placing each card in its rank position. Count the placements rather than comparisons. You will finish in 52 placements plus 52 pickups, having compared nothing at all.
What you should see: Selection sort hits exactly 45 on ten cards, every single time, which makes it a satisfying check on your counting. Insertion sort typically lands between 15 and 35 depending on the shuffle, occasionally as low as 9 if the cards arrive nearly sorted. Merge sort comes in at 22 to 25 and barely varies. At twenty cards the ordering becomes dramatic: 190 for selection against roughly 68 for merge. The final no-comparison method feels like cheating, and explaining why it is allowed is the best part of the activity.
What Sorting Algorithms Unplugged Kids Can Measure
| Method | 10 cards | 20 cards | 52 cards | How the work grows |
|---|---|---|---|---|
| Selection sort | exactly 45 | exactly 190 | exactly 1,326 | With the square of the number of cards |
| Insertion sort | 9–45, typically ~25 | 19–190 | varies widely | Square in the worst case, linear if nearly sorted |
| Merge sort | 22–25 | 65–69 | about 249 | Close to n times log n |
| Theoretical minimum | 22 | 62 | 226 | Any comparison sort at all |
| Deal into piles | 10 placements | 20 placements | 52 placements | Linear, but it is not comparing |
What’s Actually Going On in Sorting Algorithms
Selection sort’s count is fixed, and that is the first interesting thing. On the first pass it compares the leading candidate against nine others, then eight, then seven, and so on down to one. That sum is 45, and in general it is n times (n−1) divided by 2. Because it is a fixed formula, a lucky shuffle does not help it at all. Doubling the number of cards roughly quadruples the work, since the formula is dominated by n squared. This is what computer scientists mean when they call an algorithm quadratic.
Merge sort works differently because it never wastes a comparison on a pair whose relative order is already implied. Once the two halves are sorted, merging them only ever needs to compare the two cards on top of the piles, because everything below each top card is already known to be larger. That is the trick, and it is where the saving comes from. The number of comparisons follows roughly n times the logarithm of n, which grows far more gently. For 52 cards that is 249 against selection sort’s 1,326, a factor of more than five, and the gap keeps widening: a thousand items would take 499,500 comparisons one way and fewer than 10,000 the other.
Then comes the part that elevates this from a card game to real computer science. There is a hard floor on how few comparisons any method can possibly use, and you can derive it. Each comparison has two possible answers, so after k comparisons you can distinguish at most 2 to the power k different arrangements. A deck of 52 cards has 52 factorial possible orders. So you need 2 to the power k to be at least 52 factorial, which means k must be at least the base-2 logarithm of 52 factorial, and that works out to 226. No comparison-based sorting method, however clever, can ever sort a 52-card deck in fewer than 226 comparisons. Merge sort’s 249 is within 11% of a mathematical limit, which is why it is still in use. Those bounds are standard material in algorithms courses such as MIT’s 6.006.
Which makes the pile-dealing method in step 6 look like a paradox, and it is worth resolving carefully rather than hand-waving. Dealing into suit and rank piles never compares two cards. It reads each card’s value and puts it straight where it belongs, which is possible only because you know in advance that the values are exactly the integers one to thirteen and the four suits. That is extra information the comparison methods never had. The 226 limit applies only to methods that learn about the data by comparing items, and this is not one of them. Computer scientists call these counting or radix sorts, and they really do beat the bound, for exactly this reason.
The procedure here follows the long-standing CS Unplugged tradition. Its sorting algorithms activity uses balance scales and weights for the same purpose, and its sorting networks topic extends the idea to parallel sorting on a chalk diagram. Bell and Vahrenhold reviewed in 2018 how these activities are actually used and what evidence exists for them, and Caeli and Yadav traced the history of unplugged approaches to computational thinking in TechTrends. Both are worth a parent’s time, not least because they are honest about the limits of the evidence.
How to Explain It to Your Kid
Ages 5–8: find the smallest, over and over
Skip the tallying. Use six cards, face up, and have them find the smallest and put it first, then do it again with what’s left. That is selection sort, and doing it a few times makes the pattern of repetition obvious. The useful phrase to plant is “same thing again, with one less card”.
Ages 9–12: count, then compare the counts
This is the right age for the full activity. The moment that lands is reaching exactly 45 twice in a row with selection sort and then reaching 23 with merge sort, because the difference is no longer a feeling. Ask them to predict the 20-card counts before running them. Most children guess that doubling the cards doubles the work, and finding 190 instead of 90 is a genuinely valuable surprise.
Ages 13+: derive the lower bound
Walk through the counting argument: each comparison gives one bit, k comparisons distinguish at most 2 to the k arrangements, and ten cards have 10 factorial, which is 3,628,800 arrangements. The base-2 logarithm of that is about 21.8, so at least 22 comparisons are needed. Then look at their merge sort count, often 22 or 23, and the fact that they got within one or two of a proven mathematical limit with a deck of cards is a real result.
The question to ask: “If I handed you a deck that was already almost in order, which method would you use, and which one wouldn’t care at all?”
Why Teaching This Early Pays Off
Most children’s exposure to computing is to interfaces. This is an afternoon spent on the thing underneath, and specifically on the idea that two solutions to the same problem can differ by a factor of five on one deck of cards and a factor of fifty on a thousand items. That intuition is what makes a person later ask whether a slow program is slow because of the machine or because of the method.
It also puts a number on something children usually experience as vibes. “Faster” becomes “fewer comparisons”, which is measurable, independent of how quick your hands are, and comparable between two people in two different kitchens. The habit of finding the right thing to count is most of what data analysis is.
The research on unplugged activities is positive but modest, and worth representing accurately. Bell and Vahrenhold’s review found widespread use and generally encouraging but limited evidence, noting that these activities are best understood as one component of teaching rather than a replacement for it. The National Research Council’s framework lists using mathematics and computational thinking among its core practices, which is precisely what a tally chart of comparisons trains. One afternoon with cards will not teach algorithms, but it does mean that the words sorting and efficiency arrive already attached to something your child did with their hands. If you want more in this direction, there is coding without a computer and binary numbers with physical activities.
Before You Start: What Parents Should Know
| Best age | 8–14 for the counting version. 5–8 for selection sort with face-up cards and no tallies. The lower-bound derivation suits 13 and up |
| Supervision | Light. The adult’s real job is enforcing the no-peeking rule and keeping the tally honest |
| Real hazards | None beyond normal kitchen care. This is a card game with a pencil |
| Don’t | Don’t let a child reorder cards based on a glance rather than a counted comparison, because the whole measurement depends on that discipline. Don’t time it with a stopwatch instead of counting; hand speed is not the quantity of interest |
When It Doesn’t Work
- The counts come out different every time for selection sort. Something is being skipped or peeked at. Selection sort on ten cards is always exactly 45, so any other number means the method drifted. Walk one pass through slowly together.
- Merge sort collapses into confusion. The recursion is the hard part. Physically separate the piles on the table with sticky-note labels, and do the smallest merges first so the pattern is visible before the big ones.
- The child wants to sort by eye. Turn the cards face down. It is remarkable how much the face-down rule changes the activity, because it forces every piece of information to come from a counted comparison.
- Insertion sort beats merge sort. That is a legitimate result when the shuffle happened to be nearly sorted, and it is worth celebrating rather than correcting. It is exactly why real systems often use insertion sort for small or nearly-sorted inputs.
- The twenty-card run takes too long and interest fades. Split the work. One person sorts, one tallies, and swap at ten cards. Alternatively run selection sort on twenty and just compute merge sort’s prediction instead of performing it.
Take It Further: More Sorting Algorithms Unplugged Kids Can Try
- Build a sorting network on the driveway. Chalk six vertical lines and a sequence of rungs between them, then have six children walk down the lines swapping at each rung if they are out of order. Everyone moves at once, which is how parallel hardware sorts. The CS Unplugged sorting networks topic has tested layouts.
- Plot the growth. Run selection sort on 4, 6, 8 and 10 cards and plot comparisons against card count. The curve is unmistakably not a straight line, and fitting n(n−1)/2 through the points is a satisfying piece of real mathematics.
- Race a search instead of a sort. Once the deck is sorted, find a named card by halving the range repeatedly and count the steps. Seven halvings cover more than 100 cards, which is the subject of guess my number in seven tries and the reason sorting is worth the effort in the first place.
What to Watch For Over the Next 3 Months
- Week 4: Counting steps rather than timing them. Asking how many moves a puzzle takes instead of how long.
- Month 2: Noticing when something is already nearly in order and choosing a different method because of it. That is algorithm selection, and it is a genuinely advanced instinct.
- Month 3: Asking why an app or a game is slow in terms of what it must be doing rather than how old the device is. If that question appears unprompted, the idea has generalised well beyond cards.
Frequently Asked Questions
Why count comparisons instead of timing it?
Because time depends on how fast a particular pair of hands moves, so it cannot be compared between two people or two machines. Comparisons are a property of the method itself. Computer scientists count operations for the same reason, which lets them predict performance on a machine that does not exist yet.
Is merge sort always better than selection sort?
Not always, and that is worth knowing. For very small inputs, merge sort’s splitting and merging overhead costs more than it saves, which is why real sorting libraries switch to insertion sort below a threshold of around ten to thirty items. For anything large, merge sort wins decisively.
How can dealing into piles beat the mathematical minimum?
Because the 226-comparison floor applies only to methods that learn about the data by comparing items. Dealing into suit and rank piles uses outside knowledge, namely that the values are exactly one to thirteen in four suits, and places each card directly. Different information, different limit.
My child says this is boring without a screen. Any advice?
Make it a contest with a number attached: can they beat 25 comparisons on ten cards? The tally chart is the game. Face-down cards also help enormously, because the puzzle becomes genuinely hard rather than a chore, and the no-peeking rule gives it the feel of a challenge rather than a worksheet.
About the author
Ricky Flores is the founder of HiWave Makers and an electrical engineer with 15+ years of experience building consumer technology at Apple, Samsung, and Texas Instruments. He writes about how kids learn to build, think, and create in a tech-saturated world. Read more at hiwavemakers.com.
Sources
- CS Unplugged. Sorting Algorithms. University of Canterbury. https://classic.csunplugged.org/activities/sorting-algorithms/
- CS Unplugged. Sorting Networks. University of Canterbury. https://www.csunplugged.org/en/topics/sorting-networks/
- Demaine, E., & Ku, J. (2020). Introduction to Algorithms (6.006). MIT OpenCourseWare. https://ocw.mit.edu/courses/6-006-introduction-to-algorithms-spring-2020/
- Bell, T., & Vahrenhold, J. (2018). “CS Unplugged: How Is It Used, and Does It Work?” In Adventures Between Lower Bounds and Higher Altitudes, Lecture Notes in Computer Science, 497–521. https://doi.org/10.1007/978-3-319-98355-4_29
- Caeli, E. N., & Yadav, A. (2020). “Unplugged Approaches to Computational Thinking: a Historical Perspective.” TechTrends, 64, 29–36. https://doi.org/10.1007/s11528-019-00410-5
- National Research Council. (2012). A Framework for K-12 Science Education. National Academies Press. https://doi.org/10.17226/13165