Why Passion Projects Beat Course Projects Every Time

PASSION PROJECT — FIRST 90 SECONDS:

Interviewer: "Tell me about a project you're
proud of."

Candidate: "Sure. It's a running-club tracker
I built because our WhatsApp group kept
losing the weekly route.

The problem: 40 people in the club, and every
week someone asked 'what's the route?' or
'who's coming?' — the info was scattered
across messages.

The first version: a Google Form and a
Sheet. It worked for 2 weeks, then the club
grew past 20 and the Sheet got messy —
duplicate RSVPs, no route map.

So I rebuilt it as a small app: a React
front end, an Express API, and a Postgres
table for routes and RSVPs. Now people see
the route on a map, RSVP with one tap, and
get a reminder on Saturday.

The iteration: 12 versions in 18 months. The
most requested feature was the reminder — I
added it in v4. The most painful bug was a
timezone issue that sent reminders at 3 AM —
I fixed it by moving to the club's local
timezone.

The cost: I spend about 2 hours a month
maintaining it. I keep it because 40 people
use it every week, and it's the reason I
learned Postgres and React properly.

What the interviewer thinks in 90 seconds:
- "There's a real problem." ✅
- "There are real users: 40 people, weekly." ✅
- "There's iteration: 12 versions, a real
  bug." ✅
- "They learned from it and maintain it." ✅
- "This is ownership." ✅

Signal: strong. The rest of the interview
confirms it.

COURSE PROJECT — FIRST 90 SECONDS:

Interviewer: "Tell me about a project you're
proud of."

Candidate: "I built a to-do app for my React
course. It has add, delete, and filter
features. I used React hooks and
localStorage. The course instructor said it
was good."

What the interviewer thinks in 90 seconds:
- "No problem — the course told them what
  to build." ❌
- "No users — the grader is not a user." ❌
- "No iteration — it's a one-shot build." ❌
- "No decisions — the rubric made them." ❌
- "This could be any student's project." ❌

What happens next:
- The interviewer asks "Why a to-do app?"
- The candidate says "It was the course
  project."
- The interviewer asks "What would you
  change if you had real users?"
- The candidate gives a generic answer.

Signal: weak. The candidate can code, but
they haven't shown they can decide what to
build.

Why it failed:
❌ No real problem
❌ No users
❌ No iteration
❌ No decisions
❌ The first 90 seconds signaled "I
  completed an assignment," not "I own a
  project"

DECISION ANSWER — WHAT DECIDES:

Interviewer: "Why did you build it this
way?"

WHAT THE CANDIDATE SAYS:
"Three decisions, and each has a cost I
accepted.

Decision one: Postgres over MongoDB. The
RSVP data needs a unique constraint per
event per person — duplicates were the #1
bug in v1's Google Sheet. Postgres makes the
constraint the default; MongoDB would have
meant an application-level check. The cost:
a stricter schema and migrations.

Decision two: a single server, not
serverless. The club runs on a $5/month VPS.
Serverless would have been cheaper at this
scale, but cold starts on a Saturday morning
RSVP rush were a real risk. The cost: I'm
the sysadmin.

Decision three: the reminder is a cron job,
not a push notification. Push needs an app
install, and the club wouldn't install a
second app for one feature. The cost: no
lock-screen reminder, but email open rates
are 80%, so it works.

The trade-off I'd revisit: the VPS. If the
club grows past 200, I'd move to a managed
Postgres, but at 40 people it's not worth
the migration."

What the interviewer thinks:
- "Three decisions, each with a cost." ✅
- "The data-layer reasoning is specific." ✅
- "The scale is named: 40 vs. 200." ✅
- "The trade-off is named with a trigger." ✅
- "They own the architecture." ✅

Signal: confirmed ownership.

Why it decides:
✅ Decisions are named
✅ Costs are named
✅ Scale is specific
✅ A revisit has a trigger
✅ Architecture is owned

ITERATION ANSWER — WHAT DECIDES:

Interviewer: "What did you learn from
users?"

WHAT THE CANDIDATE SAYS:
"Three lessons, and each changed the
product.

Lesson one: the reminder. 8 of 40 people
asked for a Saturday reminder — the no-show
rate was 15%. I shipped it in v4, and the
no-show rate dropped to 6%. That's the
feature I'm most proud of, because it came
from users, not from me.

Lesson two: the route map. People were
copy-pasting Google Maps links into
WhatsApp. So I added an embedded map with
the route pre-loaded. The link-clicks
dropped to zero — people just open the app.

Lesson three: the RSVP list. I built it as
a private list, only visible to me. That was
wrong — people wanted to see who was coming,
because the run is social. I made it public
in v7, and RSVPs went up 20% in the next
month.

The cost: each iteration took 2–3 weekends.
I chose that over a bigger launch because
shipping small meant I could ask users what
they wanted next, not guess.

The one I got wrong: I built a leaderboard
in v9. It was a hit for 2 weeks, then
people stopped using it — running together
isn't a competition. I removed it in v10.
The lesson: I now ask 'what would you use
next week?' before building anything."

What the interviewer thinks:
- "Three lessons, each from users." ✅
- "Each changed a metric." ✅
- "They shipped small and asked." ✅
- "They admitted a feature that failed." ✅
- "They changed their process from the
  failure." ✅

Signal: confirmed ownership.

