DEV Community: Sumit Tiwari

Raat Ka RJ: An Interactive Audio Microdrama – You Decide What Dev Does Next

Sumit Tiwari — Fri, 13 Nov 2026 10:41:05 +0000

Raat Ka RJ: An Interactive Audio Microdrama – You Decide What Dev Does Next

An interactive microdrama | 3 choices, 4 endings | Estimated reading time: 5–8 minutes

What if someone sent you a voice note every night at exactly 1:47 AM, but never said a single word?

Would you ignore it, investigate it, or listen closely enough to discover what it was trying to tell you?

I normally write about code, open source, and development. This time, I wanted to experiment with something different: a story where the reader doesn't just follow the plot but actually makes decisions that change how it ends.

The idea came from my interest in radio and the people who stay awake at night listening to voices they've never met.

I've also built UP Radio, a radio app featuring live Uttar Pradesh stations. While working on it, I kept thinking about the connection between a radio host and someone listening on the other side.

That thought became Raat Ka RJ.

This is not a story where you simply scroll from beginning to end. You have choices to make, clues to notice, and different endings to discover.

How to read this story: At every choice, click an option to reveal what happens. Some options lead to dead ends. One path reaches the true ending. Read carefully, because every sound is a clue.

Characters

Dev (21): A nervous night RJ at a small campus community radio station, 91.2 FM. His voice shakes whenever he thinks someone is listening.
The Listener: An unknown person who sends one voice note every night at 1:47 AM.
Bilal (14): A young boy who appears near the end of the story.
Khan Saheb: A former radio presenter whose voice has been missing for a long time.

Episode 1: 1:47 AM

A tiny radio studio. Foam panels on the walls. One microphone. A red ON AIR light. The clock reads 1:46 AM.

Dev is alone.

Nobody usually listens to a campus radio show at this hour.

The streaming dashboard says:

3 listeners.

Sound: A quiet hum from the old mixer.

DEV (into the microphone, nervously): Aap sun rahe hain Raat Ka RJ, 91.2 FM. Main hoon Dev. Agar aap jaag rahe hain, toh iska matlab hai ki aap bhi kisi baat ka intezaar kar rahe hain.

At exactly 1:47 AM, his phone buzzes.

A message on the request line.

A voice note. Six seconds long.

No words.

Sound: A ceiling fan turning. A pressure cooker whistle in the distance. And underneath it, something rhythmic: someone tapping slowly on a wooden surface.

Dha, ge, na, ti, na, ka, dhi, na.

Then a text message appears:

"Woh purana gaana laga do. – Ek Shrota"

Dev opens the chat.

The same number has sent this message every night for eleven consecutive nights, always at 1:47 AM.

He has never replied.

He doesn't know which old song the listener means.

The voice note is still playing in his headphones.

For some reason, his chest feels tight.

🎧 Choice 1: What does Dev do?

🅰️ Play a regular song and ignore the message

Dev shrugs, queues a regular song, and finishes the show at 2:00 AM.

The next night, 1:47 AM arrives.

His phone stays silent.

No fan. No cooker. No tapping.

Dev stares at the screen for ten minutes.

The night after that, the same silence.

The number is still saved, but it never sends another message.

Ending 0: The Silence

Some messages only come once. Go back and choose B.

🅱️ Replay the voice note and listen carefully

Dev puts on his headphones again.

This time, he turns down the background music and listens to every second.

Continue to Episode 2 below.

Episode 2: The Rhythm

Dev replays the voice note. Again. And again.

Sound: Fan. Pressure cooker whistle. Eight beats of tapping. Then, at the end, something almost impossible to hear: an old man's breath.

Dev leans closer.

DEV (whispering to himself): Yeh koi gaana baja raha hai. Ungli se. Bed ke frame pe.

He recognises the pattern.

An eight-beat rhythm. The kind of rhythm that old film songs often use.

But he cannot identify the song.

