Internships — getting and using your first one

The first internship is the highest-leverage credential you collect in your first decade. Not because internships pay well (they do, but that’s not it). Because once you have one real internship at a real company, every conversation after that — the next internship, the new-grad role, the lateral move three years in — starts on different footing. The resume gets read longer. The recruiter calls back. Your cold emails get replies because you’re a known quantity.

Without one, you’re applying through the front door of every single company, into the same pile as 8000 other applicants. With one, you’re being introduced to teams by name. The asymmetry is severe and almost no student appreciates how severe until they’re on the other side of it.

This module is about getting the first one and using it. Most of what’s here applies to the second and third too — the dynamics don’t change much, the leverage just compounds.

Set up — a brutal honesty checklist

Open your resume now. Open your GitHub. Open your LinkedIn. Look at all three the way a recruiter looking at 200 applications in two hours would. Be honest:

• Resume is one page, no exceptions.
• Top of the resume is projects, not coursework or objectives.
• At least one project has a live demo URL or a screenshot.
• GitHub is not empty, not a graveyard of one-commit forks, and the pinned repos look intentional.
• Pinned repos have READMEs longer than three lines.
• The email on your resume is your name, not xx_dragon420_xx@gmail.com.
• LinkedIn photo is recognisable as a human face.

If any of those are false, fix them this weekend before you send a single application. They are filters that operate before anyone reads a word of your content.

Read these first

Three sources, in this order, then stop:

1. Patrick McKenzie — Salary Negotiation: Make More Money, Be More Valued. post · 60 min · read it now even though you’ll re-read it before your offer. The framing reshapes how you write your applications.
2. Gergely Orosz — The Pragmatic Engineer’s intern guide. post · 25 min · current, pragmatic, written by someone who’s hired hundreds.
3. Yossi Kreinin — People can read your code (the section on resumes). post · 10 min · why “looks like a real engineer’s GitHub” beats every credential.

Stop. Don’t read the “internship secrets” YouTube content. They are written by people whose product is the video, not engineering jobs.

Timing — apply 6-9 months ahead, not 6 weeks ahead

The single biggest mistake undergrads make is applying for summer internships in March. By March, the FAANG-tier internships have been filled since November. The competitive mid-tier ones since January. By March, you are applying to the third-tier postings that haven’t filled yet because they’re third-tier.

The actual calendar:

Internship season	Top-tier applications open	Most filled by	Last reasonable apply date
Summer (June-Aug)	August prior	January	March (for stragglers)
Fall (Sep-Dec)	March-April	June	August
Winter (Jan-Feb)	August prior	November	December
Spring (Mar-May)	October prior	January	February

Translation for most students reading this: start applying in August or September for the following summer, no matter how early it feels. Yes, even if you don’t feel ready. The application cycle rewards being early. Resumes don’t have to be polished masterpieces in August — they can be edited as you go. What can’t be edited is the deadline that already passed.

What gets read

A recruiter is looking at your resume for 30-90 seconds, often less. Here’s what they actually look at, in order:

1. One shipped project — a working thing with a link. A live demo, a public GitHub with stars, a repo with a real README. They click. If it works and looks intentional, you move to the “yes” pile.
2. Real GitHub activity — green-square graph, a few repos that aren’t tutorial follow-alongs, evidence that you commit to non-school code regularly.
3. Evidence of taste — small details that signal “this person notices things.” Clean READMEs. Reasonable commit messages. A personal website. One thoughtful blog post.
4. Internships or contributions or competitions — concrete external validation, in any of these forms.

What gets ignored, regardless of how much space you gave it:

• Course list. They have your major.
• GPA below 3.7. Don’t put it. Above 3.7, list it.
• “Passionate about…” lines. Every applicant claims passion. It’s a noise word.
• Skills section as a giant blob of every language and framework. Cluttered, looks like padding. Limit to the 5-8 things you’d be willing to be technically interviewed on.
• High school anything. You’re past that. Cut it.

Resume format that works

One page. PDF. Sections in this order:

[Your Name] · email · phone · github · personal site · location

EDUCATION
  University · degree · expected grad date · GPA (if >= 3.7)
  Two lines max. No coursework list.

PROJECTS
  Three projects, each with: name (linked), one-line description,
  3 bullets describing what you built and the impact, tech stack
  in italics.
  This is the most important section. Most space goes here.

EXPERIENCE
  Internships, research, jobs that involved code.
  STAR-format bullets — what you did, scoped tightly, with numbers.

SKILLS
  Languages: ...
  Frameworks/Tools: ...
  Five to eight items max in each row.

LEADERSHIP / OPEN SOURCE (optional)
  Hackathon wins, OSS contributions with linked PRs,
  community organising. Skip the section if you have none.

The PROJECTS section first is a reversal of the normal “education first” template. It’s deliberate. Recruiters know what college you go to from line 2; they don’t know what you’ve actually built unless you tell them in line 5.

Each project bullet should answer: what did I build, what’s the size or impact, what tech? For example:

• Built a SQLite-based vector search tool used by ~200 weekly active users; achieved 10ms p99 query latency over 50k documents. Python, FastAPI, sqlite-vec.
• Replaced a coursework spec’s reference solution after benchmarking 4x faster on n=10^6 inputs. Code merged into class repo. Rust, criterion.

Specific. Numerical. Linked.

The cold email template that actually works

Most students send the same generic application through 200 portals and get 3 callbacks. The students who get 30 callbacks are the ones who supplement with cold emails to actual humans. The reply rate on a well-written cold email is 10-25%, vs. ~1% for portal applications.

Here is a template that works. Customise per company; never send the same email to two people without changes.

Subject: Internship + your work on <specific project>

Hi <First Name>,

