The hardest resume you will ever write is your first one. You have an internship or two, a handful of projects, a degree that is not finished or barely is, and you are competing against hundreds of applicants for every junior opening. The recruiter screening that pile spends seconds per resume, and before a human even looks, an applicant tracking system (ATS) has already parsed yours and matched it against the posting's keywords.

The good news: most entry-level software engineer resumes are bad in the same fixable ways. They bury projects at the bottom, describe internships as coursework, list twenty technologies with no evidence for any of them, and open with a summary that says "passionate about coding." Fix those four things and you are ahead of most of the pile. This guide shows you how, with a full example resume and the specific keywords junior software engineer postings filter for.

A recruiter reading a junior software engineer resume is answering one question: can this person write production code, or have they only followed tutorials? Everything on the page should feed that answer.

Three things separate the resumes that get callbacks from the ones that don't:

Notice what is not on that list: a long work history. Nobody expects one at this level. What hiring managers expect is proof that the fundamentals stuck (data structures, version control, debugging) and that you can function on a team. Your internships, projects, and coursework carry that proof if you frame them right.

Here is a complete example for a recent computer science graduate moving from an internship into a full-time role. Read it once top to bottom, then come back to it as each section below explains the choices it makes.

One page. At this experience level there is no debate: a second page signals that you cannot prioritize, which is itself a negative signal for an engineer. If you are fighting for space, cut older coursework and shrink the skills list before you touch projects or internship bullets. There is a fuller breakdown of the one page vs. two page question by experience level if your situation is unusual.

Section order matters more for you than for a senior engineer, because your strongest material is not your work history. The order that works for most entry-level candidates:

If your projects are stronger than your internship, put projects above experience. The rule is simple: your best evidence goes highest on the page. The right resume section order shifts with what you have, and moving a section should take seconds, not a rebuild.

Keep the formatting itself boring. Single column or a simple two-column layout, a standard readable font, no headshot, no skill bars, no icons in place of section names. ATS parsers have improved, but a plain structure with clear section headings ("Experience", "Education", "Projects", "Skills") still parses most reliably. Save and submit as a PDF, which locks your formatting in place; only send anything else if an employer explicitly asks for it.

The default junior summary is "Passionate and motivated computer science graduate seeking to grow as a software engineer." It says nothing a recruiter can verify and nothing that distinguishes you from the other four hundred applicants who wrote the same sentence.

A summary that works at this level does three things in two or three lines: names your strongest credential, points at one concrete thing you built or shipped, and names the two or three technologies most relevant to the posting. Compare:

The strong version is longer, and every extra word is a fact. It also front-loads keywords the ATS and the recruiter are both scanning for. If you are deciding between a summary and an objective statement, the short answer is that a specific summary wins for almost everyone; the summary vs. objective breakdown covers the exceptions. And if you have no internship at all, there are summary examples for candidates with no experience that show how to lead with projects and coursework instead.

While you are within roughly two years of graduating, education sits above experience and earns more than the usual one line. Include:

If your route was a bootcamp rather than a degree, the same logic applies: it goes in education, with the program name, dates, and the stack you built in. There is a dedicated guide on how to put a coding bootcamp on your resume. A capstone project, whether from a degree or a bootcamp, usually earns its own entry in the projects section rather than a line under education, and listing a capstone project the right way makes it read as engineering work instead of homework.

An internship is real experience. The mistake juniors make is writing it like a syllabus: "Learned about agile development. Assisted the team with various tasks. Gained exposure to AWS." A recruiter reads that as "watched other people work."

Write internship bullets the way a full-time engineer would write theirs: action verb, what you built, the technology, and the outcome. Three to five bullets per internship is the right range. The transformation looks like this:

The "after" versions do double duty. They prove production habits (code review, CI, sprints) and they plant the exact vocabulary ATS filters scan for. If you don't have a precise number, use an honest approximation ("roughly a third") or a countable fact (14 pull requests, 12 weeks). Counting your own merged PRs takes five minutes and gives you a number no one can dispute.

Part-time technical work counts here too: a campus web dev job, freelance sites for local businesses, a research assistantship where you wrote analysis scripts. If you wrote code someone else depended on, it belongs in experience.

For a candidate with under two years of experience, projects are where interviews are won. This is the section that answers "can they actually build something" when the work history can't yet.

Two or three projects, each with a name, a one-line description of what it does and who it is for, the tech stack, and one or two outcome bullets. The bar for a project that helps you: it is deployed somewhere a stranger can use it, or the code is public and readable. A live URL or a GitHub link turns a claim into evidence. Put your GitHub link in the header as well, and make sure the pinned repos are the ones you would want an interviewer to open.

What separates a strong project entry from a weak one:

Tutorial projects are fine as a starting point, but push each one somewhere the tutorial didn't go: add auth, write tests, deploy it, get one real user. That last mile is the part that reads as engineering. The full guide on how to list coding projects on a software engineer resume goes deeper on choosing and writing them up.

Roleframe's fit reports work by reading real job postings the way a recruiter does and matching a resume against the exact terms each posting filters on. Across junior and entry-level software engineer postings, the same terms come up again and again, and they cluster into predictable groups. These are the keywords worth checking your resume against before you send it:

Two rules for using this table. First, match the posting's exact wording: if the job says "RESTful APIs," write "RESTful APIs," and if it says "CI/CD," don't paraphrase it as "automated deployments." ATS keyword matching is more literal than people expect. Second, never list a keyword you can't back in an interview. A keyword in your skills list with no supporting bullet anywhere on the page is a red flag to a technical reviewer, and an invented one is worse. The broader mechanics are covered in how ATS resume keyword matching actually works.

The keywords also shift by posting. A junior role at a data-heavy company weights SQL and Python; a product startup weights React and shipping speed. This is why one static keyword list only gets you so far, and why checking your resume against each specific posting beats optimizing for the average.

Your skills section should be almost entirely hard skills, grouped so a skimmer can parse it in two seconds: Languages, Frameworks & Libraries, Tools & Platforms. Eight to fifteen items total. A wall of thirty technologies signals padding, and any technical interviewer will probe the weakest item on the list, so only list what you can discuss.

Soft skills belong on your resume, but never as a list. "Communication, teamwork, problem-solving" as skills-section entries is dead weight; every applicant claims them and none can be verified from a list. Instead, demonstrate them inside experience and project bullets:

Hiring managers for junior roles weight soft skills heavily, because they are hiring for trajectory rather than current output. They just don't trust the word; they trust the story. The hard vs. soft skills guide covers how employers actually screen for each.

If you already have a resume, don't retype it. Upload the PDF to Roleframe and it comes back as editable blocks, with your roles, dates, and bullets in place, and an analysis already run so the first thing you see is a scored document with its weak sections named. From there, the workflow matches how this guide says to apply: keep one base resume, and for each job, duplicate it and paste the posting to get a fit report that shows your ATS score, the exact keywords that posting asks for that you are missing, and a prioritized plan. Then you make the edits yourself, with Remi, Roleframe's career copilot, proposing rewrites bullet by bullet that you approve or discard. Nothing lands on the page without your sign-off, which matters when a technical interviewer is going to probe every line.