His phone is still open.

He has two options.

He can investigate the number, or he can search the radio station's old archive: a dusty steel cabinet full of cassettes that has been locked since before he joined.

🎧 Choice 2: Where does Dev look?

🅰️ Trace the number

Dev checks the number against the station's caller log.

A name appears on the messaging profile:

Bilal.

No photograph. No address. No other information.

He sends a message:

"Aap kaun?"

Two blue ticks.

No reply.

Dev now has a name, but nothing that explains the mysterious voice notes.

He looks at the clock.

1:52 AM.

The trail has gone cold.

Ending 1: Half an Answer

A name isn't a person. Go back and choose B.

🅱️ Open the old archive cabinet

Dev remembers seeing an old cabinet behind the studio door.

He decides to investigate.

Continue to Episode 3 below.

Episode 3: The Cassette

The cabinet key hangs on a nail behind the door, under a layer of dust.

The lock groans.

Inside are forty old cassettes, each with a handwritten label.

One catches Dev's attention:

"Raat Ka Saathi, 1991. Khan."

He slides it into the old cassette player.

A hiss.

Then a voice.

Deep, warm, unhurried. A voice that sounds like it was made for radio.

KHAN (1991 RECORDING):

Yeh Akashvani ka Lucknow kendra hai. Raat ke do bajne wale hain. Agar aap abhi tak jaag rahe hain, toh main aapke saath hoon. Aaj ki raat ka aakhri gaana, sirf aapke liye.

A song begins.

Raat Ka Musafir.

Old. Gentle. Built around the same eight-beat rhythm.

Dev presses pause.

His hands are shaking.

DEV (whispering): Yeh wahi hai. Woh isi gaane ke liye ungli bajate hain.

He looks at the clock.

1:31 AM.

In sixteen minutes, the mysterious voice note will arrive again.

He rewinds the cassette.

At the end of the recording, Khan repeats a familiar sign-off.

The same words.

The same rhythm.

The same voice.

Dev begins to wonder whether someone has been waiting for that sign-off for thirty-five years.

🎧 Choice 3: What does Dev do on air tonight?

🅰️ Play the song and say nothing

At 1:47 AM, Dev plays Raat Ka Musafir.

No words. No introduction.

The song fills the studio.

Somewhere across the city, a phone buzzes.

Another voice note arrives.

The fan. The cooker. The tapping.

This time, the rhythm is a little steadier.

Then nothing.

Dev smiles, relieved, and ends the show.

Ending 2: The Song

It was kind, but the listener wasn't waiting only for the song. Go back and choose B for the true ending.

🅱️ Play the song, then say the old sign-off on air

Dev looks at the microphone.

He takes a breath.

He has never repeated someone else's words on air before.

But tonight feels different.

Continue to Episode 4 below.

Episode 4: Yeh Akashvani Hai

1:46 AM. Dev adjusts the microphone.

His hands are cold.

For the first time, he doesn't look at the streaming dashboard.

He looks at the clock.

DEV (into the microphone, steady for the first time): Raat ke do bajne wale hain. Agar aap jaag rahe hain, toh yeh gaana sirf aapke liye.

He presses play.

Raat Ka Musafir fills the studio.

Sound: The old eight-beat rhythm. Soft. Familiar.

The song ends.

A moment of silence.

DEV (slowly): Yeh Akashvani ka Lucknow kendra hai.

He stops.

He doesn't know whether he is allowed to repeat those words.

Then he continues.

DEV: Raat ke do bajne wale hain. Aap abhi tak jaag rahe hain, toh main aapke saath hoon.

The red ON AIR light stays on.

For ten seconds, nothing happens.

Then his phone buzzes.

A voice note.

Twenty seconds long.

Sound: A boy's voice. Young. Breathless.

BILAL (voice note):

Bhaiya... Dadu ne suna.