I'm <name>, a <year> at <school> studying <major>. I've been
following your work on <specific thing they built/wrote/shipped — be
real, mention something only someone who looked would know>.

Quick context: I'm looking for a <summer/fall> <year> internship
on a team like yours. The most relevant thing I've shipped is
<one project, linked>, where I <one sentence on what was hard
and what you learned>.

Resume attached. I'd love 15 minutes to learn what your team is
working on this year and whether there's a fit.

Thanks for your time,
<your name>
<linked website>

What makes this work, point by point:

• Specific opening. “Following your work on X” with a real X — a blog post, an open-source repo, a talk. Not “I love what your company does.” Generic = filtered.
• One paragraph of evidence. A linked project that proves you’re a real engineer, not a job-board ghost.
• The 15-minute ask. A specific, low-cost thing to say yes to. Not “an opportunity to interview” — that’s the recruiter’s job.
• Short. Under 150 words. They get 80 of these a week. Long ones don’t get read.

Send 30. Expect 3-6 replies. Of those, 1-2 turn into something. That’s a normal rate.

To get to 30 contacts: pull engineers’ emails off their personal sites, off GitHub commits (git log --format=%ae), off the company’s /team page. Junior engineers and TLs reply more than directors. Aim for the level just above the role you’d take.

Leverage your school + alumni

Underrated channel. Specifically:

• The CS department’s internship list. Often a private email list, often outdated, often full of recruiters who specifically want students from your school. Get on it.
• Alumni at target companies. LinkedIn alumni search by school + company. Send an honest email: “I’m at $school, considering applying to $team, would 15 minutes be okay?” Reply rate from alumni is much higher than from cold strangers. Ask them about their team, not for a referral. The referral comes naturally if the conversation went well.
• Your professors. Especially if you’ve taken a research-y class with one. Many of them have industry connections they’ll happily make.

”We want experience” with no experience yet

The bootstrapping problem. You can’t get an internship without experience, you can’t get experience without an internship.

The way out: manufacture the experience. A real shipped project that runs and is used by 50 people is experience. A merged PR to a real OSS project is experience. A 1500-word technical blog post that ranks on the second page of Google for a real query is experience. None of these require anyone hiring you.

Recruiters know this. They use these signals as a substitute for the internship you don’t have yet. The “we want experience” wall is not as solid as it looks if you arrive at it with three pieces of public proof.

Once you’re in — the first 30, 60, 90 days

The internship is not the prize. It’s the start of the longest interview you’ll ever take. How you use the first 30, 60, 90 days predicts whether you get a return offer and whether your manager remembers you in 5 years. The pattern that works:

First 30 days — orient

• Get the dev loop working end-to-end. Cloning, building, running tests, deploying to staging. Most interns waste 2 weeks on setup; you should be done in 3 days. If you’re stuck, ask for help by day 4.
• Read code more than you write. Specifically: the file you’ll be modifying, the team’s shared utility code, and the tests for both. Take notes.
• Ask. Constantly. Politely. “Naive question — what does X mean here?” is welcomed if it shows you’re paying attention. Asking the same thing twice is not.
• Ship one tiny PR. A dependency upgrade, a typo, a small lint cleanup. The point is the loop, not the impact.

Days 30-60 — own a small thing

• Take a small bug or feature off the team’s backlog. Scope it ruthlessly. Ship it with tests.
• Start asking specific design questions in your 1:1: “I noticed we do X, when would you do Y instead?”
• Notice who the team’s senior engineers are. Schedule informal coffees, ask them what they’re working on. Learn from them. Many of them will be your reference letters in two years.

Days 60-90 — own the writeup

• Write a doc summarising your project. What did you build, what surprised you, what you’d do differently.
• Share it with the team. This is the artifact the manager forwards to their manager; it’s how you become legible to the org.
• Ask for the return offer in plain language. “I’d really like to come back next summer / for full-time. Is there anything I should be doing differently?” Do not be cute about this.

What not to do as an intern

The four mistakes that quietly tank intern reviews:

• Pitching architecture in week one. You don’t know the constraints. You’ll suggest something the team rejected for a real reason 18 months ago. Listen for a month before you propose anything bigger than a bug fix.
• Criticising the codebase in public. “Why did they write this?” — said in standup, said in a PR, said on Slack. Read instead.
• Disappearing for a week with no updates. Stuck for a day is fine. Stuck silently for a week is a review-killer. Status-update yourself proactively.
• Treating the internship as one task. Some interns finish the assigned project, then go quiet. Finish it, ask for the next thing. Then ask for the next.

Going deeper

When you have specific questions, in this order:

1. Gergely Orosz — The Pragmatic Engineer. substack · the most up-to-date writing on what tech hiring actually looks like.
2. Charity Majors — The Engineer/Manager Pendulum. post · 25 min · for the longer arc of what comes after the internship.
3. Will Larson — Staff Engineer. book · skim the early chapters · the trajectory you’re early on.
4. levels.fyi internship pages — actual pay data, not the misleading “average”.

Skip “5 internship hacks” content. They’re written for people who haven’t shipped anything yet.

Checkpoints

If any one wobbles, the corresponding section above is what to reread.

1. Name the actual application timing for summer internships. When should you start? When are most filled?
2. What are the four things a recruiter actually looks at in 30-90 seconds? In what order?
3. Walk through the cold-email template’s four key elements. What makes the reply rate 10-25 percent vs 1 percent?
4. What are the three things you do in your first 30 days at an internship? What are the four things to not do?
5. How do you ask for a return offer in plain language? Why does plain-language matter?

If you can answer all five, you’ve earned 07.1. Next is 07.2 — the interview gauntlet, where the cold-email work meets the technical bar.