Five Corpses in the Garage: How I Resurrected Dead Code and Got Three Interviews Out of It

There's a folder on my machine called misc-attempts. It contains the archaeological record of two years of evenings: a parking-finder app that never made it past the map view, a webhook debugging tool with genuinely good logic buried under console.logs, a recipe scraper, a CLI for splitting group dinner bills, and something called final_final_v3 that I genuinely cannot explain.

None of them were finished. All of them taught me something. And until this spring, exactly zero of them were doing anything for me professionally.

So I ran an experiment on my own backlog. Pick five corpses. Spend two weeks maximum making each one presentable — not finished, presentable. Then put them where hiring managers could actually see them. Here's the lab report.

What "presentable" actually means (it's less than you think)

My first instinct was to refactor everything, add tests, ship it properly. That's a trap. "Presentable" for experimental code turned out to be three things:

1. A README that answers four questions in the first screen. What does it do? What's the stack? What's the demo link? What did you learn or what broke? That's it. Nobody reads past the fold on a GitHub repo, least of all a recruiter skimming between meetings.

2. A live demo or a 60-second screen recording. This was the single highest-leverage thing I did. A deployed demo on a free tier (Fly.io, Vercel, whatever) means a click instead of a git clone that will never happen. For the two projects that needed real infrastructure, I recorded a Loom-style walkthrough with my actual voice narrating the tradeoffs. Slightly embarrassing? Yes. Effective? Extremely.

3. A short write-up per project on the lab site. Not a blog post — a postmortem. What I built, what I'd do differently, one interesting technical decision. Two hundred words, tops. This is the part that did the heavy lifting in interviews, because it gave me something to talk about that wasn't a tutorial project.

Before and after: the parking app

Before: 1,400 lines of JavaScript, a commit history that ended mid-sentence, a README that said "parking app lol."

After: same code, zero refactoring. New README with a GIF of the map view, a one-paragraph explanation of why I used a spatial index instead of brute-force radius queries, a demo deployed to a free subdomain, and a write-up titled "Why my parking app died (and what the corpse taught me)."

Total time: about six hours. That's it. The code was never the problem. The packaging was.

What recruiters actually clicked

I put simple analytics on the portfolio page, mostly out of curiosity. The results surprised me:

• The webhook debugger got the most clicks by a wide margin. It's the least glamorous project, but it's the one that most obviously maps to real work. Turns out "I built a tool to make my own debugging faster" reads as seniority.
• The parking app demo video had the longest watch time. People want to see a thing working, even an ugly thing.
• The bill-splitting CLI got almost nothing. Lesson learned: projects that overlap with a thousand tutorials don't earn attention, no matter how clean the README is.

When interviewers did bring things up, it was never the code quality. It was the write-ups — the decisions, the dead ends, the honest accounting of what failed. One hiring manager literally said, "I clicked the webhook thing because nobody builds those for fun."

The results, honestly reported

Three interview requests within a month of updating the portfolio, from applications where I linked the lab page. Two of those turned into onsites, one into an offer. Correlation isn't causation — the market, my resume, and luck all played roles — but the interviewers' questions made it clear the projects changed the conversation from "can you do the job" to "tell me about this thing you built."

That's a much better conversation to have.

The reusable checklist

If you've got your own misc-attempts folder, here's the compressed version of what worked:

1. Pick projects that are yours, not tutorial clones.
2. Six hours max per project. README, demo or video, short postmortem.
3. Deploy it or record it. Never make anyone clone.
4. Kill or hide anything that overlaps with existing tutorials.
5. Write the failure honestly. That's the part nobody fakes.

The corpses were never the problem. I just kept burying them instead of putting them on display.