Woh bol nahi sakte. Operation ke baad unki awaaz bahut kam ho gayi thi.

Lekin jab bhi 1:47 bajte hain, woh mujhse phone uthake kamre ki awaaz record karne ko kehte hain.

Woh kehte hain, "Dev sun lega."

Sound: A pressure cooker whistle. The fan. And then the tapping begins.

The eight-beat rhythm.

Steady.

Joyful.

A pause.

Then, from very close to the phone, a rasping, broken whisper.

An old man, speaking for the first time in a year.

KHAN SAHEB (hoarse, barely audible):

"...Yeh... Akashvani... hai."

The tapping continues.

Then it stops.

Dev presses his hand over his mouth.

For several seconds, he cannot speak.

Then he leans into the microphone.

DEV (voice cracking, smiling): Khan Saheb... shukriya. Raat abhi baaki hai.

Sound: The song begins again, softly, underneath his voice.

ON SCREEN:

Some voices never fade. They wait for the right ear.

Ending 3: The True Ending

Why I Wrote It This Way

I wanted to experiment with a format where the reader doesn't just read a mystery but actively participates in solving it.

Here are five creative decisions that shaped the story:

Audio-first storytelling: Every important clue is a sound: a fan, a cooker, a tapped rhythm, and a breath. The story is designed to work even with the screen off.
A mystery the reader can solve: Dev hears the same rhythm as the reader. Instead of explaining everything immediately, I wanted readers to notice the clues themselves.
Choices that change the emotion: Playing the song is an act of kindness. Repeating the old sign-off takes courage. The important choice is not just about what happens next, but about whether Dev is willing to connect with someone he has never met.
Dead ends that still tell a story: Every wrong option has its own ending. Readers aren't simply told they made a mistake; they discover what happens when Dev chooses a different path.
One whisper as the payoff: The entire story builds towards a single line from a man who can barely speak. I wanted a small, quiet moment to carry more emotion than a dramatic twist.

For me, the interesting part was making the reader listen carefully, follow the clues, and feel that their decisions matter.

How I Used AI to Write This Story

This story didn't begin with an AI prompt. It started with an idea, a pen, paper, and brainstorming.

Tools: Claude, ChatGPT, and Google Search.
My process: I first brainstormed the concept on paper and thought about the setting, characters, sounds, and possible endings. Once I had a rough direction, I used Claude and ChatGPT to help organize my ideas into an interactive storyline, structure the branching choices, improve the wording, and explore different dialogue variations. I also used Google Search to explore relevant references and check technical and contextual details.
What worked: AI helped me turn scattered ideas into a structured story with multiple paths and endings. It was particularly useful for exploring different possibilities, organizing the choices, improving transitions, and checking whether the reader could follow the story without getting lost.
What didn't: The first versions felt too much like ordinary scripted stories. Some dialogue was overly polished, and some explanations revealed too much instead of allowing the mystery to develop naturally. I wanted readers to feel curious, notice the sounds, and discover the truth themselves. So I reworked the scenes, simplified the dialogue, added more pauses and sound-based clues, and made the choices more meaningful.

One of the biggest lessons for me was that an interactive story is not just about giving readers multiple options. Every option should reveal something, change an emotion, or make the reader think differently.

The idea started with me. AI helped me structure and refine it. The final creative decisions were mine.

Your Turn

Which ending did you reach first?

The Silence
Half an Answer
The Song
The True Ending

And here's a question:

If you were Dev, would you have repeated Khan Saheb's sign-off without knowing who was listening?

Tell me your choice and why in the comments.

If enough readers are interested, I'll write Part 2:

What happens to Bilal after that night?

About Me

I'm Sumit Tiwari, a frontend developer, open-source contributor, and writer from Pune, India.

I enjoy building web applications, contributing to open source, exploring new technologies, and experimenting with creative storytelling.

