SOFTWARE ENGINEER RESUME PROJECTS
Should an Older Software Engineering Project Stay on Your Resume?
Keep an older project if it still gives a stronger, relevant example of a technical decision you can explain than the newer item that would take its space. Remove or shorten it when newer work proves the same capability more clearly.
- 1Role matchWhich entry better explains a skill or system boundary relevant to this application?
- 2Your decisionWhich entry lets you name a choice you made, rather than just a tool you used?
- 3Evidence you can showWhich entry has a working artifact, test, design note, or outcome you can accurately explain now?
Keep the older entry only if its distinct evidence wins enough of this comparison to justify the space.
Compare replacements, not calendar dates alone
An old project can still be the only entry that shows a relevant design choice. A recent project can be little more than a list of familiar tools. Start with the job you are applying for, then ask what each entry helps a reader understand about your work. This is an editing decision, not a claim about how any employer scores project age.
Write the proposed replacement beside the old entry. If both demonstrate the same skill, keep the one with clearer personal scope and checkable evidence. If the old entry shows a different capability the rest of the page lacks, it may earn a short line even when it is not your newest work.
Make a retention decision in four passes
- Name the reason it is here. In a few words, identify the target-role question the project answers: API validation, data modeling, deployment, interface state, or another specific boundary. A project with no clear role connection is a candidate to cut.
- Check ownership and recall. Explain the choice you personally made, the constraint, and what you would do differently. If you no longer remember enough to defend a claim, narrow the claim or remove it.
- Find a trace. A repository, test case, screenshot, design note, or accurately described behavior can help you reconstruct the work. A dead link does not invalidate a genuine project, but do not describe an unavailable artifact as live.
- Trade against a specific newer entry. Ask what disappears if you replace the old project. Keep it if that lost evidence matters more for this role; shorten or cut it if the newer entry covers the same ground better.
A fictional replacement decision
The entries below are fictional editing examples. Their project details and decisions are illustrative, not real candidate results.
| Candidate entry | Distinct evidence | Decision for a backend role |
|---|---|---|
| Older class scheduling API: designed conflict checks and wrote tests for overlapping reservations. | A concrete validation rule, an owned implementation choice, and tests the candidate can explain. | Keep a short version if current work does not show comparable API logic. |
| Newer landing page: assembled components and adjusted colors. | Recent activity, but little backend evidence in this description. | Do not replace the API entry solely because this one is newer. |
| Newer service project: implemented reservation validation with clearer ownership and maintained tests. | The same capability with more current, explainable evidence. | Use this newer entry and remove the repeated older project. |
For a front-end role, the comparison could change if the landing page entry actually documents an accessibility or state-management decision. Rewrite the real facts first, then make the slot choice. Never add a measurement or maintenance claim that you cannot verify.
When the old project stays, make its value obvious
Give the reader the technical boundary and your action before a stack list. For example, a truthful entry might say what input the system rejected and which test covers that behavior. Include a date if dates are part of your project format, and be ready to explain what has or has not changed since then. If the link is archived, label it accurately.
When the old project loses the comparison, remove the repeated entry rather than shrinking every project line to fit. The project-slot guide helps compare several projects; the no-metric bullet guide helps describe the one you keep without inventing a number.
Questions about older projects
Is there an age after which a project must come off my resume?
No universal age cutoff follows from this editing method. Compare the older project with the evidence that would replace it for the role you want.
Can I keep a student project after gaining work experience?
Yes, if it still shows a distinct relevant decision that your work entries do not show. If a work example proves the same point more clearly, use the work example.
What if the old repository is unavailable?
You can describe work you actually did if you can still explain it accurately. Do not link to a missing artifact or imply the project is still running.
Should I keep both old and new projects if they show the same skill?
Usually the duplication is the first space to review. Keep both only if each adds a different, relevant decision or artifact that the other cannot show.