What does a software engineering intern do day-to-day?

A typical SWE intern day involves a 15-minute standup, picking up a ticket from the team backlog, creating a Git branch, writing or fixing code in an existing codebase, opening a pull request, responding to review feedback, and merging once approved. Time is split roughly 60% coding, 20% reading code and docs, 10% meetings, and 10% communication on Slack or in PR threads.

Do software engineering interns write production code?

Yes. At most companies, intern code goes into production after passing code review and CI checks. Interns typically start with smaller tickets — bug fixes, small features, internal tooling — and progress to larger pieces of work over the internship.

How much do software engineering interns code each day?

Most interns spend 4 to 6 hours per day actively coding. The rest of the day is reading the existing codebase, attending meetings, syncing with their mentor, and waiting on code review. Pure coding time is lower than most students expect — and that's normal.

What is the hardest part of a software engineering internship?

For most interns, the hardest part isn't writing code — it's reading and navigating an unfamiliar codebase, understanding the Git workflow, and writing pull requests that get approved without 30 rounds of feedback. These are the practical skills that university CS programs rarely teach.

What software engineering interns actually do day-to-day

Career Updated April 27, 2026 · 9 min read

If you imagine SWE interns sitting alone in a corner cranking out features in a quiet room, you are wrong about almost everything. Here's what actually happens — minute by minute, ticket by ticket, on a real engineering team.

The real shape of an intern's day

A typical day at a typical tech company looks roughly like this:

9:30 am — Read overnight Slack messages, check what your mentor flagged, look at any review comments left on your open PRs.
10:00 am — Standup. Fifteen minutes max. You say what you did yesterday, what you're doing today, anything blocking you. New interns over-explain. Don't.
10:15 am – 12:30 pm — Coding window. You're either fixing a bug, building a small feature, or addressing review comments on yesterday's PR.
12:30 – 1:30 pm — Lunch. At many companies this is also when senior engineers are most willing to chat. Take advantage.
1:30 – 3:00 pm — More coding. Often broken up by Slack messages, design questions to your mentor, or reading some piece of the codebase you've never touched.
3:00 – 4:00 pm — A meeting or two: design review, sprint planning, 1:1 with your mentor, or an "intern social" you'll probably eye-roll at and secretly enjoy.
4:00 – 5:30 pm — Final coding push. Open or update a PR, respond to comments, push your branch.
5:30 pm — Either you log off, or you get sucked into "just one more thing" until 7. The interns who do this every day burn out by week 6. Don't be that intern.

Notice what isn't on this list: solving algorithm puzzles, designing distributed systems on a whiteboard, refactoring 100k lines of legacy code. Internships are operationally boring. That's the point. The work that earns you a return offer is small, well-scoped, and shipped.

The four things you'll spend the most time on

1. Reading code (more than writing it)

Your first week, you will read more than you will write. The codebase has hundreds of thousands of lines you've never seen, written by twenty people you've never met, in patterns nobody documented. Before you can fix a bug, you have to find the file. Before you can find the file, you have to figure out how requests flow through the system. This is not "ramp up." This is the job.

Senior engineers spend roughly half their time reading code, too. The skill of reading code fast and accurately is the single most underrated skill in the industry. Universities don't teach it. Bootcamps don't teach it. You learn it by doing it.

2. Picking and scoping tickets

A ticket is a unit of work. It lives in Jira or Linear. It has a title ("Fix 500 error on /api/users when email is null"), a description, an assignee, and a priority. As an intern, your tickets will be picked for you the first week or two. Then you'll start picking your own from a queue tagged "good first issue" or "intern-friendly."

Scoping a ticket means: reading it, asking clarifying questions, estimating roughly how long it'll take, and breaking it into commits. The interns who scope well finish on time. The interns who don't scope spend three weeks on a "two-day ticket."

3. Writing pull requests

You will not push directly to main. Ever. You will create a feature branch, make your changes, push it to GitHub or GitLab, and open a pull request. A senior engineer reviews it line by line, leaves comments, and you address them. Then you merge.

Your code is judged on whether it works. Your pull request is judged on whether a busy senior engineer can review it without hating their day. Small PRs get merged fast. Large, sprawling PRs sit for two weeks while everyone procrastinates reviewing them. Learn to write good pull requests — it's possibly the single highest-leverage skill you can develop as an intern.

4. Communicating in writing

Slack messages, PR descriptions, comments, design docs, status updates. Engineering is mostly writing — the code is just one part. The interns who can write a clear three-sentence Slack message ("I tried X and it doesn't work because Y; I'm going to try Z, expected to be done by EOD; let me know if I'm off-track") get treated as future hires from week one. The ones who write three paragraphs of stream-of-consciousness or, worse, ghost their mentor for two days, do not.

Practice the workflow before day one

InternQuest gives you 150+ real engineering tickets — branch, fix, commit, open a PR, get reviewed. Same flow as a real internship, in your browser, free.

Try a mission →

What an intern does not do (despite what college taught you)

Whiteboard algorithm puzzles. You did them in interviews. You will not do them on the job. If you spend three months as an intern doing LeetCode at your desk, you are doing the internship wrong.
Build greenfield systems. 95% of intern work is changes to existing code, not new code from scratch.
Make architectural decisions. Your mentor decides architecture. You implement. This isn't bad — it's how you learn.
Work in isolation. Engineering is a team sport. The interns who try to "go solve it themselves without asking" are visibly less effective than the ones who ask questions every two hours.

The first-week feelings every intern has

Every intern, at every company, in every cohort, feels the following in their first two weeks:

"Everyone here is smarter than me." No, they have just been here longer.
"I have no idea what's going on." Correct. That's why you have a mentor and a 12-week timeline.
"My code is going to break production." No, code review and CI exist exactly to prevent this. The system is designed to catch your mistakes.
"I should have studied more / been better prepared." Probably true, but not in the way you think. The fix isn't more LeetCode — it's practicing the actual workflow: Git, pull requests, code review, debugging real codebases.

What separates the interns who get return offers

Across thousands of intern reviews and return-offer decisions, the pattern is almost embarrassingly simple. The interns who get offers:

Ship small things consistently. Three small PRs per week beats one giant PR per month.
Communicate proactively. They tell their mentor "I'm stuck" within an hour, not at the end of the day.
Ask good questions. "I read the README and looked at file X — I think this means Y. Is that right?" beats "How does this work?" every time.
Take review feedback gracefully. They thank reviewers, address comments, and don't argue defensively about every nit.
Pick up tickets without being told. By week 4, they're scanning the backlog and self-assigning instead of waiting to be handed work.

None of this is technical. None of it shows up in a CS curriculum. All of it can be practiced before you start.

How to actually prepare

If you have time before your internship starts — even a single weekend — the highest-leverage thing you can do is practice the workflow: branch, fix, commit, push, PR, respond to review, merge. Not LeetCode. Not algorithms. The shipping loop.

For a structured plan, see our six-week internship prep guide. For the Git side specifically, start with the Git workflow guide.

Walk in like you've been doing this for months

InternQuest simulates real intern work — fictional senior engineers assign you tickets, you fix them in an in-browser IDE, your PR gets reviewed automatically. Built specifically so you don't fumble your first week.

Start your first mission →