How to write a software engineering resume as a student

A recruiter spends 7 to 30 seconds on your resume. If they don't see what they need in that window, you're rejected, regardless of how good your code is. The students who land interviews aren't necessarily the most skilled ones. They're the ones whose resumes signal "competent enough to interview" in 7 seconds. Here's how to write one.

The 7-second test

Before anything else, understand the constraint: a recruiter at a tech company sees hundreds of student resumes per role. They don't read, they scan. They look for specific signals in specific spots. Miss those and you're filtered out.

The signals they scan for, in order:

1. School name + GPA (top right or top left corner, big-school-bias is real)
2. Internship history (do you have prior tech internships? if yes, where?)
3. Tech stack (do you list the languages/frameworks the role wants?)
4. Project bullets (are the projects substantial? do they show outcomes?)
5. Anything weird (typos, formatting issues, an objective statement from 2010)

If those four positives all light up green, you go in the "phone screen" pile. If anything looks off, you go in the no pile. The whole optimization is making those four signals as visible as possible.

The format that works

One page. Black text on white background. No photo, no graphics, no fancy fonts. The reasons:

• Most resumes pass through ATS (applicant tracking systems) that strip formatting and parse text. Decorative resumes break the parser.
• Recruiters scan dozens; visual clutter slows them down and works against you.
• Hiring managers view resumes on phones, in PDF previews, in Slack threads. Simple formats survive every viewing context.

The standard sections, in order:

1. Header, name, email, phone, LinkedIn, GitHub, personal site (if good).
2. Education, school, degree, expected graduation, GPA if 3.5+.
3. Experience, internships, jobs, research, TA roles. Most recent first.
4. Projects, 2-4 substantial projects with bullets.
5. Skills, languages, frameworks, tools. Brief.
6. Optional: Awards, hackathons, open-source contributions.

Skip: objectives, "Hobbies and Interests," references, photos, soft-skills lists. None of these help; some hurt.

The header in 4 lines

Alex Chen                                  alex.chen@email.com | (555) 123-4567
                       linkedin.com/in/alexchen | github.com/alexchen | alexchen.dev

Notes:

• Use a professional email. Not nightmare_42@hotmail.com. Your school email or a clean Gmail is fine.
• LinkedIn is non-optional. Recruiters check it. If you don't have one, make one this week.
• GitHub matters if it's good. Pinned repos with clean READMEs and recent activity = strong signal. An empty profile or a graveyard of half-finished projects = neutral or negative; consider linking only if you've got at least 2-3 real projects.
• Personal site is optional but a real positive if it exists and looks decent.

Education section

EDUCATION

University of Waterloo                                            Sep 2023 – May 2027
Bachelor of Computer Science (Honours), Co-op
GPA: 3.85 / 4.00 | Dean's List

Relevant Coursework: Data Structures, Algorithms, Operating Systems,
Databases, Computer Networks, Distributed Systems

Notes:

• List GPA only if it's 3.5+ on a 4.0 scale (or equivalent). Below that, omit it; the absence is less negative than the number.
• "Relevant coursework" is optional but useful for first-year students with thin experience sections, it shows what you've actually studied. Skip after junior year.
• Honors / awards like Dean's List, scholarships, or hackathon wins go here or in a separate section.

Experience bullets: the make-or-break section

This is where every junior writes weak bullets. The pattern that works has three pieces:

What you did + How you did it + What it produced

Weak bullet:

"Worked on the user authentication system."

Strong bullet:

"Migrated the legacy session-cookie auth to OAuth2 with PKCE across 14 microservices, reducing login-related support tickets by 60% and unblocking SSO rollout for the enterprise tier."

The strong version names: the technology (OAuth2, PKCE), the scope (14 microservices), and the impact (60% ticket reduction, SSO unblocked). A recruiter reads this once and immediately knows you can talk about it in an interview.

Patterns that produce strong bullets:

• Lead with an action verb. Migrated, built, refactored, optimized, automated, designed, integrated, deployed.
• Include the technology. Not "wrote a service", "wrote a Go service using Postgres and Redis."
• Quantify the outcome. Numbers ground claims: "reduced p95 latency by 40%," "shipped to 8,000 daily active users," "cut deploy time from 25 to 4 minutes."
• If you can't quantify, name the qualitative outcome. "Unblocked X." "Replaced Y." "Eliminated Z class of bugs."

What if I don't have impact metrics?

Most students don't. Two strategies:

1. Ask for them. If you did real work at an internship, your manager can probably tell you. "Hey, do you remember roughly how much faster the dashboard got after my changes?" Most managers know and will share.
2. Estimate honestly. If you reduced the codebase by ~400 lines, that's a number. If you handled traffic from N daily users (look at your team's metrics), use that. If you don't know, write the qualitative version with named technologies and skip the number.

