What Your Software Engineering Resume Actually Needs

TL;DR

A resume gets 10 seconds of attention. Design for skimming, not reading.
Bullet points should show impact, not activity. "Reduced load time by 40%" beats "worked on performance."
The projects section is the most important section for new grads — treat it like experience.
GPA only helps if it's above 3.5. Otherwise, leave it off.
One page. No exceptions until you have 5+ years of experience.

Software engineering resumes fail in predictable ways.

Not because candidates can't code. Because they write resumes like a job description instead of a case for hiring.

A resume has one job: get you an interview. It doesn't need to be comprehensive. It needs to be compelling.

The 10-Second Test

Here's the reality: a hiring manager or recruiter is looking at 50 resumes for one role. They will spend 10 seconds on yours before deciding whether to read further.

In those 10 seconds, they are scanning for three things:

Can this person actually write code? (Skills section, project names, tech stack)
Have they done anything real? (Experience, projects, internships)
Is this easy to read? (Layout, formatting, bullet length)

If your resume fails any of these in the first glance, it goes in the no pile. The person didn't read it. They scanned it.

Design for the scan, not for the reader.

One Page. No Exceptions.

If you have less than 5 years of experience, your resume is one page. This is not a preference — it's a signal.

A two-page resume from a new grad signals poor judgment about what matters. It says "I don't know what to prioritize." That's not the message you want to send before you've had a single conversation.

Cut anything that isn't doing work for you. Every line on the page should be earning its spot.

The Bullet Point Problem

Most resume bullets describe activity. Hiring managers want to see impact.

Activity: "Worked on the backend API for a social features project."

Impact: "Built REST API endpoints for friend requests and notifications, reducing page load time by 35% compared to prior implementation."

The difference isn't exaggeration — it's specificity. Add: the tech you used, the scale you worked at, the result you produced. If you don't have a number, estimate one ("for a team of 3" or "handling ~500 requests per day during testing").

Numbers make bullets scannable. They also force you to be honest about what you actually did.

The Projects Section Is Your Experience

If you're a new grad without internships, your projects section is the most important part of your resume.

Treat it like work experience. For each project, include:

What it is. One sentence. What does the app do?
What you built. The specific technical things you implemented.
What you used. The stack, frameworks, tools.
Where it lives. A GitHub link, and a deployed link if you have one.

A strong project entry looks like this:

Task Manager API — Node.js, PostgreSQL, Docker Built a RESTful API for task management with JWT authentication, role-based access control, and full test coverage. Deployed to Railway. GitHub | Live Demo

That's one project. It says: I built something real, I know how to authenticate users, I understand deployment, and I can be verified.

Skills: List What You've Actually Used

Don't list every technology you've ever heard of. List what you can actually use on day one.

Hiring managers read skills sections looking for matching keywords — but they also use them to start conversations in interviews. "I see you have Redis on here — how have you used it?" If your answer is "I watched a tutorial once," you've wasted their time and yours.

Short, honest, current is better than long and aspirational.

Group by type (Languages, Frameworks, Tools) to make it scannable:

Languages: Ruby, Python, JavaScript Frameworks: Rails, React, Node.js Tools: PostgreSQL, Redis, Docker, Git

GPA: When It Helps and When It Hurts

Include your GPA only if it's 3.5 or above.

Below 3.5, it's more likely to hurt than help. Recruiters at companies that care about GPA (big tech, some finance-adjacent firms) will see it and filter you out. Recruiters who don't care about GPA won't notice that you left it off.

If you had a strong semester-based GPA (e.g., 3.7 in your last two years after a rough start), you can include that as "Major GPA" or "Upper-Division GPA."

If your school is well-known, the degree itself is the signal — you don't need GPA to carry extra weight.

What to Leave Off

These things don't help your resume — they either waste space or create liability:

Objective statement. Wastes 3 lines, adds nothing.
"References available upon request." Assumed. Remove it.
Soft skills in the skills section. "Team player" and "fast learner" are not skills.
Every project you've ever touched. Pick your best 2-3.
High school information. Once you're in college, it's irrelevant.
A photo. In the US, this creates legal exposure for employers and often just gets ignored.

Format: Clean Beats Clever

Your resume doesn't need a designer. It needs to be readable.

Use a standard single-column or light two-column format. Left-align everything. Use a common font (Calibri, Georgia, Inter). Keep margins at 0.5-0.75 inches.

Do not use tables to create columns — they break ATS parsers. Do not use colored headers or graphic elements unless you're applying to a design role and the design is genuinely excellent.

The goal is: every ATS parses it cleanly, and every human reader can find your name, contact info, experience, and skills in under 5 seconds.

The ATS Problem

Most large companies use applicant tracking systems to parse resumes before a human ever sees them. If your resume doesn't parse correctly, it's invisible.

Common ATS failures:

PDF with text embedded in images (ATS can't read it)
Tables or multi-column layouts created with HTML-style formatting
Non-standard section headers ("What I've Done" instead of "Experience")
Missing contact information (email, GitHub link)

Submit a PDF from a word processor or LaTeX. Test it by copy-pasting the text into Notepad — if it comes out readable, the ATS can probably handle it.

Tailor It, But Not From Scratch

You should tailor your resume for each application. But that doesn't mean rewriting it every time.

Keep one "master" resume with everything. For each application, swap in the 2-3 bullets that most closely match the job description's language. If the JD says "microservices," and you built something with a service-oriented architecture, call it a microservice.

This is not deception. It's translation. Your goal is to help a reader who has seen 50 resumes today recognize that yours matches what they need.

The resume is not the finish line. It's a door. Your goal is to get it opened — and then perform in the conversation on the other side.

For the details behind writing strong bullets, how to write resume bullet points that show impact covers the before/after approach in depth. For presenting projects, the projects section guide covers format, framing, and what to include. If you want to understand how ATS actually works (and what the common myths get wrong), ATS explained for software engineers covers the reality. For what comes after the resume, see Behavioral Interviews: What They're Actually Testing and The Take-Home Coding Challenge: How to Impress the Reviewer. If you're coming from a non-traditional background, the career changer guide covers how to frame previous experience so it works for you instead of against you.

If you're working on all of this on your own, here's how the Globally Scoped program works.