How to write a computer science student resume

What a CS resume has to prove

A computer science student resume has a narrower job than most. Whoever reads it, a university recruiter, an engineer screening applications between meetings or a hiring manager, wants answers to a short list of questions. Can you write working code? In which languages and frameworks? Have you built something real with other people, under some constraint, and finished it? And can you explain what your work did?

Grades and coursework help, but they rarely settle those questions alone. What settles them is evidence: internships, projects with a clear purpose, contributions to code other people use, hackathon builds, teaching assistant roles and research. A strong cs resume puts that evidence up front, names the technology precisely and describes outcomes the way engineers talk about them.

This guide covers the sections that matter for a software engineering intern resume and a new grad software engineer resume: how to structure projects, which links to include, how to group technical skills, where hackathons and coursework fit and how to describe impact in code.

The layout: one page, built for skimming

Engineers tend to skim resumes fast and look for specific things, so a predictable layout serves you better than a creative one. A good order for most computer science students:

1. Header: name, city and state, email, phone, LinkedIn and GitHub URLs, plus a portfolio site if you have one.
2. Education: university, degree (for example, "B.S. in Computer Science"), expected graduation month and year, GPA if it helps you, and a short list of relevant coursework.
3. Experience: internships, research positions, teaching assistant roles and part-time technical jobs.
4. Projects: two to four projects with tech stacks and links.
5. Technical Skills: grouped by category.
6. Leadership or Activities: hackathons, ACM chapter or coding club roles, tutoring, mentoring, if you have room.

If you have no internship yet, move Projects above Experience. Your projects are then your strongest proof, and a recruiter should not have to scroll past a retail job to find them.

Keep it to one page. Even strong new grads rarely need two, and a tight page forces you to keep only your best work. Use one column, plain section headings and a standard font, and avoid skill bars or language logos; they do not parse and they say nothing about depth. For the formatting rules applicant tracking systems need, see the ATS friendly resume guide.

Projects: the section that carries a student resume

For many students, projects do more work than any other section, so build them carefully. Each project entry should have:

• A name and a one-line purpose. "Campus Ride Share: a web app matching students for off-campus trips."
• The tech stack, written on the title line or right below it: "React, TypeScript, Node.js, PostgreSQL, Docker."
• Context and dates: personal, course (with the course number if it helps), hackathon or open source, plus the month and year.
• A link: a GitHub repository or a live demo, if the code is yours to share.
• Two or three bullets describing what you built, how and what happened.

Compare these:

• Weak: "Made a website for finding study groups using React."

• Strong: "Built a study group finder in React and Firebase with real-time chat and course-based matching; 140 students signed up in the first month after launch in two dorm group chats."

• Weak: "Worked on a machine learning project."

• Strong: "Trained a convolutional neural network in PyTorch to classify plant leaf diseases from 6,000 labeled images, reaching 91% validation accuracy after adding data augmentation and early stopping."

Choose projects that look like the work you want. If you are applying for backend roles, a REST API with authentication, a database schema and tests is more relevant than a polished landing page. If you want mobile roles, ship a mobile app. One substantial project you can discuss in depth beats five tutorial clones. A to-do app built by following a course step by step rarely helps, unless you extended it in a meaningful way and can explain the decisions you made.

Be honest about team projects. Say what you built: "Implemented the matching service and its unit tests in a four-person team" is more credible, and safer in an interview, than implying you built everything.

GitHub, portfolio and other links

Recruiters and engineers do click links, so make sure they lead somewhere useful.

• Use clean URLs. Write "github.com/username" in the header rather than a long tracking link. If you use a PDF, check that the links are clickable and also readable as plain text, since some systems strip hyperlinks.
• Pin your best repositories. Your GitHub profile should show your strongest three to six projects first, each with a README that explains what it does, how to run it and what you learned or would improve.
• Clean up before you apply. Remove or archive half-finished experiments and never commit API keys or passwords. A leaked secret in a public repo is the kind of detail an engineer notices.
• Respect ownership. Do not publish code from an internship or a class assignment if your employer or school policy does not allow it. Describe it on the resume instead.
• A portfolio site is optional. It helps most for front-end, design-adjacent and mobile roles. For backend and systems roles, good READMEs matter more than a custom site.

Contribution graphs and star counts are not the point. A recruiter looks for readable code, sensible commit history and evidence that you finish things.

Technical skills: grouped, honest, matched to the posting

A long, unsorted list of every technology you have touched is hard to read and invites questions you cannot answer. Group skills into a few categories and keep each one to what you can actually use:

• Languages: Python, Java, C++, TypeScript, SQL
• Frameworks and libraries: React, Node.js, Express, Spring Boot, PyTorch
• Tools and platforms: Git, Docker, Linux, AWS (EC2, S3, Lambda), PostgreSQL, GitHub Actions
• Concepts (optional): REST APIs, unit testing, CI/CD, object-oriented design

