What to do in your first week as a software engineering intern

Day one of your first internship is mostly orientation, paperwork, and laptop setup. Day five is when expectations kick in. The students who stand out by week two aren't the ones who shipped the most code, they're the ones who set up well, met the right people, and asked the right questions early. Here's the day-by-day playbook.

The mindset for week one

You will not ship a feature in week one at most companies. You probably won't ship anything at all the first three days. This is normal, even expected.

Your job in week one is:

1. Get fully set up so you're unblocked technically.
2. Make a good first impression.
3. Learn enough about the codebase and the team to start contributing in week two.
4. Don't break anything important.

The worst thing you can do is panic about not contributing fast enough. Senior engineers know exactly what week one looks like, they're judging your process, not your output. A relaxed, curious, prepared intern beats an anxious one every time.

Day 1 (Monday): orientation, setup, and not melting down

Most companies start interns on Monday. The day will involve some mix of:

• HR onboarding (paperwork, security training, NDA).
• Laptop pickup and initial setup.
• Meeting your manager.
• Getting access to email, Slack, GitHub/GitLab, the office, etc.

What to do well on day 1:

• Don't burn out trying to start coding. If access to the repo isn't ready by 3pm, that's normal. Use the time to read company docs.
• Take detailed notes on every system you're given access to. Account names, ticket-system URLs, internal tool names. You'll forget half by Tuesday.
• Find out where to file a ticket if your laptop has issues. IT setup almost always has at least one bug.
• Schedule a 1:1 with your manager for Tuesday or Wednesday if it isn't already on your calendar. Even 30 minutes is enough.
• Introduce yourself in the team's Slack channel. One sentence: who you are, school, what you're excited to work on. Done.

End of day 1 success criteria: you can log in to email, Slack, and your code editor. Anything beyond that is bonus.

Day 2: finish setup, clone the repo, run the code locally

Day 2 is when the real ramp-up begins. The single most important thing: get the codebase running on your laptop. This is harder than it sounds. Internal codebases have undocumented dependencies, version-specific quirks, and "you have to also install X" gotchas that the README forgot.

Plan to spend 2-4 hours on this. Set up a doc as you go (your "Local setup notes") and write down every step. You'll save the next intern hours of pain, and your manager will notice.

Specific things to verify before declaring setup "done":

• You can clone the repo.
• You can install dependencies without errors.
• You can run the test suite to completion. (This catches half of broken setups.)
• You can run the app locally and reach it in your browser (or hit it via curl).
• You can connect to a development database.

If you hit a real blocker, ask within 30-60 minutes. Stewing for hours alone on day 2 is the wrong move. The right Slack message is specific: "Hey, when I run npm install I'm getting this error [paste]. Has anyone seen this?" Most teams have someone who solved that exact issue last quarter and can tell you in 60 seconds.

Day 3: read the code, find your first ticket

By Wednesday, your manager (or onboarding buddy) will probably hand you a "starter ticket." It's usually:

• A typo or copy fix in a UI component.
• A trivial bug that's been on the backlog for months.
• Adding a missing test case.
• A small refactor that shouldn't break anything.

The point of the starter ticket isn't the change itself, it's making you experience the full workflow once: pick a ticket, branch, code, commit, push, open a PR, get review, merge, deploy. Once you've done that loop, you know the team's tools.