GitHub: sumittiwari1302
LinkedIn: Sumit Tiwari
DEV Community: @sumit_tiwari_85f93699c3a7
Instagram: @sumittiwari8259

This is a work of fiction. All characters, stations, and events are fictional. Any resemblance to real persons or events is coincidental.

From My First Open-Source Contribution to Rank 46 in ECSoC’26

Sumit Tiwari — Fri, 30 Oct 2026 11:08:47 +0000

How I achieved Rank 46 in ECSoC’26 through consistent open-source contributions, mentorship, and hands-on learning.

Sumit Tiwari · B.Tech CSE Student at PW IOI Pune

ECSoC’26 Achievement: Rank 46 · 98 Merged Pull Requests · 14 Projects · 35-Day GitHub Contribution Streak

About me

I am Sumit Tiwari, a second-year B.Tech Computer Science and Engineering student at PW IOI Pune, interested in software development and open-source collaboration.

My journey through the European Summer of Code–style open-source program, ECSoC Elite Summer of Code 2026, culminated in securing Rank 46 among approximately 13,000 participants, with 822 active contributors.

Throughout the program, I achieved 98 merged pull requests across 14 projects and maintained a 35-day GitHub contribution streak.

These results came from a process of continuous learning. I began by developing my understanding of collaborative software development during my first internship. I then explored open source, learned how to contribute to established repositories, and gradually became more confident working with real-world codebases.

This is the story of that journey, the people who helped me along the way, and the lessons I will carry into my future as a software developer.

1. Where it started: My first internship at PW LeapX

My introduction to collaborative software development began with my first internship as a Frontend Developer at PW LeapX.

Before the internship, most of my experience came from learning programming concepts and building projects. Working with a team introduced me to the practical side of software development.

I learned how developers use Git and GitHub to manage changes, create branches, submit pull requests, and collaborate on shared codebases. I also gained experience building responsive user interfaces and working within an established development workflow.

One of the most important lessons was understanding that contributing to a software project requires more than writing code. You need to understand the requirements, respect existing conventions, communicate with your teammates, and make changes that fit the project.

That experience sparked my interest in contributing to projects beyond my own work.

I began exploring open-source programs, including GirlScript Summer of Code, with the goal of eventually becoming an active contributor.

At the time, I understood the basics of development workflows, but I had yet to experience the complete process of contributing to projects maintained by an external community.

2. Discovering ECSoC’26

I discovered ECSoC Elite Summer of Code 2026 while browsing LinkedIn.

The opportunity to work on real projects, learn from experienced developers, and contribute to open-source communities immediately interested me. I registered for the program, looking forward to applying what I had learned.

However, I quickly realised that knowing Git and GitHub was only the starting point.

I needed to understand how to identify suitable repositories, select issues, communicate with maintainers, follow contribution guidelines, and prepare pull requests that met a project's requirements.

Even simple questions could be challenging at first. Which issue should I work on? How should I approach a maintainer? What should I do when I encounter an unfamiliar part of a codebase?

I realised that becoming an effective open-source contributor required practical experience and a willingness to learn independently.

Rather than treating these challenges as reasons to wait, I began looking for ways to understand the process and get involved.

3. Learning through the PW IOI open-source initiative

Around the same time, PW IOI introduced an initiative to help students explore open source and contribute to real-world projects.

With guidance from Abhinav Awasthi Sir and Aaksh Meruva Sir, I developed a better understanding of how open-source communities operate.

I learned how to explore repositories, understand project documentation, identify appropriate issues, communicate with maintainers, and follow the pull request workflow.

Their guidance helped me connect what I already knew about development tools with the practical steps required to contribute to an existing project.

I began exploring repositories independently, reading their code, and identifying issues that matched my current skills while giving me opportunities to learn something new.

This changed my approach to learning software development. Instead of waiting until I felt completely prepared, I started working on real problems and learning from the process.

4. My first merged pull request

My first merged pull request was an important milestone because it gave me my first real experience of contributing to a project maintained by other developers.

