Your first software engineering resume may draw on projects, coursework, an internship, or work in another field. The task is to make your own contribution clear: what you built, how you tested it, and what you learned about the engineering decisions involved.

This guide uses a fictional graduate resume to explain section order, project evidence, internship bullets, and terminology. Use the target posting to choose relevant evidence; a keyword list or scanner score cannot establish whether an employer will shortlist you.

Make it easy to understand the work you can do and the evidence behind it. For an early-career applicant, three useful priorities are:

Read each role's requirements rather than assuming every junior job accepts the same background. Internships, projects, coursework and other work can demonstrate data structures, testing, version control, debugging and collaboration. Explain those contributions accurately, including when you worked under supervision.

This is a fictional teaching example set in September 2024, after a graduate's summer internship. The person, organizations, academic record, certification, projects and outcomes are illustrative. The summary and experience below describe the same work. Copy the structure only; replace every claim and contact link with your own information.

Select relevant languages, tools and engineering practices from the posting, then connect them to projects, coursework or work you can explain.

Add only the terms that describe work you have actually done, and put each one inside a line that shows the result. To check a specific posting rather than this general list, run it through the free resume keyword scanner, or see the full resume keywords by job title.

One focused page is a useful starting point for a short work history. A second page can be reasonable when relevant work, a career change or substantial projects need the space. Keep text readable and trim repetition before cutting your strongest evidence.

The following order is one option. Adjust it to emphasize the most relevant evidence you have:

If your projects are stronger than your internship, put them first. If you have substantial relevant work, let Experience lead. There is no automatic section-order change on a graduation anniversary.

Use clear headings and selectable text. A single column is a practical starting point; Greenhouse identifies columns, complex tables, and document headers as possible parsing problems. Follow the employer's requested file type, inspect the export and check any fields populated after upload.

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 or specific enough to distinguish your work.

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 stronger version is an illustrative rewrite, not a real candidate's verified history. It shows how a summary can connect a credential, a contribution and a relevant stack. Keep only the facts you can support. If a summary repeats the rest of a very short resume, you can use that space for evidence instead.

Education can appear near the top when it is central to your application. Include the details that help explain your preparation:

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 experience, including supervised work. Instead of listing only things you encountered, explain your contribution: what you built or investigated, the tools used, and the result or decision. Give the most relevant work enough detail without forcing a fixed bullet count.

The following before-and-after examples are fictional. Replace their scope and measurements with your own evidence.

A useful internship bullet makes your role in the team clear. Distinguish implementing a feature from helping test it, and name practices such as code review or CI when you used them. An approximate time saving still needs a measured basis. If you cannot recover it, describe the change or count verifiable work without implying that pull-request volume measures quality.

Campus development, freelance work, volunteering and research can also demonstrate engineering. Label the relationship accurately and share only details you are allowed to disclose.

Projects help show how you approach engineering when your work history is short. Choose a few relevant examples rather than filling space with every assignment.

For each, name its purpose, stack, dates, your contribution, and a useful result or technical decision. A public repository or demo can help, but private or team work can be described with permission and clear attribution. Document setup, tests and limitations for anything you link.

The following project bullets are illustrative:

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.

This table is a vocabulary guide, not a measured survey of junior job postings. Check the responsibilities in your target job and select the terms that describe your work. Roleframe can help compare that evidence with a posting; its suggestions do not reveal an employer's hidden filters or predict selection.

Use recognizable names when they describe your experience. For example, a bullet about automated builds and deployments can mention CI/CD if that is what the workflow does. Do not insert a practice such as test-driven development just because it appears in the posting.

ATS products and employer configurations differ. Greenhouse documents automatic rejection rules based on application-question answers, which is different from a universal resume keyword score. Tailor your evidence and answer the application questions accurately.

Group technical skills into useful categories such as Languages, Frameworks and Libraries, and Tools. Keep the list short enough to scan and include skills you can explain through actual work. There is no universal item count.

Support interpersonal skills with examples of communication, collaboration or ownership. These illustrative bullets show the kind of evidence to use:

These examples explain what collaboration or ownership looked like in practice. Replace them with your own work and keep team outcomes separate from what you personally contributed.

Import your PDF into Roleframe and check that names, dates, sections and bullets were parsed correctly. Compare a version with a junior SWE posting, then review suggestions before editing. AI and document allowances depend on your plan. The assessment supports your review; it is not an employer's ATS score.

For a manual start, use the free resume editor with no account and PDF export. Inspect the final document and verify every factual claim before applying.