Live Instruction · JavaScript · Closures · Masterschool
JavaScript Closures —
One-on-One Practice Session
A one-on-one Masterschool session working through six JavaScript closure practice problems live — from the simplest possible closure to a complex cache function with password gating, with a live debugging moment and a discussion of real-world applications like game save states.
The Session
Six problems. One student. Full depth.
Post-catchup week sessions sometimes run light on attendance. This one was just Francisco. Rather than a compressed group session, that meant a full one-on-one working through six closure practice problems from the Udacity curriculum — at whatever pace made sense, with space to stop, debug, and go deeper on anything that wasn't landing.
The problems were sequenced to build on each other: a function that returns "Hello World," a function that returns a function with an argument, a counter using IIFE to demonstrate separate instances, a closure over an addByX value, the complex saveOutput problem with a cache object and password gating, and finally deDup — which hit a live debugging moment that turned into a useful teaching opportunity.
The session closed with a look at real-world applications — game save states, callback queues — and a preview of OOP JavaScript coming up in the curriculum. The one-on-one format let the session go exactly as deep as the student needed on each problem.
6
closure practice problems
Masterschool Coding Bootcamp
JavaScript · Closures · One-on-One Tutoring
International cohort · Post-catchup week
The Content
What the session covered
Six closure problems built live — from a single return statement to stateful caches, first-class functions, and duplicate detection.
createFunction
Started with the simplest possible closure: a function that creates and returns another function that returns "Hello World." Built it from scratch, called it, logged the result. A minimal working example before adding any complexity.
createFunctionWithInput
Extended the first problem to capture an outer argument — the returned function closes over the input and returns it when called. Made lexical scope visible: the inner function retained access to the outer variable after the outer function returned.
Counter with IIFE
Built a counter using an IIFE to demonstrate that each invocation creates its own independent closure. Created Will's counter and Jazz's counter as separate instances — incrementing one had no effect on the other, showing scope preservation in action.
addByX
A closure that closes over an X value and returns a function that adds X to any argument passed in. Two layers of input — one captured at creation, one passed at call time. Used to reinforce how closures hold onto outer scope across multiple calls.
saveOutput
The most complex problem in the set: a closure that wraps any function, stores its results in a cache object, and gates repeated calls behind a password. Demonstrated passing first-class functions as arguments and using an object to persist results across calls.
deDup — Live Debugging
Built a deDup function that removes duplicates from an array using an object as a tracker. Hit a live debugging moment when the output wasn't matching expectations — walked through the logic step by step until the issue was found and fixed.
Separate Closure Instances
The counter example made a key concept concrete: calling the outer function twice produces two independent closures, each with its own internal state. Will's counter and Jazz's counter don't share anything — the closure owns its scope.
First-Class Functions as Arguments
The saveOutput problem required passing a function as an argument to another function — reinforcing first-class functions in a stateful context. The outer function stored the passed-in function and called it when needed.
Real-World Applications
Closed with a discussion of where closures show up outside of practice problems: game save states that persist data between sessions, callback queues in async code, and encapsulated modules. Connected the abstract concept to things Francisco had already encountered.
The Approach
1:1 format with progressive problem difficulty
One-on-one sessions allow for a different pacing than group open gym. With a single student, it's possible to slow down on any problem that isn't clicking and move quickly through what's already solid — something that a group format can't do without losing half the room. This session ran at Francisco's pace throughout.
The problem sequence was chosen deliberately. Each problem introduced one new idea on top of what came before: first a return, then an argument, then multiple instances, then two input layers, then a cache object, then a debug. None of the jumps were large enough to lose the thread, but each one extended the mental model further.
The live debugging moment in deDup was unplanned but useful. When code doesn't produce the expected output, walking through the logic line by line — asking what should happen here, what's actually happening, where the two diverge — is a more durable learning experience than just showing the working solution. Francisco found the issue by tracing through it.
The session closed with real-world framing because abstract problems land better when they have concrete analogues. Closures as game save states, closures as callback holders — those connections give students somewhere to put the concept before they need it on the job.
Simplest Case First
createFunction · one return · verify it works
Add Outer Scope
createFunctionWithInput · capture an argument
Separate Instances
Counter · IIFE · Will vs Jazz · independent state
Two Input Layers
addByX · outer capture · inner argument
Complex State
saveOutput · cache + password + first-class functions
Debug Live
deDup · object tracker · find and fix the issue
Session Recording
Watch the Session
One-on-one closure practice working through six problems live, including a debugging moment on deDup.
Reflection
Debugging is part of the lesson
The deDup debugging moment is worth noting specifically because it's what happens in real development — code runs, produces the wrong result, and you have to figure out why. Modeling the debugging process out loud, in front of a student, is different from showing a working solution. It demonstrates that confusion is a normal part of coding, not a signal that something is wrong.
The saveOutput problem is the most instructionally dense in the set. It requires three things at once: a closure over a cache object, a first-class function passed as an argument, and password-gating logic. Walking through each piece in isolation before assembling them made it tractable — and Francisco had enough context from the earlier problems to follow each step.
1
student · full depth
createFunction · createFunctionWithInput · Counter
addByX · saveOutput · deDup
Live debug · real-world applications · OOP preview
Keep Exploring
Related Case Studies
Interested in working together?
I'm open to remote opportunities in technical learning experience design, developer education, and customer enablement.