The portfolio paradox

We're told that a strong portfolio of side projects is the golden ticket to landing a software engineering job. Build things, ship them, show initiative. It sounds simple enough. But what happens when you take that advice seriously, when you build projects that actually make money, attract users, and turn into real businesses? You become less hireable, not more. This is what I call the portfolio paradox: the better your side projects are, the worse your chances of getting a traditional job.

The advice everyone gives

If you've ever searched for tips on breaking into tech, you've heard the usual guidance. Build side projects. Contribute to open source. Show hiring managers you can code outside of a classroom. The logic is that side projects demonstrate passion, technical skill, and initiative. And for the most part, this advice works, as long as your projects stay safely within the realm of "impressive but harmless." A to-do app in React. A portfolio site. Maybe a clone of a popular product. These projects check the boxes without raising any red flags. But what if you go further? What if you build a SaaS product that generates revenue? What if you launch an app with paying customers? What if you, in every meaningful sense, start a business? That's where the paradox kicks in.

The research that proves it

This isn't just a feeling. Researchers at Yale School of Management ran a field experiment that confirmed the paradox in hard numbers. Tristan Botelho and Melody Chang applied to 2,400 entry-level software engineering jobs using fictitious résumés. Some profiles described a successful startup founder, some a failed founder, and some a candidate with no founder experience at all. The results were striking. Candidates with no founder experience received callbacks 24% of the time. Founders overall were called back just 13.6% of the time. And here's the real twist: successful founders had the worst results, with a callback rate of only 10.9%, compared to 16.2% for failed founders. The researchers then tried mid-level roles, thinking maybe founders were just seen as overqualified for entry-level positions. Same result. The non-founder got callbacks at more than double the rate of the successful founder.

Why success scares recruiters

When the researchers interviewed 20 technical recruiters, a clear pattern emerged. Recruiters valued the entrepreneurial mindset in theory, but in practice they saw founders as risky hires. Their concerns boiled down to three things: Flight risk. Recruiters are evaluated on retention. A candidate who has already built something successful looks like someone who will leave in six months to chase the next idea, potentially taking colleagues with them. Poor cultural fit. Founders are used to setting their own direction, making decisions autonomously, and wearing many hats. That independence reads as a red flag in environments that value hierarchy and role clarity. As one recruiter put it bluntly: "Founders look like aliens to people." Overqualification anxiety. A candidate who has shipped a product, managed users, handled billing, and made business decisions doesn't fit neatly into a "junior developer" or even "mid-level engineer" box. Hiring managers don't know what to do with someone whose experience is both broader and less conventional than expected.

The real contradiction

This creates a genuinely absurd situation. The tech industry constantly preaches the value of building things, shipping fast, and thinking like an owner. Companies plaster "entrepreneurial mindset" across their job listings. But when an actual entrepreneur shows up, they get penalized for it. Meanwhile, the candidate who built a snake game in Python, a project with zero users, zero revenue, and zero real-world complexity, gets the interview. Not because the snake game demonstrates superior engineering, but because it signals something recruiters actually care about: compliance. It says, "I'm enthusiastic enough to code on the side, but not so ambitious that I'll leave." In the age of AI, where generating boilerplate code is trivially easy, the bar for what constitutes an "impressive" side project should be rising. Building a basic CRUD app no longer demonstrates much. Building a product that people pay for demonstrates product thinking, resilience, customer empathy, and technical skill across the full stack. And yet the job market continues to reward the former over the latter.

The entrepreneurial engineer's dilemma

This paradox hits a specific kind of engineer hardest: the entrepreneurial engineer. These are people who are too hands-on to be fulfilled as managers, too versatile to be pigeonholed into a narrow specialty, and too ambitious to sit quietly in a corporate role. Startups offer the ideal environment for this kind of engineer, but startups mature. The scrappy early days give way to process, hierarchy, and specialization. The entrepreneurial engineer is then faced with a recurring choice: stay and stagnate, or leave and face the job market again, carrying a résumé that makes recruiters nervous. Arvid Kahl, who writes about bootstrapping and indie hacking, describes this trajectory well. Once you've experienced the autonomy of building your own thing, it's hard to go back to a system that expects compliance and submission. You've learned that you can do more than anyone ever asked of you. That self-knowledge is powerful, but it's also exactly what makes traditional employment feel like a bad fit, and what makes traditional employers see you as a bad fit.

What this means in practice

If you're a software engineer weighing whether to build a toy project or a real product, here's the uncomfortable truth: the toy project is probably better for your job search. Not because it's more impressive, but because the hiring system is optimized for signals of conformity, not signals of capability. That doesn't mean you shouldn't build real things. It means you should go in with open eyes about the trade-offs. If you build a revenue-generating product, you may be building something far more valuable than a portfolio piece, but you'll need to work harder to convince employers you're not a flight risk. Some practical ways to navigate this:

The bigger picture

The portfolio paradox reveals something deeper about how the tech industry evaluates talent. We claim to value builders, but our hiring systems are designed to filter for employees. We celebrate entrepreneurship in blog posts and conference talks, then penalize it in résumé screens and interviews. Until hiring practices catch up with the rhetoric, the paradox will persist. The best side project for getting a job will continue to be the one that shows just enough initiative to be interesting, but not so much that it threatens the status quo. And if you've already crossed that line, if you've built something real, something that makes money and serves users, don't let the paradox discourage you. The skills you've developed are genuinely more valuable than what any toy project could teach. The job market just hasn't figured out how to recognize that yet.

References