DEV Community: Akanksha Trehun

Getting Selected — The Night I Couldn't Sleep

Akanksha Trehun — Tue, 12 May 2026 04:37:40 +0000

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.

Pre GSoC — Finding My Way to CircuitVerse

Akanksha Trehun — Wed, 06 May 2026 18:51:19 +0000

This post is going to be a long one. I figured if I'm going to write about the two months that led up to my GSoC selection, I should do it properly the whole thing, from the very beginning, not just the highlights. So grab a coffee, get comfortable, and let's go back to where this story actually starts.

A Classroom Demo I Never Forgot

The first time I heard the name CircuitVerse, I was sitting in a Digital Principles of Design class in my third semester. I'm currently in my sixth semester, so that's about a year and a half ago now. It wasn't a big moment. It wasn't even really part of the class.

Our faculty and I'm genuinely grateful to her for this had pulled up CircuitVerse on the projector one day just to show us something. It wasn't in the syllabus. It wasn't going to be on the exam. She just wanted us to see what it actually looked like when the circuits we were drawing on paper came to life on a screen. We were studying:

Half adders and full adders
JK flip flops
Foundational digital logic that you spend your first years drawing on paper or building with actual wires on a breadboard

She simulated a few circuits in front of us, walked us through how the inputs and outputs worked, showed us how you could change values and watch the circuit respond in real time. It was maybe twenty minutes of a single class period. And then we moved on.

But I remember thinking even then, as a third semester student still getting used to the pace of engineering college that this was a really interesting platform. There was something satisfying about seeing the logic work visually, in real time, without needing physical components. I didn't do anything with that thought at the time. I just filed it away somewhere.

That's where it started. One classroom demo that I technically didn't need to pay close attention to.

Why This Year

Fast forward to the beginning of this year. I'm in my sixth semester, roughly halfway through my degree, and I had been thinking about GSoC for a while not in a serious, planned out way, but in the background. I knew what it was. I knew it was something I wanted to try. I just hadn't pulled the trigger.

This year felt different. I had a feeling and I think a lot of students who've gone through this will understand it that if I kept waiting for the perfect time, the perfect time was never going to arrive. There is always:

An exam
A project due
Some reasonable-sounding reason to push it to next semester

And at some point, next semester becomes next year, and next year becomes too late.

I'm in sixth semester. If I didn't apply this year, I'd have my seventh and then my final eighth semester, and by then everything gets consumed by placements and final year projects. The window felt like right now, not later.

So when the 2026 GSoC organisations were announced and I saw CircuitVerse on the list, something clicked immediately. I already had that memory of it from third sem. I'd always had a genuine interest in circuits and digital logic it goes back further than that DPD class, actually, all the way to eleventh and twelfth grade in school, where I first encountered electronics properly. It was one of those subjects that made sense to me intuitively in a way that not everything does.

And I thought: I know what this platform is, I care about what it does, and I can try. So I did.

Starting From Zero

I want to be honest about where I was when I started contributing to CircuitVerse in February. I was not a well-prepared, experienced open source developer who had been waiting for the right organisation. I had contributed to a few other open source programmes before, so I wasn't completely new to pull requests, issues, and code review. But CircuitVerse specifically? I was starting from scratch.

And the first thing I ran into was the codebase itself.

CircuitVerse runs on Ruby on Rails. For those unfamiliar:

Ruby on Rails is a web application framework built on the Ruby programming language
It has its own conventions, its own file structure, its own way of thinking about problems
It is absolutely not part of the curriculum at my college

I had never written a line of Ruby before February. I had never built anything in Rails. Both the language and the framework were entirely new to me.

The codebase is also large. This is not a small hobby project — CircuitVerse is a platform used by students and educators all over the world, and the code reflects years of development from many different contributors.

The first time I cloned the repository and opened it, I felt genuinely lost. Not discouraged — but lost.

So I did what you do when you're lost. I started from the very beginning:

Watched Ruby on Rails tutorials and beginner walkthroughs on YouTube
Read the official Rails documentation
Read the CircuitVerse contribution guides and developer documentation
Spent time building a mental map of how the whole thing fit together before I tried to change any of it

Did I fully understand it after a week? No. But I understood enough to start, and that's all you actually need.

The Rule I Set For Myself

From February onward, consistency became my only rule.

It might sound simple, but it is genuinely harder than it sounds. When you are trying to break into a large open source project as an outsider, the temptation is to wait until you feel ready...until you understand enough to make something meaningful. But that moment of feeling ready never comes on its own. There is no threshold you cross where the codebase suddenly makes sense. You only get there by actually working in it, making mistakes, getting feedback, and going again.

"The journey of a thousand miles begins with a single step" — and in open source, that first step is almost always smaller and more unglamorous than you expect.

So I started small:

Documentation fixes — correcting things that were incomplete or inaccurate
Updating tests — fixing outdated test cases that no longer reflected the current code
Small bug fixes — low-risk contributions that didn't require deep knowledge of the whole system

Not glamorous work, but important work, the kind of work that keeps a codebase healthy and maintainable. More importantly, it got me reading the code every single day, building familiarity one small piece at a time.

I worked hard at it not in the sense of grinding through long sleepless nights, but in the quieter and more demanding sense of showing up without exception. Even on the days when I was tired. Even when the progress felt invisible. Even when I wasn't sure what I was doing was making any difference.

Some days I made several contributions. Some days I barely scraped through with one small fix. But the consistency mattered far more than the volume on any given day. Showing up every day, even for something modest, built a habit. And habits compound in ways that occasional bursts of effort simply do not.

Over the weeks, I started to feel the codebase becoming familiar. I began recognising file names, understanding what different directories were responsible for, knowing where to look when I encountered something I didn't understand. The codebase had not changed. I had just spent enough time in it that it stopped feeling foreign — and that shift, slow and quiet as it was, turned out to be everything.

The Saturday Meetings

CircuitVerse has weekly community meetings every Saturday, and I made it a rule to attend as many of them as I could. The only real exceptions were when I had an exam on Monday, and even then I'd try to go over what had been discussed afterwards.

I want to say clearly: these meetings were more valuable than I expected when I first started attending.

When you're a new contributor reading a codebase alone, you get a limited picture of the project. You see the code, but you don't necessarily understand:

The priorities and ongoing discussions
What the maintainers are excited about
What's been tried and abandoned
What's coming next

The meetings gave me that layer of context that you simply can't get from reading files alone. They also gave me a sense of how the community operated how decisions got made, how contributors communicated, how to bring up a question without sounding like you hadn't done your homework. These things aren't written in any documentation. They're things you absorb from being present over time.

Gradually, I started feeling less like an outsider submitting pull requests into the void and more like someone who actually belonged in the community, at least in a small way. That shift matters more than it might seem.

Growing Into Bigger Contributions

As February turned into March, I started feeling more confident. The codebase was familiar enough that I could look for more substantial issues:

Actual bugs that needed fixing
Missing features that were clearly needed
Things that needed real work rather than just documentation updates

I started creating my own issues rather than only picking up ones that were already listed. I also reached out to the mentors for the specific project I was interested in. This felt more nerve wracking than it probably should have... there's an intimidation factor around directly contacting experienced maintainers when you're a new contributor.

But I sent the messages, asked the questions, and the mentors were approachable. They replied, pointed me toward relevant parts of the codebase, gave feedback on my pull requests. I want to acknowledge that, because I think the attitude of a project's maintainers has a huge influence on whether new contributors stick around or quietly disappear.

Feeling like your questions are welcome makes an enormous difference when you're just starting out.

Deciding It Was Time to Write

At some point in early March I made a call: I have enough now. It's time to start writing the proposal.

I want to be clear about what "enough" meant. It didn't mean:

I had mastered the codebase
I had become an indispensable contributor
I felt completely ready

It did mean:

I had enough familiarity with the project
I had enough presence in the community
I understood what needed to be built well enough to write something credible

