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.October: Hackathon chaos to hackathon WIN
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.
What we built at CalHacks: merj, an AI-powered merge conflict resolver
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 user experience
The tool was a CLI, and the entry point was simple:
merge pull
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.
The part that mattered most (and it wasn’t the prize)
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:
- “Here’s the goal.”
- “Here’s what we built so far.”
- “Here’s what isn’t working.”
- “Here are two options we’re debating.”
- “What would you do next?”
That’s how you turn a sponsor booth conversation into a real connection.
The follow-up: How a hackathon turned into an internship
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 thoroughly explained our project architecture.
- We talked about follow-ups and how to improve the product.
- We discussed how it might fit within CodeRabbit’s existing product.
- We went deeper on technical choices and failure modes.
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.
Practical advice for junior devs (what I’d do again)
I want to end with concrete advice, because I wish someone had told me this earlier.
1. Build things that force real engineering decisions
Tutorials are fine. But the projects that change your trajectory are the ones with:
- Constraints
- Tradeoffs
- Failure modes
- Real integration points
Those are the projects that make interviews feel like conversations instead of interrogations.
2. Ask for help while you’re still building
Don’t wait until it’s “perfect.”
Ask early enough that feedback can change the design.
3. Make your ask easy to answer
Respecting someone’s time isn’t about being silent; it’s about being clear.
Show:
- What you tried
- What broke
- What you think is happening
- What kind of feedback you want
4. Follow up with proof, not desperation
“Here’s what I built and what I learned” is memorable.
A generic “please give me a chance” message isn’t.
5. LeetCode can help you pass gates. Building creates doors.
Interview prep matters, but building impressive things is what gets attention and creates opportunities.
The bottom line
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.
