Entry Level Software Engineer Resume Examples

An entry level software engineer resume is one page, single column, and built from four sections: Education, Experience (internships, co-ops, TA or research work), Projects, and Technical Skills. The order of those sections depends on what your strongest evidence is. If you have an internship, it goes near the top. If you don't, your projects do the work an internship would.

Below are five complete example resumes, one for each of the most common starting points. The people and companies are made up and so are the numbers; the structure and the kind of evidence in each bullet are what you should copy.

If you are a new grad and want the longer walkthrough on coursework, GPA, and timing for fall recruiting, the new grad software engineer resume guide covers that. This page is the example library.

Why it works

• Education is first because it is still the fastest way for a reviewer to place him: degree, school, graduation date. It takes three lines, not ten.
• The internship bullets name the system he built and who used it. "Built a dashboard" alone says little; "replaced a CSV export 12 dispatchers filtered by hand" tells you the work mattered.
• The TA role gets one line. It shows he can explain data structures, which helps in interviews, without taking space from the internship.
• One personal project with real users and one hard course project cover two different kinds of proof: shipping something people use, and handling systems concepts.

Why it works

• Three internships with different scopes (payments backend, data pipelines, frontend) tell a reviewer she has shipped code on real teams three times. That beats any coursework list, so Education drops to a single line at the bottom.
• Projects shrink to one entry. It still earns its spot because it shows systems depth the internships don't.
• Each internship has two or three bullets. Older or smaller internships get fewer lines than the most recent one.

Why it works

• Projects move above Experience because they are the strongest software evidence on the page. Each one says what he personally did, which matters most on team projects like a capstone.
• Every project has a detail that only comes from real use: a pilot with 150 students, a user's import file that broke, a maintainer shipping his fix. Reviewers notice those.
• GPA is left off because it is below 3.5. Dean's List says the same thing more favorably.
• The dining job stays as one line. Four years of holding a job while in school is worth showing; it just doesn't need bullets about food service.

For more on making projects carry the page, see how to write a developer resume with no experience.

Why it works

• Projects go first because the reviewer's first question is whether she can build software, and the projects answer it before anything else.
• Pantry Log has real users with a real problem, so the bullets can describe a decision (accounts and edit history) made because of how people used it. A tutorial clone can't do that.
• The retail job keeps the one bullet that involved building a tool, plus one line on managing people. Both are relevant to a software team.
• The bootcamp sits in Education with its length, which is the detail reviewers look for. The B.A. stays because a degree in any field still counts for some employers.

If you taught yourself instead of attending a bootcamp, the same layout works; the self-taught developer resume guide covers that version.

Why it works

• This is the one example with a summary. A career switcher needs two sentences to explain the story; a CS new grad usually doesn't.
• Experience stays first because it is real professional work, and three of the four bullets are software he wrote on the job. The engineering-only work is cut to one line.
• The project is in his own domain, which makes it more believable and gives him something specific to talk about in interviews.

For more on reframing past work, see the career change software engineer resume guide.

For most entry level candidates, Education goes first. Move it lower once your work history is stronger evidence than your degree. A reasonable rule: if you have two or more software internships or co-ops, or any full-time software job, lead with Experience. The Tech Interview Handbook gives a similar cutoff, suggesting Education first for people still in school or with under three years of experience.

A few related placement calls

• Skills at the top or bottom? Bottom is the default. Move it up only when your experience section has no software in it, as in the bootcamp example.
• Summary or objective? Skip both if you are a new grad; the space is better spent on a project bullet. Career switchers are the exception. More detail in should software engineers use a summary.
• Where do TA and research roles go? In Experience. They are real jobs with real responsibility, even if they aren't industry internships.
• Non-tech jobs? Keep recent ones as one line each if you have room. A job you held through school shows reliability; it doesn't need three bullets.

For page length and layout, a one-page tech resume template or our software engineer resume template gives you a clean starting file.

On most entry level resumes, project bullets are where you either look like an engineer or a student finishing assignments. The difference is usually one specific detail: a constraint you hit, a choice you made because of it, and how you know it worked. Numbers help, but only real ones. "Used by 40 people" is better than an invented "improved efficiency by 30%."

If you want a formula, the XYZ method (accomplished X, measured by Y, by doing Z) works well for internship bullets. For projects without metrics, describe the problem and the technical decision instead of forcing a number.

More project ideas and full write-ups are in developer resume project examples.

The skills section is where entry level resumes most often go wrong, usually by listing everything from a semester of MATLAB to a weekend with Rust. Every item is something an interviewer may ask about, so keep it to tools you have used in a project or job on the same page.

• Group by type: Languages, Frameworks, Tools or Infrastructure. Three or four groups is plenty.
• Order each group by how well you know it, strongest first.
• Skip proficiency bars, star ratings, and percentages. They don't mean anything to a reviewer.
• Leave out soft skills ("teamwork", "communication") and generic software (Microsoft Office, Slack, Jira).
• Mirror the job post's spelling where it is honest: if the post says PostgreSQL and you wrote Postgres, use PostgreSQL.

Example skills sections by target role

For a longer list of what to include by specialty, see what skills to put on a software engineer resume.

Recruiters read a lot of resumes built from the same few templates, and copied bullets are easy to spot. Use an example for its structure and its level of detail, then write every line from your own work.

1. Pick the example whose situation is closest to yours and copy its section order.
2. For each of your projects and jobs, write down the facts first: what you built, the stack, who used it, what broke, what you changed, anything you measured.
3. Turn those facts into bullets that follow the pattern in the example. If you don't have a number, use a concrete detail instead of making one up.
4. Read the page with the Skills section covered. If it still reads like a software engineer wrote it, the bullets are doing their job.
5. Tailor the top third for each application type. A backend role and a frontend role should see different first projects.

Expect to be asked about any line in an interview. If you can't talk about a bullet for two minutes, rewrite it or cut it.

The two terms overlap. In job posts, "entry level" usually means no professional software experience expected, while "junior" or "Software Engineer I" often means zero to two years. The resume changes in one way: once you have a software job, it becomes the center of the page.

• Move Experience to the top and give your current job 4 or 5 bullets.
• Cut coursework entirely and reduce Education to one line.
• Keep one or two projects, only if they show something your job doesn't.

If you are deciding how much school detail to keep in your final year, the new grad resume guide goes deeper on that, and the internship resume guide covers resumes for internship applications specifically.

• A projects section full of tutorial apps. A to-do list, a weather app, and a calculator tell a reviewer you finished a course. Keep one if it has a twist, and put your most original project first.
• Team projects with no ownership. "Worked with a team to build" leaves the reviewer guessing what you did. Name your part.
• A skills list longer than your experience. Twenty-five technologies on a resume with two projects reads as padding.
• Two-column templates with icons and skill bars. A single column is faster to scan, puts your best bullets where the reader looks first, and gives a resume parser less to get wrong. See two-column resumes for software engineers.
• A generic objective. "Motivated graduate seeking a challenging role" takes two lines and says nothing.
• Going to two pages. One page is the norm at this level. If you are over, cut coursework, old non-tech jobs, and your weakest project before you shrink the font.
• Dead or empty links. Check every GitHub and demo link before you apply. A 404 on your best project undoes the bullet about it.

More examples of what to fix are in top software engineer resume mistakes.