Why it decides:
✅ Lessons come from users
✅ Each has a metric
✅ Shipping small is a choice
✅ A failure is admitted
✅ The process changed from the failure

DEBUGGING STORY — PASSION VS. COURSE:

Scenario: "Tell me about a bug that took you
a long time to fix."

COURSE SIGNAL:
"One time my to-do app had a bug where the
list didn't update. I fixed it by adding a
key prop."
What the interviewer thinks:
- "That's a tutorial bug."
- "No users affected, no stakes."
- Signal: course-level.

PASSION SIGNAL:
"The reminder emails were going out at 3 AM
on Saturday instead of 8 AM. 40 people got
a notification at 3 AM — 6 people messaged me
about it.

The root cause: my cron job ran on the
server's timezone, which was UTC, but the
club runs on IST. So 8 AM IST was 2:30 AM
UTC, and the job was set at 8 AM UTC — which
landed at 1:30 PM IST. The 3 AM part was a
different bug: I had a retry that fired on
failure, and the failure was a missing SMTP
credential that I'd forgotten to set.

The fix: I moved the cron to run on IST
explicitly, and I added a credential check
that fails the job loudly before it tries to
send. I also added a test that runs the job
with a mock timezone and asserts the send
time.

The prevention: I added a health check that
sends a test email to me every Sunday at
7:55 AM IST — if it fails, I know before the
club does.

The cost: the test email is a bit of noise,
but it's caught two issues since.

The lesson: never trust a server's default
timezone for anything a user will see."

What the interviewer thinks:
- "Real users were affected: 40 people,
  6 messages." ✅
- "Two bugs, both traced." ✅
- "The fix targets the cause." ✅
- "The prevention is a test and a health
  check." ✅
- "The lesson is reusable." ✅
- Signal: confirmed ownership.

Why it decides:
✅ Real users and impact
✅ Two root causes traced
✅ Fix targets the cause
✅ Prevention: test + health check
✅ Reusable lesson

PORTFOLIO REVIEW — PASSION VS. COURSE:

Scenario: "Review this portfolio. The
candidate lists two projects."

COURSE-ONLY PORTFOLIO:
- To-do app: React, hooks, localStorage
- Weather app: fetch an API, display data
- No users, no README, no decisions
- Both are named after the course module

What the interviewer thinks:
- "These are course projects."
- "No users, no iteration, no decisions."
- "I can't tell what they'd build for
  themselves."
- Signal: no-hire for mid/senior.

PASSION PORTFOLIO:
- Running-club tracker: live link, 40 weekly
  users, 12 iterations
- A README with: the problem, the users,
  the decisions (Postgres over MongoDB, VPS
  over serverless), the failures (the
  leaderboard), and the next step
- A "what I'd do differently" note: "I'd
  add offline support — the route is often
  loaded on a phone with no signal at the
  start line."
- A maintenance note: "2 hours a month, on
  a $5 VPS"

What the interviewer thinks:
- "There's a real problem and real users." ✅
- "Decisions are named with costs." ✅
- "A failure is admitted." ✅
- "The next step is specific." ✅
- "The maintenance cost is honest." ✅
- Signal: strong hire.

Why it decides:
✅ Real problem and real users
✅ Decisions with costs
✅ Failure admitted
✅ Specific next step
✅ Honest maintenance cost

Project Signal Checklist:

FIRST 90 SECONDS:
☐ Name why the project exists: the
  problem, the users
☐ Name how many people use it
☐ Name one iteration from feedback
☐ Avoid "it was the course project"

WHAT DECIDES:
☐ Name one technical decision and its
  cost
☐ Name one metric that moved:
  no-show rate, RSVPs, latency
☐ Name one failure and what you changed
☐ Name the maintenance cost: time, money

WHAT CONFIRMS:
☐ Show a live link or a reproducible
  build
☐ Name the next step with more time
☐ Answer "why did you build it?" without
  pausing
☐ Answer "what did users ask for?" with
  a specific request
☐ Answer "what failed?" with a real
  failure

RED FLAGS:
❌ "It was the course project"
❌ No users
❌ No iteration
❌ No decisions
❌ No failure
❌ No maintenance cost
❌ A to-do app with no reason

Why this works:
- The first 90 seconds set the signal
- The rest of the interview confirms or
  overturns it
- A real problem, real users, and a real
  failure are the three things that can't
  be faked

30-DAY PROJECT PLAN (FOR CANDIDATES):

Week 1 — Pick a real problem
☐ List 5 problems in your own life, your
  club, your family, your community
☐ Pick one that 5+ people have
☐ Write one sentence: who has this
  problem, and why
☐ Build the ugliest version: a form, a
  sheet, a script

Week 2 — Ship to real users
☐ Give it to those 5+ people
☐ Watch them use it
☐ Write down the 3 things they ask for
☐ Fix the top one

Week 3 — Add a decision and a cost
☐ Make one technical decision and write
  the cost
☐ Make one failure and write what
  changed
☐ Add one metric: users, time saved,
  errors caught

Week 4 — Write the README
☐ The problem and the users
☐ The decisions and their costs
☐ The failure and what changed
☐ The maintenance cost
☐ The next step

Signs it's working:
✅ You can name the users and how many
✅ You can name an iteration from
  feedback
✅ You can name a decision and its cost
✅ You can name a failure
✅ You can name the maintenance cost
✅ The interviewer asks "what else?"
  instead of "was this a course project?"