Before opening the editor: read about the area you're going to change. If your ticket is in billing/, spend 30-45 minutes reading the surrounding code so you have context. Don't read the whole codebase, just the corner relevant to your task. (See our guide on reading code you didn't write.)

Day 4: ship your first PR

Open the PR. Don't be a perfectionist. Don't wait until everything is "perfect", your first PR exists to verify the workflow, not to demonstrate technical excellence. Your manager and team know it's your first.

Things to get right on this first PR:

• A clean commit message. Conventional commits format (fix: typo in user profile heading). See our cheat sheet.
• A clear description. What changed, why, and how to verify. Three sentences is fine for a tiny change.
• You walked through the diff yourself first. No leftover console.log, no commented-out code, no TODO that should be handled.
• You requested review from the right person. Ask your manager who to ping if you don't know.

Then expect comments. You'll probably get more than you expected, that's normal. See our guide on how code review works for how to handle them gracefully.

Day 5: wrap up week one with a check-in

Friday is your free pass for honest reflection. The instinct is to coast through Friday afternoon, resist it. Spend 30 minutes:

• Update your manager. One paragraph: what you set up, what you shipped (or didn't), what you learned, what's blocking you. Even if you have a 1:1 scheduled, send the written version too, it gives them something to read async.
• Update your "lessons learned" doc. Things that surprised you. Internal tool names. Slack channels you found useful.
• Plan week two. If your manager hasn't already given you a week-two ticket, ask for one before end of day.
• Send thank-yous to anyone who helped you. The IT person who fixed your laptop. The senior engineer who unblocked you. Two-line Slack messages. Costs nothing, builds the relationships that compound for the rest of the internship.

The relationships that matter more than people tell you

Tactical work is half of the internship. The other half is building the relationships that turn into a return offer, a reference, or a future job opportunity. Specific people to invest in during week one:

Your manager

The person making the return-offer recommendation at the end of summer. Schedule a 1:1 by day 2. Come with two questions: "What does success look like for me this summer?" and "What's the most useful thing for me to learn first?" Listen carefully, those are your goalposts for the whole internship.

Your onboarding buddy / mentor

Someone (usually a mid-to-senior engineer on your team) assigned to help you ramp up. They're allocated time for this, use it. Ask them to walk you through the part of the codebase you'll touch most. Most buddies are happy to spend 30 minutes on a screenshare.

Other interns on your team or in your cohort

The people you'll commiserate with for the next 12 weeks, and probably stay friends with for years. Have lunch with them on day 2 or 3. They're going through the exact same thing.

One senior IC outside your team

This is the move most interns miss. Within your first two weeks, find one senior engineer outside your immediate team and ask for 20 minutes of their time. "Hi, I'm a new intern and I'd love to hear about how you got into engineering / what your team works on / how the company has changed since you joined." 80% will say yes. Those conversations build a network beyond your direct reports, invaluable for the long game.

Common week-one mistakes

Spending too long alone before asking

The 30-minute rule: stuck for 30 minutes? Ask. Specifically. Not "I'm stuck", "I'm trying to do X, I tried Y, I got error Z, has anyone seen this?" Vague questions get vague answers; specific ones get unblocking ones.

Not taking notes

Week one drowns you in information. Names, tools, processes, codebases. Without notes you'll forget 80% by Friday. A scratch doc, a notebook, anything works. Re-read it Sunday night to make week two start strong.

Trying to memorize the whole codebase

Impossible. Don't try. You learn the codebase one ticket at a time. Skip the urge to read every file, it's exhausting and not useful.

Pretending to understand when you don't

If a manager or senior says something and you nod but didn't follow, you're setting yourself up for an embarrassing moment three days from now when it comes up again. The phrase that saves careers: "Sorry, can you say more about that? I'm not sure I'm following." No one judges you for this on day one.

Underrating the social half

Engineers tend to think the work is everything. It isn't. The intern who gets the return offer is usually the one whose manager likes them as well as respects their work. Be friendly. Eat lunch with the team. Show up to optional events. None of this is fake, it's how teams form, and team-fit is half of the return-offer decision.

What to read in spare moments

Inevitably you'll have downtime in week one, waiting for access, waiting for review, waiting for an environment to spin up. Useful things to read in those gaps:

• The team's README and design docs. Often outdated, but always informative.
• The last 20 merged PRs in your repo. Best way to understand team conventions and the actual flow of work.
• The runbook if one exists, what to do when production breaks, who's on call, escalation paths.
• Postmortems / incident reports. The team's "how things have gone wrong before." Gold for understanding the system's real failure modes.
• The team's CHANGELOG or release notes, the recent past, in plain English.

Don't try to read everything. Skim, bookmark what's useful, come back when you have a specific question.

End-of-week-one self-check

By Friday afternoon, you want to have:

• ✅ Local dev environment running, including tests passing.
• ✅ Met your manager and at least three teammates.
• ✅ Opened (and ideally merged) one PR, even if tiny.
• ✅ Asked at least three questions in Slack or in person, proves you're engaging with the work.
• ✅ A "lessons learned" doc with at least 10 entries.
• ✅ A clear plan for week two.

If you check most of these, you've had a good first week. Take the weekend off, really off, no Slack, and come back Monday rested.

The bigger frame

The internship is a 12-week conversation. Week one sets the tone. The students who do well in week one buy themselves trust and goodwill, and trust is the currency that lets you take on harder, more interesting work in weeks 4-8 when it matters most.

Don't burn out trying to be a hero on day one. Set up well, ask good questions, ship a small clean PR, learn the team's rhythms. The hard problems come soon enough; you'll be ready for them.