While exploring a repository, I found an issue I believed I could solve. I commented on it, received the assignment, and started working on the implementation.

After submitting my pull request, I waited to see whether the maintainer would accept my changes.

Since this was my first contribution, I was naturally uncertain about the outcome. I wanted to know whether my solution met the project's requirements and whether I had approached the problem correctly.

My pull request was merged just one day later.

That experience gave me the confidence to continue contributing.

It showed me how an individual contribution, even a small one, could become part of a larger project. It also helped me understand the value of carefully reading an issue, working within an existing codebase, and following the project's contribution process.

After that first merge, I started approaching open source differently. I became more willing to explore unfamiliar repositories, investigate problems, and learn through implementation and review.

My first merged pull request did not make me an expert, but it gave me a reason to keep improving.

5. Building consistency across open-source projects

Throughout July and August 2026, I continued contributing to open-source projects and became increasingly comfortable with collaborative development.

Each repository introduced its own structure, conventions, and expectations. Understanding an unfamiliar codebase often required reading documentation, tracing existing implementations, investigating related files, and testing potential solutions.

Not every issue was straightforward, and progress was not always immediate. Balancing contributions with my academic responsibilities also required planning and discipline.

I continued working through these challenges, treating each issue as an opportunity to improve my understanding of software development.

During this period, I maintained a 35-day GitHub contribution streak.

The streak reflected my effort to stay engaged with development consistently. Some contributions involved more investigation than implementation, while others required me to understand an existing feature before making a change.

Over time, I became more comfortable navigating repositories, debugging code, following project conventions, and responding to feedback from maintainers.

I also developed a better appreciation for code review. A pull request is not simply a submission; it is part of a collaborative process in which the solution can be examined, discussed, and improved.

These experiences helped me develop a more systematic approach to solving problems.

6. ECSoC’26 results and achievements

My efforts culminated in securing Rank 46 in ECSoC Elite Summer of Code 2026.

The program had approximately 13,000 participants, including 822 active contributors.

My achievements during the program were:

Metric	Achievement
Final ECSoC’26 rank	46
Approximate program participants	13,000
Active contributors	822
Merged pull requests	98
Projects contributed to	14
GitHub contribution streak	35 days

Each milestone represents a different part of my experience, from exploring repositories and understanding issues to submitting contributions and learning through code reviews.

Securing Rank 46 is an achievement I am proud of, particularly because I began the journey with limited practical experience in open-source contribution workflows.

The progress I made throughout the program strengthened my confidence in working with unfamiliar codebases and collaborating with developers outside my immediate academic environment.

I see this ranking as a milestone in my development journey and a foundation for the work I want to do next.

Explore my ECSoC’26 journey:

7. Recognition from PW IOI

One of the highlights of this journey was having my achievement featured on the PW IOI Instagram page.

For me, this recognition was an encouraging reminder of the value of practical learning and participation in open-source communities.

As a student, I believe opportunities to work on real-world projects are an important part of developing engineering skills. Experiences like ECSoC’26 help students apply what they learn, understand collaborative development, and discover areas in which they want to grow.

I appreciate PW IOI for encouraging students to pursue these opportunities and for supporting learning beyond the classroom.

You can view the feature here:

View my ECSoC’26 feature on PW IOI's Instagram

Visit the official PW IOI website

I hope sharing my experience encourages other students to explore open source and take their first steps towards contributing to projects.

8. What I learned from ECSoC’26

The most valuable part of ECSoC’26 was the practical experience I gained throughout the program.

Understanding existing codebases

Contributing to an established project requires understanding its structure and existing implementation before making changes. I learned to spend time investigating a problem rather than immediately jumping into the code.

Learning through code review

Feedback from maintainers is an important part of collaborative development. Reviews help contributors understand project expectations and improve their solutions.

Staying consistent

