If you haven't read my previous post about the pre-GSoC journey the two months of contributing, the early mornings, the proposal drafts I'd suggest starting there. This post picks up right where that one ended: the proposal had been submitted, the deadline had passed, and there was nothing left to do but wait.
Waiting, as it turns out, is its own kind of difficult.
After the Submission
I hit submit at 11:20 PM on March 31st, ten minutes before the deadline. And then, almost immediately, the adrenaline wore off and a very different feeling took its place.
When you're in the middle of writing a proposal, you have something concrete to do:
- Sections to draft
- Diagrams to make
- Timelines to think through
- Drafts to improve
The work itself keeps the anxiety at a manageable level because you can always channel it into doing something. But the moment the submission is in and there's nothing more you can do to improve your chances, the anxiety has nowhere to go. It just sits there.
I kept contributing to CircuitVerse during the waiting period. Partly because I genuinely wanted to stay involved, and partly because it gave me something productive to do instead of refreshing my email. It was the right instinct. Staying active meant I was still:
- Building context in the codebase
- Building relationships in the community
- Becoming a better contributor regardless of what the outcome would be
But I'm not going to pretend the nervousness wasn't real. It was. Every time I thought about the results, there was a knot of uncertainty that I couldn't quite reason away.
The Message on April 10th
On April 10th, I got a message from one of the mentors.
I had been shortlisted for an interview round.
I remember reading it twice, just to make sure I had understood correctly. Someone had read my proposal and thought it was worth having a conversation about. That felt significant, and it was.
It also meant a whole new category of nervousness had arrived. I had no idea what the interview would look like. Would it be:
- Highly technical — testing my knowledge of the codebase in detail?
- Proposal-focused — asking me to defend my timeline and technical approach?
- Background-focused — asking about my prior contributions and understanding of the project history?
I didn't know, and not knowing made it hard to prepare efficiently. You can't study for an exam when you don't know what subjects it covers.
What I decided to do was prepare for everything.
Three to Four Days of Preparation
I had roughly three to four days between finding out about the interview and actually sitting down to do it. I used all of them.
Here's exactly what I covered:
- Revisited the entire codebase — not just the parts I had contributed to, but the broader architecture: how the different components connected, what the data models looked like, how requests flowed through the system
- Reviewed every contribution I had made since February — not just what the changes were, but why I had made them, what problem each one was solving, what I had learned in the process
- Studied the project history — the previous year's proposals, what had been attempted before, why it hadn't been selected, what the mentors had said they were looking for
- Prepared to be honest about Ruby on Rails — I was still not deeply comfortable with it. Two months of contributing gives you familiarity, but it doesn't make you an expert. I knew which parts I understood well and which parts I had been moving carefully around
Being honest about uncertainty is better than pretending to know something you don't especially when the people you're talking to know the codebase far better than you do.
All the mentors for my project were present in the interview. I found that out when I joined the call and saw all the names. The opening minutes were nerve-wracking. But once the conversation started, it felt less like an interrogation and more like a genuine discussion — which is, I think, exactly what a good technical interview is supposed to feel like.
I came out of it thinking I had done reasonably well. I wasn't certain, but I felt like I had represented my actual understanding accurately.
There Is a Second Round?
A few days later, I got another message.
I had cleared the first round. There would be a second interview — five days later.
My initial reaction was not pure excitement. It was something more complicated.
On one hand:
- I had cleared the first round — the mentors thought the conversation went well enough to continue
- That was genuinely good news
On the other hand:
- I had assumed there would be one interview
- Finding out there was a second one raised the stakes again
- I had let myself feel like the hardest part was behind me — it wasn't
And then there was a very concrete problem: the day after the second interview, I had my compiler design lab exam.
I want to describe this dilemma accurately because I think it's the kind of thing that doesn't get talked about enough when people write about GSoC. The romanticised version of applying is that you pour everything into it and everything else makes way. The real version is that everything else doesn't make way at all.
College keeps happening:
- Exams keep being scheduled
- Assignments keep being due
- Real consequences for your grade don't pause for GSoC
I spent a while genuinely unsure what to do. I couldn't do both properly. Something had to give.
I chose the interview.
I decided it was better to go into the interview focused than to spend the day before it with my attention split between two things. I crammed for the exam after the call. I don't know whether that was the optimal decision in terms of the exam result. But it was the decision I made, and I stand by it.
The Second Interview
I prepared for the second interview much as I had for the first:
- Went back over my contributions
- Reviewed the proposal thoroughly
- Made sure I understood the technical details clearly enough to explain them under pressure
The conversation itself went well. What I'll say is that by the time it ended, I had a sense — not certainty, but a sense — that it had gone the way it needed to go. I had said what I thought, explained my approach clearly, and been honest about the boundaries of what I knew.
And then I waited again.
April 30th
I had been watching the clock on April 30th for most of the evening — not because I was actively anxious, but because I wanted to see it. The official thing. The acceptance letter in the profile. The Google stamp on it.
By the time 11:30 PM arrived, I was in bed, phone in hand, scrolling through Netflix trying to find something to watch. A completely ordinary end to an ordinary evening. I opened my GSoC profile, and there it was.
I cannot sleep when I am that happy. That is just a thing I have learned about myself.
I lay there for what felt like hours with my brain going at full speed — not anxious anymore, just overwhelmed in the best possible sense. I:
- Texted people I probably shouldn't have texted at that hour
- Sent voice notes
- Called someone
- Told everyone who was close to me
The next morning I wrote a long email to all my mentors. I thanked them properly, not just a quick reply for selecting me and for the conversations during the interview process, and I asked about the next steps. Writing that email felt important to do well. It was the beginning of a professional working relationship that was going to last at least three months, and I wanted to start it on the right note.
The Part Nobody Tells You About
There is something that happens after you get selected for GSoC that I don't think people talk about enough.
There is a brief period maybe a day or two where the excitement is so overwhelming that you feel like you could do anything. You are riding an enormous wave of:
- Relief — months of uncertainty finally resolved
- Happiness — the kind that makes you text people at midnight
- Satisfaction — of having worked hard for something and actually gotten it
And then, slowly, the reality of what you've committed to starts to come into focus.
You have:
- Twelve weeks of a coding period
- A specific project with real deliverables
- Mentors who are experienced, thoughtful people paying attention to your progress
- A proposal with your name on it, full of specific claims about what you will accomplish and when
For me, that moment of reality arriving wasn't frightening — but it was sobering in a healthy way. It reminded me that getting selected is the beginning of the work, not the end of it.
The weeks of contributing in February and March, the early mornings, the proposal drafts — those were the audition. The coding period is the actual performance.
I found that realisation motivating rather than deflating, which I think is probably a good sign.
What I Believe About This Process
Looking back at everything — the two months of contributing, the early alarms, the proposal drafts, the two interview rounds, the waiting I want to say something honest about what the GSoC application process actually is.
It is not:
- A competition for the most brilliant developers at the most prestigious universities
- Something that requires a perfect academic record
- Something that requires years of professional experience
What it actually requires:
| Requirement | What it looks like in practice |
|---|---|
| Genuine interest in open source | Showing up even when no one is making you |
| Consistent effort | Contributing every day, even for something small |
| Clear communication | Asking questions, responding to feedback, being honest |
| Technical curiosity | Reading code you didn't write, understanding systems you didn't build |
I was a sixth semester engineering student who had never written a line of Ruby before February of this year. I had no prior experience with the CircuitVerse codebase. I was balancing a full college schedule, internal exams, and assignments throughout the application period. None of that disqualified me.
The process also teaches you things that are genuinely valuable regardless of whether you get selected:
- Reading a real production codebase is a skill you can only build by doing it
- Writing a defensible technical proposal requires a kind of thinking most coursework never asks for
- Building credibility through consistent small actions is a professional skill that transfers directly to the working world
If you are reading this as someone considering whether to apply next year and aren't sure whether you're ready: you probably are. Start contributing now, before the application period opens. The earlier you start, the more comfortable you will be, and the stronger your proposal will be.
The worst possible outcome is that you spend several months learning more than you expected and become a meaningful contributor to a real open source project. That is a genuinely good outcome.
The best outcome is an email that keeps you up all night too happy to sleep.
Next up: the community bonding period, meeting my mentors properly for the first time, and what the next twelve weeks actually look like.
Top comments (0)