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.

DEV Community: Sumit Tiwari