Maintaining a contribution streak taught me the value of regular effort. Progress can be gradual, especially when working on unfamiliar problems, but continued practice builds experience.

Communicating with maintainers

Open-source development involves collaboration. Clear communication, thoughtful issue discussions, and following contribution guidelines help contributors work more effectively with project communities.

Becoming comfortable with unfamiliar problems

Not every issue matches something you have already learned. I became more comfortable researching unfamiliar concepts, exploring existing implementations, and working towards a solution step by step.

These lessons have influenced how I approach software development, and I intend to continue applying them to future projects.

9. Looking ahead

As a second-year B.Tech Computer Science and Engineering student at PW IOI Pune, I want to build on the foundation I developed through ECSoC’26.

My focus is on contributing to more open-source projects, taking on technically challenging issues, and strengthening my understanding of software engineering practices.

I also want to continue learning from experienced developers and collaborating with communities that build and maintain useful software.

Open source has given me a practical way to apply my knowledge, learn from feedback, and work on problems beyond the scope of my individual projects.

I look forward to continuing this journey, building better software, and making meaningful contributions to the developer community.

Acknowledgements

I would like to express my sincere gratitude to Abhinav Awasthi Sir and Aaksh Meruva Sir for their guidance and for helping students understand the practical aspects of open-source development.

I am also thankful to PW IOI for encouraging students to explore opportunities beyond the classroom.

My appreciation goes to the ECSoC’26 community, the maintainers who reviewed my contributions, and the developers whose projects provided opportunities to learn and collaborate.

Every issue I worked on and every review I received contributed to my growth throughout this experience.

Final thoughts

When I first explored open source, I was still learning how to identify issues, work with unfamiliar repositories, and submit contributions that met project requirements.

By the end of ECSoC’26, I had achieved 98 merged pull requests across 14 projects, maintained a 35-day GitHub contribution streak, and secured Rank 46.

I am proud of these results, but I value the experience behind them just as much. The journey helped me become more confident in approaching unfamiliar problems and gave me a clearer understanding of collaborative software development.

I am still learning, and there is much more I want to explore.

If there is one lesson I would share with students considering open source, it is this: start with what you know, be willing to learn what you don't, and give yourself the opportunity to improve through practice.

My ECSoC’26 journey is one milestone in a much longer path, and I look forward to what comes next.

Connect with me

I enjoy connecting with developers, students, and open-source contributors who are interested in learning, building projects, and collaborating with the community.

GitHub: github.com/sumittiwari1302
LinkedIn: linkedin.com/in/sumit-tiwari-b18701380
Instagram: @sumittiwari8259
ECSoC’26 Profile: View my contributor profile

Thank you for reading about my journey.

#ECSoC26 #OpenSource #GitHub #SoftwareEngineering #PWIOI #StudentDeveloper #OpenSourceContribution

From Zero to Production: How I Shipped Responsive UIs During My Frontend Internship

Sumit Tiwari — Wed, 21 Oct 2026 12:16:20 +0000

Through my entire first semester of BTech, I didn't really know what I was doing.

I'm Sumit, a student at PW IOI, a new-generation college. Nobody around me had a clear picture of how the industry worked, and neither did I. It took me time to understand what companies expect from a developer and what I needed to learn to get there.

A few months later, I was working in an 11-person team, reading product requirement documents, reporting in daily scrum calls, and building responsive UIs in HTML, CSS and JavaScript on two-week deadlines.

This post is about how that happened, what the internship was like day to day, and what I learned that no tutorial taught me. If you're a student who feels behind or lost, I wrote it mainly for you.

Why the first semester felt so confusing

PW IOI Pune is a new-generation college, so there isn’t a long line of seniors to guide you on what to learn, what to focus on, or what to avoid. During my first semester, I often felt unsure about how the tech industry worked, which skills I needed to develop, and where to start.

