Back to all essays

I Wasted $24K Hiring for Experience (Here's What Actually Matters)

·7 min read
George Pu
George Pu$10M+ Portfolio

27 · Toronto · Building businesses to own for 30+ years

I Wasted $24K Hiring for Experience (Here's What Actually Matters)

Hired someone for $8K/month last year because they "had experience."

Great resume. Said all the right things. Confident in interviews.

3 months later: nothing shipped. Excuses. Meetings about meetings. Always "almost done."

$24K and a quarter of momentum—gone.

Here's what I do differently now: I hire slower. I watch what people actually do in the first 2 weeks, not what they say they'll do.

And when it's not working, I end it fast. Not in 3 months. In 3 weeks.

The expensive lesson: Experience on paper means nothing. Output in reality means everything.


The Resume Delusion

What I thought I was hiring:

  • Senior developer with 8 years experience
  • Previous roles at "recognizable" companies
  • Technical skills that matched our needs perfectly
  • Someone who could "hit the ground running"
  • Leadership potential for future team growth

What I actually hired:

  • Someone great at interviewing
  • Expert at corporate politics and bureaucracy
  • Master of appearing busy without producing results
  • Professional excuse generator
  • Meeting enthusiast

The gap between resume and reality cost me $24,000.


The Interview Theater

Their interview performance:

Technical Questions: Answered everything perfectly. Used the right buzzwords. Explained complex concepts clearly.

Experience Stories: Had impressive examples from previous companies. Talked about "leading initiatives" and "driving outcomes."

Cultural Fit: Said exactly what I wanted to hear about working style, communication, and autonomy.

References: Glowing reviews from former managers and colleagues.

My conclusion: This is exactly what we need.

The reality: They were exceptional at performing competence, terrible at actual competence.


The 3-Month Nightmare

Week 1-2: The Honeymoon

  • Lots of questions (seemed engaged)
  • Setting up development environment
  • "Getting familiar with the codebase"
  • Weekly check-ins going well

Week 3-6: The Red Flags

  • First deliverable pushed back "for quality"
  • Meetings to discuss meetings
  • "Almost ready" became the default status
  • Simple tasks taking weeks, not days

Week 7-12: The Excuses

  • "The codebase is more complex than expected"
  • "Need to refactor before adding features"
  • "Previous team made questionable decisions"
  • "Setting up proper testing frameworks first"

The output after 3 months:

  • Zero features shipped to customers
  • One internal tool half-finished
  • Extensive documentation about what needed to be done
  • Multiple proposals for "better approaches"

What our $3K/month contractor in India shipped in the same period:

  • 4 major features
  • 12 bug fixes
  • 2 integration improvements
  • Consistent weekly progress

The math was humiliating.


The Sunk Cost Trap

Why I kept them for 3 months:

Month 1: "They're still ramping up. This is normal."

Month 2: "We've invested so much in onboarding. They'll turn it around."

Month 3: "They're almost done with that big feature. Let's see it through."

The psychology: I didn't want to admit I'd made a $24K mistake.

The reality: Every week I delayed firing them cost another $2K plus opportunity cost.

The lesson: Sunk cost fallacy is expensive. Cut losses early.


What Experience Actually Means

What I thought "8 years experience" meant:

  • 8 years of learning and improving
  • Deep expertise in relevant technologies
  • Proven ability to ship products
  • Understanding of what customers need

What "8 years experience" actually meant:

  • 8 years in corporate environments
  • Expert at navigating bureaucracy
  • Skilled at looking busy without results
  • Comfortable with slow, process-heavy development

The disconnect: Their experience was in big companies where "moving fast" means shipping quarterly. I needed someone where "moving fast" means shipping weekly.

Different games. Different skills.


The New Hiring Framework

Old approach: Interview and Hope

  1. Post job description
  2. Review resumes
  3. Conduct interviews
  4. Check references
  5. Make offer
  6. Pray it works out

New approach: Trial by Fire

  1. Post simple project description
  2. Ask for work samples (actual code, not talks about code)
  3. Give paid trial project (1-2 weeks, $500-1000)
  4. Evaluate based on output, not words
  5. Hire only if trial exceeds expectations

The difference: I see what they actually do, not what they say they do.


The 2-Week Trial System

How it works:

Week 1: Simple Feature

  • Give them a well-defined, small feature
  • Provide access to staging environment
  • Set clear expectations and deadline
  • Minimal guidance (see how they work independently)

Week 2: Customer Feedback Integration

  • Share real customer feedback
  • Ask them to propose and implement solution
  • See how they prioritize and communicate
  • Evaluate their customer empathy

What I'm evaluating:

  • Output quality: Does it work? Is code clean?
  • Communication: Do they ask good questions? Update proactively?
  • Speed: Do they ship on time or make excuses?
  • Initiative: Do they suggest improvements or just follow orders?
  • Customer focus: Do they understand why features matter?

Pass rate: About 30% of candidates who look great on paper.


Red Flags I Now Recognize

During trial period, immediate red flags:

The Process Perfectionist

  • Wants to set up elaborate workflows before starting
  • Spends more time planning than coding
  • Asks for requirements documents for simple features
  • "We should really have proper CI/CD first"

The Meeting Requester

  • Wants daily check-ins for simple tasks
  • Schedules "alignment sessions" constantly
  • Prefers talking about work to doing work
  • "Let's hop on a call to discuss this"

The Excuse Generator

  • Every delay has an external reason
  • "The documentation wasn't clear"
  • "I'm waiting for clarification on X"
  • Never takes ownership for outcomes

The Scope Creeper

  • Simple tasks become complex projects
  • "Actually, we should rebuild this entire module"
  • "Let me refactor this first"
  • Can't ship incrementally

I end trials immediately when I see these patterns. No exceptions.


Green Flags That Actually Matter

Candidates who succeed in trials:

The Pragmatic Shipper

  • Asks clarifying questions upfront, then executes
  • Ships working solutions quickly
  • Iterates based on feedback
  • Focuses on customer value, not technical perfection

The Proactive Communicator

  • Updates progress without being asked
  • Flags potential issues early
  • Suggests improvements based on user perspective
  • Writes clear, concise status updates

The Problem Solver

  • Doesn't get blocked by ambiguity
  • Makes reasonable assumptions and documents them
  • Finds workarounds when stuck
  • Takes ownership of outcomes

The Customer-Focused Builder

  • Asks why features matter
  • Suggests user experience improvements
  • Tests their own work thoroughly
  • Thinks beyond just writing code

These traits have zero correlation with years of experience or resume impressiveness.


The India Contractor Revelation

While the $8K/month "experienced" developer produced nothing:

My $3K/month contractor in Bangalore:

  • Shipped 4 features in 12 weeks
  • Communicated daily via Slack
  • Fixed bugs within hours of reporting
  • Suggested useful product improvements
  • Never missed a deadline

The skill difference: Negligible. Both could code well.

The mindset difference: Massive. One optimized for looking busy. The other optimized for shipping.

Want the full playbook? I wrote a free 350+ page book on building without VC.
Read the free book·Online, free

The cost difference: $5K/month for 10x the output.

The lesson: Geographic arbitrage + trial-based hiring beats resume hiring every time.**


What Experience Actually Predicts

Years of experience correlates with:

  • Interview performance
  • Technical knowledge breadth
  • Process familiarity
  • Salary expectations
  • Confidence in meetings

Years of experience doesn't correlate with:

  • Shipping velocity
  • Customer empathy
  • Problem-solving creativity
  • Willingness to learn new things
  • Output quality

The hiring mistake: Optimizing for the wrong metrics.**

Better predictor of success: How they handle a real project with real constraints and real deadlines.


The 3-Week Rule

New policy: If it's not working after 3 weeks, it's not going to work.

Week 1: Benefit of the doubt (ramping up) Week 2: Clear expectations and feedback Week 3: Final evaluation and decision

No more:

  • "Let's give them another month"
  • "They're almost turning the corner"
  • "We've invested so much already"
  • "Maybe they need different projects"

The 3-week rule has saved me:

  • Approximately $50K in bad hires
  • Months of lost momentum
  • Team morale issues
  • Customer disappointment

Fast hiring, fast firing beats slow hiring, slow firing.


What I Look for Now

Instead of asking: "How many years of experience?"

I ask: "Show me something you built last month."

Instead of: "Tell me about a challenging project"

I say: "Here's a challenging project. Build it."

Instead of: "What's your greatest weakness?"

I evaluate: How do they handle real feedback on real work?

Instead of: "Where do you see yourself in 5 years?"

I observe: Do they ship this week's work on time?

The shift: From hypothetical performance to actual performance.**


The Uncomfortable Truth About Experience

Most "experienced" developers have experience in the wrong things:

  • Navigating corporate politics ✓
  • Writing extensive documentation ✓
  • Attending planning meetings ✓
  • Following elaborate processes ✓
  • Shipping quickly ✗
  • Working autonomously ✗
  • Focusing on customer value ✗
  • Iterating based on feedback ✗

For startups, inexperience in corporate bullshit is often an advantage.

I'd rather hire someone with 2 years of experience who ships weekly than someone with 10 years who ships quarterly.


Real Examples: Trial Success Stories

Current team members who passed trials:

Developer #1 (2 years experience):

  • Trial: Built customer dashboard feature in 1 week
  • Red flag: Asked a lot of questions initially
  • Green flag: Shipped working solution ahead of schedule
  • 6 months later: Our most productive team member

Developer #2 (4 years experience):

  • Trial: Integrated payment system in 2 weeks
  • Red flag: No experience with our tech stack
  • Green flag: Learned it during trial and delivered
  • 8 months later: Promoted to lead developer

Developer #3 (1 year experience):

  • Trial: Built mobile-responsive feature
  • Red flag: Fresh graduate, minimal experience
  • Green flag: Code quality exceeded expectations
  • 4 months later: Handling complex projects independently

Common traits: All focused on shipping, not on seeming impressive.**


The Resume vs Reality Test

Questions that reveal the gap:

Resume says: "Led team of 5 developers" Reality check: "Show me code you personally wrote last month"

Resume says: "Delivered major features on schedule"
Reality check: "What did you ship last week?"

Resume says: "Expert in React, Node.js, Python" Reality check: "Build a simple CRUD app in your preferred stack"

Resume says: "Improved performance by 40%" Reality check: "Here's a slow query. Optimize it."

The pattern: Resumes describe what teams did. Trials show what individuals do.**


What This Means for Founders

If you're hiring based on resumes and interviews:

  • You're optimizing for performance, not competence
  • You're competing with big tech for the same "experienced" talent
  • You're paying premium prices for unproven productivity
  • You're setting yourself up for expensive mistakes

If you're hiring based on trials:

  • You see actual work quality before committing
  • You can hire globally without location bias
  • You pay for results, not credentials
  • You build a team of proven shippers

The choice: Hire slow and expensive, or hire smart and effective.**


Action Steps for Better Hiring

This week:

  • Create a simple 1-2 week trial project for your next hire
  • Define clear success criteria for the trial
  • Set up a staging environment for candidates to use
  • Write evaluation framework focusing on output, not credentials

This month:

  • Test trial system with 2-3 candidates
  • Compare trial performance to interview impressions
  • Refine trial project based on what you learn
  • Document red flags and green flags you observe

This quarter:

  • Build pipeline of trial-tested candidates
  • Calculate cost savings vs traditional hiring
  • Share trial system with other founders
  • Expand trials to other roles (design, marketing, etc.)

The goal: Never hire based on promises again. Only hire based on proof.


The $24K Lesson

What I learned from wasting $24,000:

Experience is often experience in the wrong things.

Resumes are marketing documents, not performance predictors.

Interviews test presentation skills, not execution skills.

Confidence in meetings doesn't correlate with competence in work.

The best predictor of future performance is recent performance.

Cut losses fast. The sunk cost fallacy is expensive.

Most importantly: Trust what people do, not what they say they do.


Why This Matters

Because most founders make the same hiring mistakes I did.

Because "experience" often means experience with bureaucracy, not execution.

Because interview skills and work skills are completely different.

Because bad hires cost more than money—they cost momentum and morale.

The solution isn't better interviews. It's actual work trials.

See what people do when no one's watching. That's who they really are.

Experience on paper means nothing. Output in reality means everything.