What a software engineer
portfolio should include.
A software engineer portfolio should lead with the systems and services you actually built, not a list of languages, and pair each one with a number: requests per second served, latency you cut, users supported, cost you saved. Show a curated GitHub with a few pinned repositories that have readable READMEs, name your stack plainly, and link live systems where you can. It must never contain employer-owned or proprietary code, secrets, API keys, or anything under an NDA. Below is the full list of what to put in, the terms a hiring manager and their applicant tracking system actually search, and which of the Portfolio designs suit a technical CV.
The sections an engineer portfolio needs.
Engineers are hired on evidence they can build and ship systems that hold up under load. Organise the portfolio around that proof. Work through these in order, and read the flagged block twice.
Systems you built, stated first
Lead with two or three systems or services you designed and shipped: a payments pipeline, a search index, an event queue, an internal platform. Say what problem it solved and who used it. A reviewer wants to see you own a system end to end, not that you know a syntax.
Scale and impact metrics
Put a real number on each project. Requests per second handled, p99 latency reduced from 800ms to 120ms, 40,000 daily active users served, a batch job cut from six hours to twelve minutes, infrastructure cost reduced by a stated percentage. Numbers are what separate your page from a syntax tour.
A curated GitHub, pinned
Link a GitHub profile with three to six pinned repositories, each with a README that explains what it does, how to run it, and one design decision you made. A reviewer will open one repo, read the README, and skim the commit history. A clean, documented repo beats a hundred unread ones.
Architecture and tradeoffs
For at least one project, show the shape of the system and why you built it that way. Why Postgres over a document store, why you sharded when you did, what you gave up for consistency. A diagram and a paragraph on the tradeoff you accepted signals senior thinking more than any feature list.
The stack, named plainly
State the languages, frameworks, data stores, and cloud you work in: Python, Go, TypeScript, React, Node.js, PostgreSQL, Kubernetes, AWS. Group them so a reader sees your depth, and be honest about what you have shipped versus tried. These are the exact terms a screen indexes.
Open source and live links
List any merged open-source contributions with a link to the pull request, and link deployed systems a reviewer can actually load, a live demo, a public API, a running side project. A working link that responds is stronger evidence than a screenshot of one.
Never include: employer code, secrets, or NDA work
Do not publish proprietary or employer-owned source, internal architecture diagrams, database schemas, or anything covered by an NDA. Do not paste API keys, access tokens, connection strings, or any credential, and scrub any config or example that carries a real endpoint. A leaked key on a public page is a security incident and can cost you the offer.
Rewrite employer work as described outcomes in your own words: "built the service that ingested 2M events a day" is safe. Link only personal repositories you own the rights to, and if a side project touched a former employer's data or code, leave it off.
Terms a hiring team searches.
Recruiters and engineering hiring managers filter their applicant tracking system for specific technologies and competencies. If these are true of you, use the exact words, because a system indexes the words you wrote, not the ones you meant.
Paste your resume into the free ATS score checker with a real engineering job posting to see which of these terms the posting uses and your resume is missing.
Which designs suit a technical CV.
Engineering hiring reads projects and impact, so the design should be clean and technical, not decorative. Of the 60 Portfolio designs and 48 resume layouts, these are the shapes that fit.
Engineers can use one of the project-grid designs that puts each system in a card with its stack, a metric, and a repo link. It reads the way a reviewer scans: what did you build, how big was it, can I see the code. Skip the heavy photographic designs.
Of the 48 resume layouts, choose a single-column one rather than a two-column design. Multi-column resumes can serialise into a scrambled reading order when a company's system parses them, which is the last thing you want on a screened application.
Order the sections so your strongest systems and their metrics come before the biography. A reviewer decides whether to keep reading in the first fifteen seconds, so put the work that earns that time at the top.
Use a restrained palette, a monospace accent for stacks and repo names, and generous whitespace. A clear technical look reads as an engineer who cares about clarity, which is exactly the signal you want to send.
Who an engineer portfolio is not for.
A portfolio helps some engineers and is almost invisible to others. Read this before you spend a weekend building one, because for a large share of roles a strong GitHub and a parsable resume do most of the work.
Worth building if you
- +Have shipped side projects or open-source work you can show, and want one link that frames them with the stack and the impact.
- +Are early in your career or self-taught and need a place to prove you can build, beyond a resume line.
- +Are a frontend, full-stack, or developer-experience engineer where a live, well-built site is itself a work sample.
- +Want to control the narrative around employer work you cannot link, by describing outcomes in your own words.
Skip it, for now, if you
- −Have a strong GitHub with pinned, documented repos that already tells the story. Link that and move on.
- −Are applying through large-company portals that never surface an external link, where a parsable resume gets read.
- −Cannot show any work without touching employer code. Do not publish it, an ATS-clean resume is safer.
- −Have a deadline. Spend the time making your resume machine-readable and your top repos clean, then build the site.
Questions engineers ask.
Straight answers on GitHub, projects, impact, and whether the effort is worth it.
Do I need a portfolio if I already have a GitHub?
Not always. A GitHub with a few pinned, documented repositories often does the job on its own. A portfolio earns its place when you want one link that frames those repos with the stack, the scale, and the impact, or when you have employer work you can describe but cannot link. If your GitHub already reads well to a stranger, lead with it.
What projects should I show?
Two or three systems you built end to end, chosen for what they prove rather than how new they are. A project that handles real load, integrates two services, or solves a concrete problem beats a tutorial clone. For each, say what it does, name the stack, and attach one number. Depth on a few projects reads better than a long list of unfinished ones.
Should I link a monorepo or pinned repos?
Pin three to six individual repositories on your GitHub profile rather than pointing at one large monorepo. Pinned repos let a reviewer open exactly the work you want them to see, each with its own focused README. A monorepo forces them to hunt for the part that matters, and most will not.
How do I show impact without leaking employer data?
Describe outcomes in your own words and keep the numbers at the level of results, not internals. "Built the ingestion service that handled 2M events a day and cut processing time by half" is safe and specific. Do not publish internal diagrams, schemas, source, or anything under an NDA, and never paste a credential or a real endpoint.
Does a portfolio help with take-homes or system-design interviews?
Indirectly, yes. A portfolio that shows a real system and the tradeoffs you made is a preview of how you will reason in a system-design round, and a clean repo signals how you will approach a take-home. It does not replace either, but a reviewer who has seen your architecture write-up walks into the interview already believing you can build.
Where to go next.
Build the site, test your resume, or read how the paste-a-resume flow works.
Turn your engineering
resume into a site.
Paste your resume and Portfolio drafts a clean, project-led website in about a minute. Systems and metrics up top, pinned repos linked, no employer code or secrets anywhere, published to your own domain with TLS handled for you.