How to prepare for a software engineering internship

If you're reading this, you probably already have an internship offer (or expect one) and you have a few weeks before it starts. Good. The internet will tell you to grind LeetCode. The internet is wrong. Here's the actual six-week plan.

What hiring managers actually want from interns

Before the plan, the principle: when an engineering manager evaluates an intern at the end of the summer, the question they're answering is "would I want this person on my team after they graduate?" The answer is almost never about algorithms. It's about whether you can:

• Take a vague ticket and turn it into a working pull request without three days of follow-up questions.
• Fix bugs in a codebase you've never seen before.
• Take review feedback without being defensive.
• Communicate clearly when you're stuck.
• Ship something — anything — every week.

That's the bar. Now here's the plan to clear it.

Week 1: Master the Git workflow

You will use Git every single day of your internship. Most CS programs cover it for one lecture, one time. That's not enough. Spend a full week getting good at it.

By end of week 1, you should be able to do all of these without looking anything up:

• Create a feature branch (git checkout -b fix/something).
• Stage and commit changes with a conventional commit message (fix: handle null email in /api/users).
• Push your branch (git push -u origin fix/something).
• Resolve a merge conflict without panicking.
• Use git rebase -i to clean up your commits before opening a PR.
• Read the output of git log --oneline --graph and understand what happened.

Read our Git workflow for beginners guide. Then practice on a real codebase, not a tutorial sandbox.

Week 2: Read and debug real code

Clone a real open-source project — pick something in a language you'll use at your internship. Find an issue tagged "good first issue." Read enough of the codebase to understand where the bug lives. Fix it. Open a PR.

You will be slow. That is the point. The skill of navigating an unfamiliar codebase is the single biggest difference between an intern who takes 3 weeks to ship their first ticket and one who ships in their first week. You build it by doing it badly, repeatedly.

If you don't want to wade through OSS triage, the alternative is to practice on a curated set of pre-broken codebases — that's part of what InternQuest is built for.

Week 3: Write production-style code

"Production-style" means: not clever, not minimal, not maximally short. It means your code handles edge cases, fails predictably, has tests for the parts that matter, and reads clearly to a stranger.

This week, take any small project you have and rewrite one module of it as if your senior engineer would review it. Add tests. Handle the null cases. Replace the magic strings with named constants. Stop trying to write code that looks impressive — write code that reads like it was written by someone reasonable.

One specific exercise: pick a function from your project that you wrote without thinking. Now imagine a hostile reviewer. What inputs would crash it? What happens if the network call fails? What if a user is malicious? Add the handling.

Week 4: Practice code review (both sides)

Most interns are terrible at code review on day one because they've never done it. Two angles:

Receiving review

• Read every comment fully before responding.
• If you disagree, push back politely and with reasoning ("I considered that — I went with X because Y. Open to changing it if you want, though.").
• If you don't understand a comment, ask. Don't pretend.
• "Resolve" each comment thread once you've addressed it — don't leave 40 dangling threads.
• Thank the reviewer when you merge. It costs nothing and people remember.

Giving review

Yes, even as an intern, you'll review other people's code. Practice now by reviewing PRs in OSS projects. Learn the difference between a blocking issue ("this will crash production"), a question ("why this approach over X?"), and a nit ("I'd prefer fooBar over foo_bar"). Mark each appropriately. Senior engineers who do this well are loved. Interns who do this well stand out instantly.

Week 5: Ship a portfolio project end-to-end

Pick something small. Three pages. One feature. The point is not the project — it's that you take it from idea to deployed URL with a CI badge. The end-to-end shipping loop is the thing you're practicing.

Required ingredients, no shortcuts:

• Public Git repo on GitHub.
• README with setup instructions and a one-paragraph description.
• At least one test file, even if it tests one thing.
• GitHub Actions workflow that runs the tests.
• Deployed somewhere accessible: Vercel, Netlify, Render, or a $6 droplet.
• Conventional commits in the history.

You will hate at least one part of this. That's fine. The point is to do it once before your first day of work, so when your manager says "set up a GitHub Actions pipeline for this," you say "yeah, give me an hour" instead of staring blankly.

Week 6: Pre-internship reading and async communication

Read your company's public engineering blog. Read the README of any public repos they have. If they have a developer documentation site, skim it. You will not understand most of it. That's fine — the words will sound less foreign on day one.

Also this week: practice writing async messages like an engineer.

Bad message:

"hey i'm stuck on this thing can you help"

Good message:

"Hey — quick question on the auth ticket (IQ-42). I'm trying to call verifyToken() from the new middleware, but it's throwing because the env var JWT_SECRET isn't loaded in test. I tried adding it to .env.test but it's still undefined. Am I loading the test env wrong, or should the middleware not run in test? No rush, blocked on this until I hear back."

The second one tells your reviewer everything they need in 30 seconds. They can answer in another 30 seconds. The first one will sit in their inbox for 4 hours while they avoid it.

What you can safely skip

• LeetCode beyond what got you the offer. You did the hard problems for the interview. Now stop. The marginal hour spent on LeetCode is worse than the marginal hour reading code.
• Memorizing the company's tech stack from blog posts. You'll learn the actual stack on day one in 30 minutes. Don't memorize anything yet.
• Pre-coding "side projects" to impress your team. Nobody will ask. Spend the time on the workflow skills above.

The shortcut: simulate the work

If you have less than six weeks, or you want to compress all of this into something you can do in a few hours per week, the shortcut is to simulate the actual workflow under realistic conditions: a ticket from a fictional senior engineer, an unfamiliar codebase, a bug you have to find, an automated reviewer who marks up your PR.

That's the whole premise of InternQuest. It's the closest thing to "doing an internship before your internship" we know how to build.