Don't fabricate metrics. Recruiters and interviewers can usually smell made-up numbers and will ask follow-up questions you can't answer.

Projects section: what counts as "substantial"

For students with limited internship history, projects do most of the heavy lifting. The bar is much higher than most students realize.

Doesn't count as substantial:

• To-do list apps, weather apps, simple CRUD tutorials.
• Course assignments unless they were genuinely ambitious.
• Anything you built by following a YouTube tutorial step-by-step.

Counts as substantial:

• Anything with real users (even 50 friends).
• Anything that solved a personal problem you actually had.
• Open-source contributions to projects with stars.
• Hackathon projects that won or shipped.
• Anything that involved trade-offs you can speak to in an interview.
• Internship-style projects: cloning the workflow of a real company on broken codebases (e.g., InternQuest missions).

Project bullets follow the same template as work bullets, what + how + outcome:

PROJECTS

DormSwap, Peer-to-peer textbook marketplace        github.com/alex/dormswap
- Built a Next.js + Postgres marketplace serving ~600 weekly active students
  across 3 universities; processed $40K in transactions with Stripe Connect
- Designed an embeddings-based search using OpenAI + pgvector that improved
  click-through rate from 8% to 31% over keyword search
- Reduced page load p95 from 2.1s to 380ms by adding Redis caching of hot
  product queries and switching to streaming server-side rendering

Three bullets. Each names tech (Next.js, Postgres, Stripe, pgvector, Redis), states scope (600 users, $40K, 3 unis), and gives outcome (CTR delta, latency drop). A recruiter reads this and knows you can talk about a real system.

Skills section: what to list, what to skip

Common student mistake: listing every language and framework they've ever touched. This dilutes signal, if you list 14 languages, the recruiter assumes you're a beginner at most of them.

Better:

SKILLS

Languages:    Python, JavaScript, TypeScript, Go, SQL
Frameworks:   React, Next.js, FastAPI, Django, PostgreSQL, Redis
Tools:        Git, Docker, AWS (EC2, S3, Lambda), Linux, GitHub Actions

Group by category. Order by depth, strongest first. Only list things you can actually speak to in an interview. If "Rust" is on your resume, an interviewer might quiz you on ownership semantics. If you can't answer, you torch the interview.

Skip: HTML, CSS as separate skills (assumed at this level), soft skills ("teamwork"), and operating systems unless DevOps-relevant.

Auto-rejection patterns: what gets you filtered before review

1. Typos. One is forgivable. Two is "this person doesn't proofread their own code." Three is auto-reject.
2. Inconsistent formatting. Some bullets have periods, some don't. Some companies are bold, some aren't. This signals carelessness.
3. Multiple pages. Students should be one page. Multi-page resumes for students read as inflated.
4. Wrong dates. Listing future internships or saying "expected May 2025" when it's already 2026.
5. Lying about tech. Listing tools you've used once. They'll catch it in the interview.
6. Generic objective statements. "Seeking a challenging role to grow my skills…" Delete it.
7. Wall of text. Bullets longer than 2 lines. Recruiters skip them.

Tailoring per application: yes, do this

Most students send the same resume everywhere. Don't. Spend 5 minutes per application reordering bullets and skills to match what the role's description emphasizes.

Concrete tailoring moves:

• Reorder skills so the role's stack is listed first.
• Reorder projects to lead with whichever is most relevant.
• Adjust bullet emphasis, for a backend role, lead bullets with backend work; for a frontend role, the React bullet leads.

You don't need 50 versions. Three or four, backend-focused, frontend-focused, infrastructure-focused, generalist, covers nearly every application.

What to actually do this week

1. Audit your current resume. Run it through the 7-second test by handing it to a friend and asking "what did you see in the first 7 seconds?" If they don't mention school + tech stack + recent project, your resume is failing.
2. Rewrite your three weakest bullets using the action + how + outcome pattern.
3. Get one project with a clean README on GitHub if you don't have one. Link it.
4. Have one senior engineer review it. Even a 10-minute review catches things you can't see. Career-services counselors can help; engineers on Twitter or Discord servers like r/cscareerquestions or buildinpublic communities will too if you ask politely.
5. Save it as PDF. Always send PDFs. Word docs render differently on every machine.

The bigger picture

A resume is a 7-second pitch for a 30-minute conversation. It doesn't need to capture everything you are, it needs to make the recruiter say "yes, talk to them." That's a much smaller bar than it feels.

The students who get interviews aren't usually the smartest in the room. They're the ones whose resumes are easy to scan, whose bullets demonstrate impact, and whose projects show real engineering, not tutorial completion. Spend the time. Update it twice a year. It's the highest-ROI document you'll write all year.