I could follow lectures and finish assignments, but I couldn't answer basic questions: What does a developer actually do all day? How do teams build software together? What would a company expect me to know on day one? Without answers to those, it was hard to know what to practise.

If you're a first-year student feeling the same way, that's normal. For me, the confusion didn't go away because I studied harder. It went away when I met someone who could show me the path.

The turning point: finding PW LeapX

In February, I heard about PW LeapX.

PW LeapX is a program associated with PW IOI where students work on real-world projects in teams. For me, that meant building real projects with mentor guidance, working alongside other interns, and learning how a development team actually operates.

The hiring process hadn't started yet, so I used that gap to prepare properly instead of waiting. My interview was in mid-March, and I was selected as a frontend developer. I'm grateful to the two people who guided me through this stage.

Lesson: preparation before an opportunity opens counts. I wasn't ready in February, but I had a few weeks to get ready before the interviews started, and those weeks made the difference.

How the internship worked

The internship began in May 2026 and ran for about three months. We worked under mentors, who guided us through the projects and the daily scrum calls.

The structure looked like this:

Real-world projects. We weren't given toy exercises. Each project came as a real brief.
The PRD comes first. A product requirement document (PRD) was prepared for every project, and each intern (developer) had to read it before building.
Two weeks per project. Each project had a two-week window, and we had to deliver properly within it.
A team of 11. Eleven interns worked on one project together, so coordination mattered as much as code.
Daily scrum at 4 PM. Monday to Friday, we had a scrum call with our mentors.

Starting with the PRD

A PRD describes what a product should do and who it's for. Documents like this usually cover the goal of the project, the features required, and what counts as done.

Reading it properly before writing code sounds obvious, but it matters. When 11 people read the same document, everyone builds toward the same target. When someone skims it, you find out later, usually when two people's work doesn't fit together.

What happens in a scrum call

A scrum is a short, regular check-in. In ours, each of us explained what we had done the day before. If we were stuck, the mentors guided us right there.

This sounds simple, but it changed how I work:

You can't hide when you're stuck. You have to say it, and then you get unstuck faster.
You learn to summarize your work clearly and briefly, instead of rambling about everything you touched.
You learn how to report to seniors professionally, which isn't something you pick up from coding videos.
You see how other people are approaching their parts, which shows you problems before you hit them.

What we built

Our stack was HTML, CSS and JavaScript. Our team's GitHub organisation, LeapX-Pune, holds a set of public projects that gives a good picture of the kind of work we did:

A gym/club membership dashboard designed to work on desktop, tablet and mobile.
A product catalogue with search, filters, a cart and a validated checkout form.
Event listing and registration platforms with filtering, and an admin dashboard in one of them.
Kanban-style project management boards, including a Trello-style one with drag-and-drop.
A weather and news dashboard with separate JavaScript modules for weather, news and UI.
A student progress tracker.

Looking at that list, the pattern is clear. These projects aren't about fancy tools. They're about UI interactions, state handling, form validation, filtering logic and layouts that hold up on different screen sizes. These are the fundamentals that most frontend work is built on.

Working only in HTML, CSS and JavaScript also has a benefit. With no framework hiding the details, you see how the DOM, events and layout actually work, which makes frameworks easier to learn later.

Working in a team of 11

When 11 people build one project in two weeks, a few things become obvious very quickly:

Everyone depends on everyone else's work.
You need to communicate early, not when something is already broken.
Your code is not just yours. Others have to read it, build on it, and merge with it.

This is where Git and GitHub stopped being commands I had memorized and became a daily tool. I learned how teams actually use them, including raising pull requests (PRs) for our work.

What a pull request is for

A pull request is a request to merge your branch into the shared code. It gives teammates a chance to look at your changes first, and it leaves a record of what changed and why.

If you haven't used a team Git workflow yet, here is the generic shape of it. This is a common pattern, not a copy of our project's exact setup:

# Get the latest code
git checkout main
git pull origin main

