SOFTWARE ENGINEER RESUME PROJECTS
How to Describe a Software Engineering Project When the Repository Is Private
State the project’s problem and your own technical contribution, then link only to a demo, design note, or artifact you are allowed to share. If nothing is public, say so accurately rather than implying that a reviewer can inspect private code.
- 1Public demoLink a live, non-confidential demo only if it represents the work accurately and may remain public.
- 2Sanitized artifactUse a short design note, screenshot, or test description only after removing confidential names, data, and implementation details.
- 3Accurate explanationWhen no artifact can be shared, describe the boundary you worked on and be ready to explain it without claiming that code is available.
Do not create a public repository, screenshot, or link merely to fill a resume slot. Accuracy comes before visibility.
Separate the project from the proof you can publish
A resume can describe work that is not publicly accessible. What matters is whether the wording is accurate, scoped to your contribution, and something you can discuss. Start with the technical problem and the decision you made. Treat a repository link as one possible artifact, not as proof that every genuine project must be public.
Do not write “GitHub available on request” if the code cannot actually be shared. Do not turn a private company, client, class, or team repository into a public sample without permission. A short honest boundary is more useful than a link that exposes someone else’s work.
Use the shareable-proof ladder
- List what is genuinely public. A demo, deployed personal version, public documentation page, or independent test fixture may be shareable. Confirm that it reflects your actual contribution before linking it.
- Find what can be safely summarized. If an artifact cannot be public, describe the system boundary, constraint, and your owned action in a few precise words. Remove names, credentials, customer data, and implementation details you do not have permission to disclose.
- Label the limitation plainly. If a repository is private, do not attach a broken or placeholder link. You can say “repository private” only when that is true and when the rest of the bullet still stands on its own.
- Prepare the conversation version. Be ready to explain the constraint, trade-off, test, review, or handoff without revealing code or confidential information. Narrow any claim you cannot explain accurately.
Fictional examples: keep the boundary visible
These are fictional editing examples. They show how a resume line can stay specific without disclosing code, clients, or data.
| Avoid | More accurate direction | Shareable proof, if permitted |
|---|---|---|
| Built a confidential payments system; see GitHub. | Implemented input validation for an internal payments workflow; repository is private. | A sanitized description of the validation boundary, not customer records or source code. |
| Created a company dashboard that increased revenue. | Worked on a dashboard view that surfaced existing team metrics; describe only the view and your owned component. | A generic mock-up only if it does not reproduce company data or design assets. |
| Designed a private API used by many teams. | Documented one API error-handling decision and reviewed the handoff with the service owner. | A non-sensitive design note if its owner allows it; otherwise an accurate verbal explanation. |
When no link is safe, do not compensate with an inflated result. The no-metric project-bullet guide explains how to keep a technical action concrete without inventing a number, while the team-project guide helps separate your work from shared outcomes.
Decide whether the private project still earns the space
A non-public project can still be a strong resume entry when it reveals a relevant decision you can explain. Compare it with the project that would replace it: which one gives a clearer role match, owned action, and honest evidence? The answer may be a short private-project line, a public project, or a different work example.
Never imply that an interviewer may inspect a repository unless you are authorized to provide access. If the project is confidential, keep the boundary explicit and focus on what you can truthfully discuss.
Questions about private repositories
Can I include a project without a GitHub link?
Yes. Describe your real contribution accurately and link only to artifacts you are allowed to share. Do not add a placeholder link.
Should I say that the repository is private?
You can state that limitation when it clarifies why no code link appears. The project description should still stand on its own.
May I show screenshots from a private project?
Only if you have permission and the image does not reveal confidential names, data, credentials, or implementation details. When uncertain, do not publish it.
What if the project cannot be discussed in detail?
Use a narrower, non-sensitive description or choose another evidence source. Do not make a broad claim that depends on information you cannot explain.