What teaching 100+ students taught me about explaining code

By

Between 2021 and 2023 I spent a lot of my evenings teaching. At Growing Stars I taught more than 100 students across the United States, in over 250 hours of live sessions on Python, JavaScript, and data structures and algorithms. After that I spent a year as a MERN stack mentor at GeeksforGeeks, helping students and working professionals with problem solving, coding and system design. I still run mock interviews and publish the material I use for them.

Teaching changed how I explain things, and it changed how I write code. These are the lessons that stuck.

Start with an example, then name the idea

The instinct is to define a concept and then show an example of it. It almost always works better the other way round. Show a function that calls itself to walk a folder tree, let people follow it, and only then say the word “recursion”. The name lands on something they already understand instead of floating in the air waiting for an example to attach to.

Ask for a prediction before the answer

When someone asks why their code doesn’t work, the fastest route is rarely to tell them. Ask them what they expect it to print, and then run it. The gap between the prediction and the output is exactly where their mental model is wrong, and finding it themselves sticks far better than any explanation I could give.

Let people get stuck, but not for long

Struggling with a problem is how the learning happens, and solving it for someone takes that away. But being stuck for too long just turns into frustration. What worked for me was a ladder of hints: first a question that points in the right direction, then a smaller version of the problem, then the key insight, and only at the very end the solution.

Hand-drawn staircase of hints. From "stuck" at the bottom, each step gives a little more: first a question that points the right way, then a smaller version of the problem, then the key insight, and only at the top the solution. A note says to stop climbing as soon as they are unstuck.
A ladder of hints: give the smallest one that gets them moving again.

Draw the state

A lot of confusion comes from state people can’t see. For recursion, a table with one row per call and a column per variable makes the call stack visible. For pointers and references, boxes and arrows. For system design, the path of one request through every component, drawn before discussing how to scale anything. Once the state is on the page, most questions answer themselves.

Hand-drawn sketch of a recursive factorial function next to a table with one row per call and a column per variable. fact(3) has n equal to 3 and waits for fact(2), which waits for fact(1), which returns 1. The returns flow back up: fact(2) returns 2 and fact(3) returns 6.
Draw the state: one row per call, one column per variable, and the call stack stops being invisible.

Get to something that works early

Motivation is a resource, and nothing replenishes it like seeing your own program work. The best sessions got students to a running result quickly, even a crude one, and improved it from there. That’s also how I approach new projects now: an ugly end-to-end version first, then refinement.

Make feedback specific

In mock interviews, “you did well” and “work on your communication” help nobody. A scorecard with concrete criteria, such as clarifying the requirements, explaining the approach before coding, testing with an edge case and discussing complexity, makes feedback something a person can act on. It also makes me more consistent: two candidates who do the same thing get the same feedback. The mock interview kit on my GitHub grew out of exactly that.

How it changed my engineering

Teaching taught me that if I can’t explain something simply, I probably don’t understand it well enough yet. That shows up in my work every day:

  • Code reviews. I try to explain the why behind a suggestion, and ask questions rather than issue verdicts, the same way I would with a student.
  • Naming. A name is a tiny explanation. If a function is hard to name, it usually does too much.
  • Design documents. I write them for someone joining the team next year, not for the people in the room today. That forces me to state assumptions I would otherwise leave implicit.
  • Debugging. “What did you expect, and what happened instead?” is as useful a question for a production incident as it is for a beginner’s homework.

Why I keep doing it

Every time I explain something, I find a gap in my own understanding. Students ask the questions experienced engineers have stopped asking, and answering them properly keeps me honest. That’s the real reason I’ve kept teaching alongside engineering, and why the low-level design and interview material I use is open on GitHub for anyone who wants it.