Visibility
Software engineer portfolio website
A portfolio website does one job: let a stranger verify your work in a minute. Most engineer portfolios are built to impress a designer and forget to prove anything to an engineer.
3 min read
Do you need one?
Not always. An engineer with a strong CV, a clear LinkedIn profile and a well-known employer will get interviews without a site. A portfolio earns its place when your best work is not visible from those: freelance and contract work, side projects, open source, apps in the stores, writing, or a career change where the CV alone undersells you.
If you work independently, it is not optional. The site is the storefront, and clients will judge it the way they will judge your work.
The minute a hiring manager spends
When I open a candidate's portfolio, I am checking three things, in this order. What does this person claim to be good at. Is there work that proves it. Is there anything that contradicts the CV. That takes about a minute, and the page either answers those questions near the top or it does not.
| They look for | Put it here |
|---|---|
| What you do and at what level | One sentence at the top of the home page |
| Proof | Three case studies, linked from the first screen |
| Consistency with the CV | The same roles, dates and claims |
| A way to reach you | Email and LinkedIn, visible without searching |
If the first screen answers all four, the rest of the portfolio gets read. If it answers none of them, the minute ends there, however good the work behind it is.
Case studies, not screenshots
A grid of app screenshots proves that an app exists. It does not prove what you did. A case study does, if it has the parts an engineer cares about.
- The problem, in one or two sentences.
- Your role: what you owned, what the team did, what you decided.
- The decision: the options, the one you chose, and why.
- The result: what changed, with a number where you have an honest one.
- What you would do differently. This line does more for credibility than any metric.
Three case studies are enough. A fourth usually dilutes the first three.
A case study, written out
One complete example, so the shape is concrete. It is illustrative, not a real project, and it is about as long as a case study should be: a reader finishes it in two minutes.
| Part | Example |
|---|---|
| Title | Offline checkout for a grocery app |
| Problem | Orders placed in stores with weak signal failed at payment, and 4% of carts were abandoned at that step. |
| My role | I led the iOS side with one other engineer; backend changes were another team's, agreed through an API proposal I wrote. |
| Decision | Queue the order locally with an idempotency key and confirm when the network returns, instead of blocking the checkout screen. We rejected retrying in place because it double-charged on flaky connections. |
| Result | Payment-step abandonment fell to 1.5% over the next quarter; no duplicate charges in the first 40,000 queued orders. |
| What I would change | I would have added the queue depth metric on day one. We found a stuck-queue bug from a support ticket instead of a graph. |
Notice what carries the weight: the rejected option, the number with its time window, and the honest last row. A screenshot of the checkout screen adds nothing to any of them.
What the home page holds
- First line: "Senior iOS engineer. I build offline-first commerce apps." Role, level, specialty.
- Below it: three case study cards, each with the problem in one line and the result in one number.
- Then: two or three pieces of writing, linked by title.
- Last: email, LinkedIn, GitHub. Nothing else in the footer.
Side projects that help
The side projects that help are the ones with real users, real constraints or a real decision behind them: an app in the store with reviews, a library with issues from strangers, a tool you built because work needed it. Tutorial clones (the to-do app, the weather app) do not help past the first job; if they are all you have, write about one decision you made building them rather than listing them.
Writing on the site
A few pieces of writing about real engineering decisions make a portfolio stronger than any design choice. They show how you reason, which is the thing interviews spend hours trying to find out. Personal branding for software engineers covers what to write.
Design and technology
Keep it plain and fast. A portfolio that takes four seconds to load on a phone, or animates every section, tells an engineer something about your priorities. A static site generator on a cheap host is enough. Use your own domain; it outlives any platform.
Test it the way a reader meets it: on a phone, from a link in a LinkedIn message, on a slow connection.
What to leave out
- Skill bars and percentages. "Swift 90%" means nothing and invites the question of which 10% is missing.
- Every technology you have touched. Name the ones the case studies use.
- Confidential employer details and screenshots of internal tools.
- A photo carousel, a testimonials slider and a newsletter pop-up. None of them is evidence.
- Anything the CV contradicts.
Portfolio checklist
- The first sentence says what you do and at what level.
- Three case studies, each with your role, a decision and a result.
- Links to real work: store listings, repositories, published writing.
- Roles, dates and claims match the CV and LinkedIn.
- Email and LinkedIn visible on every page.
- Loads fast on a phone.
- On your own domain.
Take the free Engineer Visibility Score to see how your public evidence reads today. The LinkedIn profile guide covers the page most hiring managers open first. If you want the CV, LinkedIn and introduction rewritten around your work, that is The First Screen.
