According to The How-To Geek, some of the most influential tools and products in tech began as modest side projects. In 2005, a student project called Narbacular Drop, created by Kim Swift and her team, was demoed to Valve’s Gabe Newell, who hired the entire team on the spot to build what became Portal. In 2015, Dan Abramov created Redux as a proof-of-concept for a conference talk, which led to him being hired by Facebook’s React team after the presentation. That same year, François Chollet released his deep learning library Keras as a personal research project, leading Google to hire him first for research and then to officially integrate Keras into TensorFlow. Earlier, in 2003, Chris Lattner released his LLVM compiler project as open source from his doctoral research, catching Apple’s eye and leading to a job where he later created Swift. These projects weren’t built for profit, but their utility and elegant design made them impossible for the industry to ignore.
The Unfiltered Audition
Here’s the thing about a traditional resume or a degree: they’re proxies. They’re supposed to represent your skills. But a side project? It is your skill, rendered in executable code. It cuts through the corporate HR noise like a laser. When Gabe Newell saw that student game demo, he wasn’t looking at a GPA. He was looking at a brilliant, fun, novel game mechanic that was already working. He bought the team, not their credentials. Same story for Sebastian McKenzie, who built Babel in high school. No degree, no “professional experience,” but he had built a tool the entire JavaScript ecosystem desperately needed. That’s a more powerful portfolio than any internship.
Solving Your Own Itch
Look at the common thread. Kenneth Reitz was frustrated with Python’s awful HTTP libraries. Dan Abramov needed time-travel debugging for a talk. Ari Weinstein saw a gap in iOS automation. They weren’t trying to build a billion-dollar startup. They were just solving a problem that genuinely annoyed them, with a focus on great design and developer experience. And that authenticity is magnetic. When you build something because you need it, you’re likely building something others need, too. That’s how Requests became a Python standard. That’s how Workflow became Shortcuts. It’s pure product-market fit, born from personal frustration.
The Acqui-Hire Playbook
This pattern is basically the ultimate “acqui-hire” playbook, but in reverse. Usually, a big company buys a small one for its team. In these cases, the company is effectively hiring a person (or team) for a project that already exists and has already proven its value in the wild. Apple didn’t hire Chris Lattner and then ask him to make a better compiler. They hired him because he’d already built LLVM. Google didn’t hire François Chollet to maybe one day build a nice API. They hired him because Keras was already that nice API. The interview is the project’s adoption rate, its GitHub stars, its community love. The risk for the hiring company is almost zero.
Stop Waiting For Permission
So what’s the takeaway? Stop waiting for a manager to assign you the cool project. The most career-defining work often happens off the clock. It doesn’t have to be huge. Reitz built the first version of Requests in two hours! But it has to be excellent and it has to be public. Put it out there. Let people use it. The market for talent is desperate for signals that cut through the noise, and a beloved, useful side project is the brightest signal there is. It’s the ultimate cheat code. And who knows? You might just end up creating the next standard everyone has to use. Just ask any React developer who’s had to manage state, or any Python dev making an API call.