Order languages by strength, not alphabetically. If you want to signal depth, a short qualifier works better than a rating: "Familiar with Go" is honest; a four-star icon is not. Never list a language you could not write a simple function in during a technical interview, because interviewers often pick from your skills list.

Match the posting's spelling and naming where the skill is genuinely yours. If the job says "JavaScript (ES6+)" and "Node.js," use those forms rather than "JS" and "Node." If it lists "AWS," and you have deployed with EC2 and S3, naming both the platform and the services helps both search and readers.

Internships, research and hackathons

Technical experience comes in more forms than a formal internship, and each deserves the same treatment: title, organization, city and state, dates and results-focused bullets.

Internships. Describe the system you worked on, what you built or changed and how you know it worked. Name the stack. If your internship had a final presentation or a shipped feature, say so: "Shipped a feature flag service used by three internal teams" is concrete.

Research. Undergraduate research is valuable experience, especially for machine learning, systems and graphics roles. State the problem in plain language, your part in the work and any output: a dataset, a tool, a poster or a paper you contributed to.

Teaching assistant and tutoring roles. These show you understand fundamentals well enough to explain them. "Held weekly office hours for 60 students in Data Structures and graded programming assignments in Java" fits under Experience.

Hackathons. A hackathon build can go under Projects, with the event and month as context. What makes it strong is the same as any project: what you built in the time available, with what stack, and what happened next. If you placed or won a sponsor prize, include it briefly. If you attended several, you can also list them in one line under Activities. Do not let hackathon count replace substance; one well-described build says more than a list of event names.

If you are still looking for your first technical role, the internship resume guide covers how to put together a strong application before you have much experience.

Describing impact in code: performance, users, tests

The difference between an average and a strong software engineering bullet is usually whether it says what changed. Engineers think in measurable effects, so describe your work the same way. Useful dimensions include:

• Performance: latency, load time, query time, memory use, build time. "Reduced the search endpoint's median response time from 900 ms to 220 ms by adding a composite index and caching popular queries in Redis."
• Users and usage: how many people used it, how often, who. "Built an internal dashboard in React used daily by the support team to look up order status."
• Reliability and quality: test coverage, bugs fixed, incidents prevented, uptime. "Added 85 unit and integration tests with pytest, raising coverage of the billing module from 40% to 78% and catching two rounding bugs before release."
• Scale: amount of data processed, requests handled, records migrated. "Wrote a Python ETL job that migrated 1.2 million customer records to PostgreSQL with zero data loss in validation checks."
• Developer time: automation that saved effort. "Automated deployment with GitHub Actions, cutting a manual 30-minute release process to a single merge."

A simple formula for each bullet: action verb, what you built or changed, the technology, and the result. Weak versions describe tasks; strong versions describe outcomes.

• Weak: "Fixed bugs in the mobile app."
• Strong: "Fixed 12 crash-causing bugs in a React Native app by adding null checks and error boundaries; none of those crashes reappeared in the team's crash monitoring after the next release."

Only use numbers you can stand behind. If you do not know the exact figure, describe the scope ("for all new user sign-ups") rather than inventing a percentage. Interviewers frequently ask how you measured something, and a confident, honest answer is worth more than a big number.

Coursework and education details

Relevant coursework is useful when you have limited experience, because it puts real technical terms on the page. Pick four to six courses that match the role: Data Structures, Algorithms, Operating Systems, Computer Networks, Databases, Machine Learning, Software Engineering, Computer Architecture. Use the course names, not just codes; "CS 3110" means nothing outside your school.

Include your GPA if it is 3.0 or higher or if the employer asks for it. Many big tech application forms ask anyway, so leaving it off the resume does not hide it. List honors, scholarships and relevant minors such as mathematics or statistics.

Once you have an internship or two, coursework can shrink to a single line or disappear, and for a new grad software engineer resume, Experience often moves above Education.

Check the resume against the posting, then tailor it

Software postings vary a lot in their requirements, even for roles with the same title. Before you submit, upload your resume to the free ATS resume checker and paste in the posting. It reads your file in the browser, flags layout and section problems and shows which of the posting's languages, frameworks and requirements your resume already covers, so you can see the gaps you might honestly fill.

When you are applying to many roles, StudentCV can handle the rewriting. Upload your resume or LinkedIn profile, or type in your projects and experience, then paste the job posting. The AI rewrites your summary, bullets and skills for that role in a clean, one-column template, using the posting's terms only where they match your real work. You can see and edit the whole resume for free before paying, then download a PDF or Word file with an ATS score against the posting. No resume guarantees an interview, but a clear, well-matched one makes sure your code gets looked at.