Is Open Source the New LeetCode? My Tough First PR
Is contributing to open source the new LeetCode for landing a dev job? I share my tough first PR experience and compare the skills you gain from each.
Michael Rodriguez
Senior Software Engineer passionate about open source, mentorship, and real-world coding skills.
We’ve all been there. Hunched over our keyboards, staring at a problem about traversing a binary tree or finding the median of two sorted arrays. The LeetCode grind has become a rite of passage for software engineers, a necessary hurdle to clear before landing that dream job. But lately, I’ve been hearing a different question in tech circles: Is contributing to open source the new LeetCode?
It’s a tantalizing idea—trading abstract puzzles for real-world code that people actually use. To find out, I dove headfirst into the world of open source. What followed was one of the most challenging, humbling, and ultimately rewarding experiences of my career: my very first pull request.
The LeetCode Grind: A Rite of Passage?
Let's be clear: LeetCode has its place. It’s fantastic for sharpening your understanding of data structures and algorithms (DS&A). It forces you to think about edge cases, time complexity, and space complexity in a controlled, isolated environment. There's a reason Big Tech companies rely on it—it’s a standardized way to test foundational computer science knowledge.
But the grind can feel… disconnected. You solve a problem, your solution is accepted, and you move on. You rarely see how that clever algorithm fits into a larger system, how it’s maintained, or how it interacts with dozens of other moving parts. It’s like practicing free throws without ever playing in a real basketball game.
The Rise of Open Source as a Credibility Signal
This is where open-source contribution (OSS) comes in. Contributing to an established project isn't just about writing code; it's about proving you can function as a modern software engineer. When a recruiter sees a merged PR on your GitHub profile, they see evidence of skills that LeetCode can't measure:
- Collaboration: You successfully used Git, navigated a code review, and communicated with maintainers.
- Reading Code: You were able to understand a large, unfamiliar codebase well enough to make a meaningful change.
- Real-World Problem Solving: You didn't just solve a puzzle; you fixed a bug or added a feature that real users needed.
- Patience and Professionalism: You handled feedback, iterated on your work, and followed project-specific guidelines.
An open-source contribution is a public, verifiable artifact of your ability to work on a team and deliver value. It’s the difference between saying you can play basketball and showing a highlight reel of you sinking a game-winning shot.
LeetCode vs. Open Source: A Head-to-Head Comparison
To really break it down, let's look at what each path offers. Neither is inherently superior, but they build vastly different—and complementary—skill sets.
Feature | LeetCode | Open Source Contribution |
---|---|---|
Primary Skill Tested | Algorithmic thinking & DS&A knowledge | Collaboration, code comprehension, real-world application |
Real-World Applicability | Low to Medium. Concepts are vital, but problems are abstract. | High. Directly mimics day-to-day engineering work. |
Collaboration | None. It’s a solo activity. | Essential. Communication and code reviews are core to the process. |
Feedback Loop | Instantaneous (Pass/Fail from automated tests). | Slow and human-driven (days or weeks of review and discussion). |
Visibility to Recruiters | Shows you can pass a technical screen. | Shows you can perform the job. A public portfolio of work. |
Barrier to Entry | Low. Sign up and start coding. | High. Finding a project, setting up the environment, and understanding the codebase is challenging. |
My First PR: A Humbling (and Rewarding) Journey
Theory is great, but my real education came from experience. I decided to contribute to a popular command-line tool I used daily. I found an issue tagged good first issue
that seemed simple enough: “Incorrect error message for invalid flag.” Easy, right? I figured it would take an afternoon.
I was wrong. It took a week.
The Setup Nightmare
First, I couldn't even get the project to build. I spent the better part of a day wrestling with obscure dependencies, cryptic build scripts, and version mismatches. This wasn't a coding problem; it was a test of my patience and my ability to read documentation (and old, unanswered GitHub issues).
This is the first, unglamorous filter. Many aspiring contributors give up right here. Pushing through is a skill in itself.
Diving into the Codebase: An Act of Archaeology
Once it was running, I had to find the code. Where was this one error message generated? I felt like an archaeologist digging through layers of code, following function calls across dozens of files. The codebase was massive, with conventions and patterns I’d never seen before. The grep
command became my best friend.
Finally, I found it. A single line of text in a massive error-handling module. The actual code change was trivial: I corrected the string and added a placeholder for the invalid flag. It took me 5 minutes to write the code and 10 hours to find where to put it.
The Review: Where the Real Learning Happens
I proudly submitted my Pull Request. A maintainer responded within a few hours. I was expecting a quick “Thanks, merging!” Instead, I got a polite but firm list of requested changes:
- “Thanks for this! Could you please add a unit test to cover this case?” (I had no idea how their test suite worked.)
- “Our CI build is failing. It looks like you need to run the linter.” (What’s a linter?)
- “Please update the PR title to follow our contribution guidelines (e.g.,
fix(cli): correct error message for xyz
).” (I hadn’t read the contribution guidelines closely enough.) - “Instead of concatenating the string here, can you use our internal
localization
helper?” (I didn't even know that existed.)
I wasn’t offended; I was humbled. Every piece of feedback was a lesson. I learned about their testing framework, about code linting, about conventional commits, and about internal APIs. The back-and-forth took a few more days, but with each commit I pushed, I felt more like a real engineer and less like an outsider.
When my PR was finally merged, the feeling was a thousand times more satisfying than getting a green “Accepted” on LeetCode. I had navigated a complex social and technical system and made a tangible improvement to a tool I admired.
Key Takeaways: Should You Ditch LeetCode for GitHub?
Absolutely not. The question isn't about replacement; it's about augmentation.
- Start with the Fundamentals: LeetCode is still the best way to build the raw problem-solving muscle for DS&A. You need that foundation.
- Embrace the Mess: Open source teaches you how to apply those fundamentals in a messy, complex, real-world environment. This is a separate and equally critical skill.
- Your First PR is a Huge Win: Don't aim to refactor the core architecture on your first try. Fixing a typo in the documentation is a valid and valuable contribution. It gets you familiar with the workflow.
- Feedback is a Gift: A tough code review isn't a criticism of you; it's a free mentoring session from an experienced engineer. Absorb it.
Conclusion: It’s Not a Replacement, It’s a Superpower
So, is open source the new LeetCode? No. It’s what comes next. It's the practical exam after you've studied the textbook. LeetCode proves you can think like a computer scientist. An open-source contribution proves you can work like a software engineer.
The combination of the two is a true superpower. If you can solve complex algorithmic problems and demonstrate that you can patiently navigate a real-world codebase and collaborate effectively with a team, you become an incredibly compelling candidate.
So keep practicing those trees and graphs. But when you’re ready, find a project you love, read the contribution guidelines, and dive in. Your first PR might be tough, but the engineer you become on the other side is worth the struggle.