The 90-Second Test: I Rebuilt My Side Project for a Hiring Manager Who Doesn't Exist

Somewhere around week two of this experiment, I caught myself deleting a perfectly functional feature at 1 a.m. and muttering, "I couldn't defend that in a panel."

That's when I knew the diet was working. Or breaking me. Possibly both.

The Rules of the Diet

Here's the setup: for thirty days, my side project — a scheduling tool for volunteer shifts that has roughly twelve users, four of whom are related to me — could only receive work that passed one filter. Could I demo and explain it to a hiring manager in ninety seconds, and would they care?

Not "is it useful." Not "is it interesting to me at 2 a.m." Not "does it use that new thing I saw on Hacker News." Just: does it survive a fictional interview round where some imaginary staff engineer leans back in their chair and says, "So walk me through what you built."

I kept a running ledger. Every candidate feature, every refactor, every bug fix went into one of three buckets: Shipped, Cut, or Deferred Until I Have a Real Job Again. The ledger is genuinely embarrassing and I'm going to share it anyway.

What Got Cut (RIP)

The plugin architecture. I spent three weekends last year building a plugin system for a tool with twelve users. Twelve! There were zero plugins. Not even mine. It existed because I read a blog post about extensible design and got ideas above my station. Under the diet, it failed instantly — try explaining an empty plugin registry to an interviewer. "So it's a system for extensions that don't exist?" Next question.

My custom logging framework. Four hundred lines of what was essentially print() with delusions of grandeur. Cut. Replaced with structured logging in an afternoon, which — and this stung — took less time than writing the original thing.

The admin dashboard with six charts. I kept two. The other four charted metrics that, when asked aloud "why does this number matter," I could not answer. A chart you can't justify is a screensaver.

WebSockets. The app polled every fifteen seconds. That's fine. That's genuinely fine. I rebuilt it with WebSockets because WebSockets felt like the kind of thing that separates "hobbyist" from "engineer." The diet called my bluff: "Why does a volunteer shift scheduler need real-time updates? Is the church bake sale latency-sensitive?" It is not. Cut.

What Survived (and Thrived)

The conflict detection logic. Double-booking volunteers was the actual problem the app solves, and the solution involves some satisfying constraint checking with a clear before/after. Ninety seconds: "Before, two people could sign up for the same slot and nobody knew until Sunday morning. Now the system catches it at signup, here's the edge case with recurring shifts that made it hard, and here's how I handled it." That's an interview answer with a beginning, middle, and end.

The test suite. Boring. Unsexy. But "I have 87% coverage on the scheduling core and here's the property-based test that found a timezone bug" is a sentence that makes interviewers write things down.

The failure story. I wrote up the outage where a bad migration took the app down for six hours during signups. Under the diet, this wasn't a blog post — it was ammunition. Real engineers love a well-told failure more than a highlight reel. My fictional panel ate it up.

The Uncomfortable Discovery

Here's the thing I didn't expect: the product got better. Not despite the diet — because of it.

When your only user is a skeptical imaginary interviewer, you stop building features and start building evidence. Every line of code has to earn its place in the demo. The app shed maybe 30% of its code and every remaining piece now has a reason to exist that I can articulate in one breath.

But — and I want to be honest about this — the diet also distorted things. I deprioritized onboarding improvements because "improved copy on the signup flow" is a weak interview answer, even though it's probably the highest-impact change my twelve actual users would feel. I favored flashy-but-marginal work like the new conflict UI over unglamorous-but-real work like rate limiting. The fictional panel has taste, but it's a performed taste, and catering exclusively to it makes you a resume-driven developer in the worst sense of the phrase.

So Is This How You Should Build Portfolio Projects?

Half of it, yes. The ninety-second test is a genuinely great pruning heuristic, and I'm keeping it permanently for feature cuts. If you can't say why something exists, you shouldn't have it.

But as a north star? No. The best portfolio projects solve a real problem for real people, and the interview magic comes from being able to talk about those people — what they needed, what broke, what you learned. Optimize for the story, not the storyteller.

My imaginary hiring manager is retired now. The app polls every fifteen seconds again, on purpose. And next sprint, I'm fixing that signup copy — for the twelve users, not the panel.