# Work on your task in its own branch
git checkout -b feature/responsive-navbar

# Commit your changes
git add .
git commit -m "Make navbar responsive for mobile and tablet"

# Push the branch and open a pull request on GitHub
git push origin feature/responsive-navbar

A few habits make this work better in a big team:

Pull before you start. Working on stale code is how you create problems for everyone else.
Keep branches small and focused. One task per branch is easier to review and easier to undo.
Write clear commit messages. "Fix navbar overflow on mobile" tells your teammates something. "Update" doesn't.

With 11 people contributing to one codebase, merge conflicts are a normal part of the job, not a sign that someone did something wrong. Learning to read and resolve them calmly is a real skill.

Getting to responsive UIs

I started this internship without professional frontend experience, and by the end I could build properly responsive UIs. That didn't come from one big breakthrough. It came from repeating the same cycle: read the PRD, build, get stuck, explain it in scrum, get guided, fix, and repeat.

A responsive UI adapts to different screen sizes instead of breaking on them. Here are the building blocks, with generic examples to show each idea. None of this is code from our projects.

1. The viewport meta tag

Without this line in your HTML <head>, mobile browsers pretend the page is a desktop-sized screen and shrink it, so your media queries won't behave as you expect:

<meta name="viewport" content="width=device-width, initial-scale=1">

2. Media queries, mobile-first

Start with the layout for small screens, then add rules as the screen grows:

.card-grid {
  display: grid;
  grid-template-columns: 1fr;   /* single column on small screens */
  gap: 1rem;
}

@media (min-width: 768px) {
  .card-grid {
    grid-template-columns: repeat(2, 1fr);  /* two columns on tablets */
  }
}

@media (min-width: 1024px) {
  .card-grid {
    grid-template-columns: repeat(3, 1fr);  /* three columns on desktops */
  }
}

3. Flexible layouts and units

Fixed pixel widths are a common reason layouts break. Flexible containers and relative units adapt on their own:

.container {
  width: 100%;
  max-width: 1100px;
  margin: 0 auto;
  padding: 0 1rem;
}

img {
  max-width: 100%;
  height: auto;
}

4. Test on real sizes

Browser DevTools has a responsive mode that lets you resize the page to common phone and tablet widths. It's the quickest way to catch overflowing elements, text that's too small, and buttons that are hard to tap. Testing on a real phone is better still.

The more important lesson is that responsiveness isn't something you add at the end. When you design for small screens first, you spend far less time fixing broken layouts later.

What I learned beyond code

Looking back, the technical skills were only part of it. This three-month internship was a life-turning point for me because of what else I picked up:

Team coordination: how to work with a large team on one deliverable.
Talking to mentors: how to ask for help clearly and at the right time.
Professional behaviour: how to carry yourself in a work environment.
Reporting in scrum: how to explain your progress to seniors.
Git and GitHub: how real teams use them, including raising PRs.

If I had to pick the most useful one, it would be asking for help early. In a team on a two-week deadline, a problem you raise on day two is a small problem. The same problem raised on day twelve is an emergency.

The people who made it possible

I didn't do this alone.

My fellow interns helped me go from zero to building properly responsive UIs. Working with ten other people on the same project taught me more than working alone ever could.

Thank you to all my mentors for the daily guidance, to the two people who pointed me in the right direction before the internship began, and to PW LeapX for the opportunity.

If you're where I was

If you're a student who feels lost about the industry, here is what worked for me:

Find someone a few steps ahead of you. One conversation with the right person saved me months.
Prepare before the opportunity opens. Use the waiting time.
Choose project-based learning. Building real things in a team teaches what courses can't.
Say when you're stuck. The sooner you ask, the sooner you move.
Learn Git properly. You will use it every day in a team.
Build with small screens in mind from day one. It saves you from rewriting layouts later.

I started the year confused. Three months of real projects, daily scrums, and a lot of help from good people changed that.