Ayush Sridhar
June 22, 2026
7 min read
June 22, 2026
7 min read
Share
Cut code review time & bugs by 50%
Most installed AI app on GitHub and GitLab
Free 14-day trial
In late October, I visited CodeRabbit’s offices to collect my prize from the CalHacks Hackathon.
A few months later, I walked into the CodeRabbit office as a SWE intern.
That’s the headline. But the part that matters (especially if you’re a junior dev) isn’t “wow, lucky.” It’s the chain of events that made it possible:
This post is for junior developers who are trying to land internships in a market that feels tougher than it should be. I want to share the “unofficial path” that worked for me.
The technical project that started it all was: merj, an AI-powered merge conflict resolver that used CodeRabbit to give an LLM the missing ingredient it needed to resolve conflicts correctly: semantic intent.
I’ll also share what I’m working on now as an intern. I’m taking the same core idea and turning it into something that can help teams resolve PR merge conflicts with a workflow that fits cleanly into GitHub.
CalHacks is chaotic and energetic in the best way. There’s half-coded demos, half-asleep teams, and a constant stream of “that doesn’t work, gotta fix that.”
My friends and I did what a lot of teams do at the start. We brainstormed a bunch of ideas, then walked around talking to sponsors and attendees to see what’s feasible and what would actually be fun to build in a weekend.
That’s when we ran into CodeRabbit.
At the time, we weren’t thinking “we need a code review product.” We were thinking like hackers: “We want to ship something ambitious in 36 hours and how do we keep it from collapsing under rushed changes?”
We realized CodeRabbit could help. And that’s when we met Hendrik Krack, a developer advocate at CodeRabbit.
This is the moment that changed everything. Hendrik didn’t just tell us about the product. He helped us refine the actual project idea in a way that made CodeRabbit genuinely useful to the solution.
Our early thinking was pretty typical hackathon-thinking: “Throw some context into an LLM and hope it figures it out.”
Hendrik pushed us toward a much better approach:
“Don’t just give the model raw diffs. Give it semantic understanding of what each person was trying to do.”
That might sound obvious in hindsight. But in the middle of a hackathon, it’s easy to default to “LLM magic.” Hendrik helped us see what the LLM would actually need to succeed and that became the core of our architecture.
Over the course of the hackathon we stayed in contact with Hendrik and also met Erik Thorelli, the Dev Experience Lead at CodeRabbit. We attended their workshop, asked for input multiple times, and kept tightening our ideas based on what we learned.
By the time presentations came around, we were showing something that had been iterated on with real feedback, and we even got the chance to present directly to them because they were so interested in what we were building.
We ended up winning CodeRabbit’s track. The prizes were amazing: Meta AI glasses and a visit to the CodeRabbit office that afternoon.
But the part that stuck with me was the irony. I visited the office as a hackathon prize, and I had no idea I’d be working as an intern in that same office less than three months later.
Our project was called merj (pronounced like “merge,” but slightly wrong on purpose).
Problem: Merge conflicts are one of the most tedious, annoying parts of software development.
They show up at the worst times. They’re hard to reason about from conflict markers alone, and they’re a perfect example of “high friction, low reward” work. You’re not building something new. You’re just trying to get back to building.
So we asked: What if resolving a merge conflict could be as easy as running one command?
The tool was a CLI, and the entry point was simple:
merge pull
Under the hood, it would attempt a normal git pull. If Git complained about a merge conflict, merj would trigger a conflict-resolution workflow.
We designed it that way intentionally. We didn’t want “another AI chat tool.” We wanted something that fit the existing workflow developers already use.
Over that weekend, Hendrik helped us refine our concept so we weren’t relying on “LLM magic.” He showed us how to use CodeRabbit’s semantic summaries as an intent layer, and he was generous with his time answering our questions about how CodeRabbit works and how it could integrate into our project.
Erik’s workshop helped us understand CodeRabbit more deeply so our integration became less hand-wavy and more real.
We kept coming back for feedback, and each time, the project got better.
This is one of the most important lessons I’ve taken away as a junior dev:
Asking for help is a skill. And when you do it well, with momentum and clarity, experienced engineers actually want to help.
A good “ask for help” looks like:
That’s how you turn a sponsor booth conversation into a real connection.
The week after CalHacks, I reached out to Hendrik and Erik asking about potential internship opportunities and whether they could help me navigate the process.
They connected me with David Loker, CodeRabbit’s VP of Applied AI, and we set up an interview, which felt like a continuation of the hackathon:
I received an offer the next day.
I’m not sharing this to flex. I’m sharing it because it highlights something that matters in today’s environment: It’s easier for people to believe in you when you’ve already shown proof of how you think, build, and iterate.
I want to end with concrete advice, because I wish someone had told me this earlier.
Tutorials are fine. But the projects that change your trajectory are the ones with:
Those are the projects that make interviews feel like conversations instead of interrogations.
Don’t wait until it’s “perfect.”
Ask early enough that feedback can change the design.
Respecting someone’s time isn’t about being silent; it’s about being clear.
Show:
“Here’s what I built and what I learned” is memorable.
A generic “please give me a chance” message isn’t.
Interview prep matters, but building impressive things is what gets attention and creates opportunities.
I landed an internship with CodeRabbit because I built something real, asked for help early, iterated fast, and followed up with proof.
And the wild part is that the loop is continuing. The hackathon project that started as a weekend experiment is now becoming a real product initiative I get to work on as an intern.
Don’t just apply harder in isolation if you’re a junior dev trying to stand out in a tough environment. Instead, build something you’re proud of and then get it in front of people who might be interested in it.
