First Hackathon Project

This is a submission for the MLH x DEV Writing Challenge

What I Built

I built Under the Hood, an interactive algorithm visualizer for common LeetCode problems, for people who can write the solution but don't yet understand why it works.

The idea came from my own experience. As a CS freshman, I've been told that grinding LeetCode 75 is a great way to get good at interview problems. It is, but it's easy to slip into a loop where you memorize "use a hash map" or "use two pointers," get the green checkmark, and move on without really knowing why it works. Why does binary search only need log N steps? Why is Two Sum fine with one pass? Why does a sliding window beat recomputing the sum? Most explanations online are a wall of text or a finished block of code, and neither shows what the variables are doing while the code runs.

So I built something that does. Pick a problem and you get:

• The idea in plain English, with time and space complexity
• The real Python code, with the currently executing line highlighted
• A live visualization: color-coded array cells (comparing, found, eliminated, in the window), labeled pointers like low, mid, and hi, and a hash-map view
• A "What's happening" explanation written for every step
• A variables panel that highlights what changed on the latest step
• Your own input, with validation and a Random button
• Playback controls: step with ← →, play/pause with Space, and 0.5x to 4x speed

It currently covers seven problems across seven patterns:

Problem	LeetCode #	Core idea shown
Binary Search	704	Discard half the array with each comparison
Two Sum	1	A hash map turns "find my partner" into a lookup
Two Pointers (sorted pair sum)	167	Too small? Drop the left. Too big? Drop the right.
Move Zeroes	283	A write pointer swaps non-zeros forward, in place
Maximum Average Subarray	643	Sliding window with an O(1) update
Buy & Sell Stock	121	Track the cheapest price so far
Climbing Stairs	70	A DP table, compared against naive recursion call counts

The part I'm proudest of: the step recorder

Every algorithm is a self-contained module that runs the real algorithm once and records a snapshot at each meaningful moment: the active code line, a plain-English explanation, the array state, pointers, highlight roles, hash-map contents, and variable values. The UI doesn't run any algorithm logic. It just plays the snapshots back, which makes stepping backward as easy as stepping forward.

My first version was built only for binary search. Refactoring it into one shared recorder format that could handle pointers, windows, hash maps, and DP tables was the hardest design decision of the project, and it paid off immediately. Each problem exports its code, default input, step generator, complexity, idea text, input fields, validator, and random-input generator. Adding a new problem is one new module file plus one line in a registry.

Challenges

• Designing one recording format flexible enough for very different algorithms
• Keeping the UI stable as input changes, like reserving space for error messages so the page doesn't jump, and dimming the visualization when the input is invalid
• Writing explanations short enough to read while the animation plays (harder than writing the code)

What I learned

I learned React, Vite, Tailwind, and Vercel, and this was my first time using all of them. The biggest lesson was working with AI as a teammate rather than a tool, which I cover below. I also learned that writing a good one-sentence explanation of an algorithm is harder than implementing it, and that building the visualizer made me understand each algorithm more deeply.

What's next

More patterns (linked lists, trees and graphs with BFS/DFS, heaps, backtracking, more DP), more languages in the code panel, a "predict the next step" quiz mode, shareable links to a problem plus input, and a GenAI integration that tests your understanding of an algorithm.

Demo

Live site: https://under-the-hood-blue.vercel.app/
Code: github.com/max-dean05/under-the-hood

To try it quickly, open Binary Search, press Space to play, then type your own sorted array and watch the low, mid, and hi pointers close in on the target.

Partner Technologies

I entered the Best use of SpaceXSI challenge, and I used Grok Bot and Cursor in two ways.

• Grok Bot for smoke testing. I used Grok Bot to smoke test the live site, which let me test it much more thoroughly than I could by clicking around myself. I could fix problems based on its feedback while it kept testing, which sped up my workflow a lot.
• Cursor for building modules. I used Cursor to analyze the patterns in my existing modules, so new ones could be written faster and stay consistent with the shared recorder format.

Together these felt like working with a teammate rather than using a tool, which was the biggest lesson of the weekend for me. I worked alongside Cursor to help develop the maximum average subarray problem, which ended up working very nicely. I connected my github repo so it could analyze my stylistic choices and code format, then write up a draft module. After I revised it and gave it the all-clear, it automatically pushed to github for me and all I had to do was merge the branches (no conflicts!).

Hackathon Experience

I attended HackTX 2026, and it was my first hackathon ever, so I didn't know what to expect. I worked solo for about 24 hours, wrote 1,500+ lines of code, and drank almost 500 mg of caffeine. If there's one thing that I could say I enjoyed about this hackathon, it would be the FOOD!

I left feeling much better about building under pressure, and I'm eager to do more hackathons.

If you've ever solved a problem without really knowing why it worked, give Under the Hood a try and tell me which algorithm you want to see next.