Before I wrote anything of my own, I spent time reading. The project I was applying for had been proposed the previous year and hadn't been selected I don't know exactly why, but it meant there was history to learn from. I read:

Proposals from people who had worked on CircuitVerse in previous GSoC cycles
Older ideas pages and discussions
Notes about what had been built and what was still outstanding

That research took days. But it was the most important preparation I did, because it meant that when I started writing, I wasn't guessing at what the organisation wanted. I had evidence.

Seven Drafts, Maybe Ten

I wrote somewhere between seven and ten drafts of my proposal. I lost count after a while.

I kept going back to it. The cycle looked something like this:

Write a section
Read it the next morning
Decide it wasn't clear enough
Rewrite it entirely
Add diagrams → delete diagrams → add them back in a cleaner form
Restructure the timeline
Rewrite the problem statement
Change the order of sections → change it back

The hardest section, without question, was the timeline.

In college, someone gives you a deadline and you work toward it. You're not usually asked to commit, in writing, to what you will accomplish in each specific week of the next three months. GSoC asks you to do exactly that — to look at twelve weeks and say with real specificity what will be done by the end of week one, two, three, all the way through.

In my case, there was an additional layer of complexity — I had to account for my college schedule, which I can't fully predict:

Internal exam dates aren't announced at the beginning of the semester
Assignment deadlines shift based on faculty schedules
Lab work takes unpredictable amounts of time

I had to build buffer into my timeline without making it look like I was padding. I spent more hours on that timeline than on any other part of the proposal.

The second hardest section was the problem and solution where you show that you actually understand what you're proposing to build, not at a surface level, but in real technical depth.

Five Forty-Five AM

All of this was happening while I was attending college, sitting internal exams, completing assignments, and trying to maintain some kind of normal student life.

The time I found was in the mornings.

I started setting my alarm for 5:45 AM and trying to be up by six. That gave me an hour to an hour and a half before I had to think about anything else before college, before messages, before the day's demands started stacking up.

It doesn't sound like much. But when that's the only truly quiet time available in a given day, you make the most of it. And over six or seven weeks, those morning sessions added up to something real.

There were mornings when the alarm went off and getting out of bed took everything I had. Days when I sat at my desk with coffee going cold and the proposal open and nothing useful in my head. But I showed up anyway, did what I could, and went to college. And slowly the drafts got better.

Submitting

I was late submitting my proposal for mentor review, which meant I didn't get as much feedback as I'd wanted. I got some — one mentor gave me genuinely useful notes that I was able to implement... but I wish I'd started the review process earlier.

If there's one piece of advice I'd give to anyone applying next year: send your draft to the mentors at least two weeks before the deadline. You need enough time to actually act on the feedback, not just read it.

The final deadline was March 31st, 11:30 PM IST. I submitted at 11:20 PM.

Ten minutes to spare. I'm not recommending this approach.

I was proud of what I submitted though. It was specific, honest, reflected months of work, and was genuinely mine in a way that felt important. And then there was nothing left to do but wait.

What This Process Actually Is

I want to end this post with something I believe is genuinely truemnot just something people say to make those who weren't selected feel better.

The pre-GSoC period teaches you things that cannot be learned any other way:

Skill	Where you learn it
Reading a real-world codebase	By actually working in one
Writing a credible technical proposal	By writing seven drafts and rewriting them
Consistent community contribution	By showing up every single day
Professional communication	By reaching out to maintainers and getting feedback

GSoC is not a competition for the most brilliant students at the best universities. It is an opportunity for anyone who is genuinely interested in open source and willing to put in consistent, honest work.

I was a sixth semester student who had never written Ruby before February. I didn't have a polished portfolio or a list of impressive prior projects. I just kept showing up every day and tried to get a little better.

If you're reading this and considering whether to apply next year — start now. Not next month. Now. The earlier you start contributing, the more comfortable you'll be with the codebase by the time the proposal period opens. And even if you don't get selected the first time, the work you do in the process is real and valuable in itself.

In the next post: what happened after the submission the shortlist, rounds of interviews, and the night I found out I got in.