How to write it
The projects section is the whole resume
For a new-grad application, the projects section is where differentiation happens, and most of them are written in a way that removes it. "Built a full-stack web app using React, Node and MongoDB" describes a tutorial. It could be any of two hundred applicants, because it is any of two hundred applicants.
The fix is to describe what the thing does and whether it survived contact with reality. "Built a transit-delay API over the city's GTFS feed; it has served about 90k requests since launch and the data pipeline runs nightly on a $5 VPS" describes a person who shipped something, kept it running and thought about cost. Same project, entirely different signal.
Three good projects beat eight. If a project was abandoned at 40%, either finish it or leave it off — a reader who clicks through to an empty repo has learned something you did not want them to.
- What it does, in one clause, before what it was built with
- Whether anyone used it — requests, users, downloads, stars, a real deployment
- A constraint you worked under: latency, cost, data volume, a device limit
- A link that works, to a repo with a README that explains it
- The stack per project, so a reader can see which technologies you actually used where
Internships: write the engineering, not the attendance
Internship bullets tend to describe the experience of being an intern — attended standups, participated in code reviews, learned the codebase. None of that is a contribution.
What a reader wants to know is what shipped and what it changed. "Shipped a retry and backoff layer for the settlement service in Go, eliminating about six pages a month" is engineering. So is "added integration tests that caught two pre-existing bugs, both fixed in production during the internship".
The highest-value thing you can convey from an internship is that you worked inside an existing system. Almost every CS resume demonstrates the ability to start from a blank file; far fewer demonstrate the ability to read four hundred thousand lines of someone else's code and change it safely. Say so explicitly, because that is what the job is.
The skills list, and how to keep it honest
Group it — languages, frameworks, infrastructure, tools — rather than running twenty-five terms together. Order within each group is read as priority, so put what you would want to be interviewed on first.
Do not rate yourself out of five. The scale is undefined and self-assigned, and it invites a question you would rather not answer. If the gradient matters, split the section into something like Core and Familiar, which conveys the same thing in words a reader can interpret.
And keep it defensible. A language listed because you did one assignment in it will surface in the first technical screen, and being caught overstating is worse than a shorter list. The rough test: if it is on the page, you should be able to talk about something you built with it for two minutes.
Format, and the one-page rule
One page. There is no new-grad situation that justifies two, and stretching to two makes the thin parts conspicuous. Single column, plain typography, no photo, no skill bars, no colour beyond an accent.
Order for a student: contact details with GitHub and LinkedIn, a short summary with your graduation date, education, experience, projects, skills. Move projects above experience if your projects are genuinely stronger than your internships — for many second-year applicants they are, and pretending otherwise buries your best material.
Put your graduation date somewhere obvious. New-grad and internship hiring runs on a calendar, and a recruiter filtering for a summer 2026 cohort cannot place you without it.
Applying without an internship yet
Very common, and not fatal. The substitute is a projects section that is unusually good, plus anything that shows you have worked with other people's code: open-source contributions with links to merged pull requests, a hackathon project that got finished, a TA or lab-assistant role, a course project where you owned a component.
Open-source contributions are worth more than their size suggests. A merged pull request against a real project — even a small one — demonstrates reading unfamiliar code, following a contribution process and responding to review, which is the closest thing to job experience available without a job.
Class projects count, and should be described as work rather than as coursework. Name what you owned within a group project, because "contributed to a team project" tells a reader nothing about which part was yours.