Building a developer portfolio that a reviewer will actually read

An engineering reviewer opens a portfolio looking for one thing: evidence that you have shipped something real and can say what it cost. Everything else is scenery.

ConxfolioPublished 2026-09-12

— the repository is the proof. The page is the index.

Engineering portfolios fail in a specific way. They list technologies, link repositories, and leave the reader to reconstruct what the person actually did. A reviewer with forty candidates does not reconstruct anything; they read the first outcome line and decide whether to open the link.

So the page has one job, which is to make three or four pieces of work legible fast enough that the repository gets opened at all.

What an engineering reader is looking for

• Did it ship. Something that ran, that other people used, that had consequences when it broke.
• What was the constraint. Latency, cost, correctness, a deadline, a team of two. Work without a constraint is a tutorial.
• What changed. A number if one exists, and a plain statement if not.
• What you chose and why. The reasoning is the part a repository cannot show.

Four short entries in that shape outperform a page listing fifteen technologies, because a reviewer can use them.

Write the outcome line first

The builder defines a project as a name, a year and one line about what changed, and that line is the whole entry for scanning purposes. "Rebuilt the settlement pipeline, cutting end-of-day reconciliation from forty minutes to six" does more work than a paragraph of architecture, and it invites the exact question you want to be asked.

Where a figure genuinely does not exist, describe the change in plain terms: a process that used to need two people now needs none, a failure mode that used to page somebody at night no longer does. Finding the number covers the cases where one is hiding.

What stays in the repository

The code, obviously. Also the setup instructions, the architecture notes, the benchmark output and everything else a reader will want only after they have decided you are interesting. Putting that material on the page pushes the outcomes below the fold, where nobody scrolls.

Each entry in the details sheet takes a link, so the page can carry a repository address per project without carrying the repository.

Which designs suit this

The portfolio builder opens on a gallery of 20 authored pages grouped into 6 directions, with a filter along the top. The Technical direction holds five of them: Studio Quiet Builder, a quiet builder studio; Control Room Corridor, an operational control-room journey; Vantic, a cinematic product runbook; Queuewell, a kinetic queue board; and System Proof, a technical evidence system.

Those are not the only reasonable choices. Grey Drift and Ink & Paper carry engineering material perfectly well, and a quiet page is never the wrong answer for work that is itself quiet. The filter exists to shorten the browsing, and each card opens full screen at desktop and phone width before you commit. You can see the whole set at portfolio designs.

The case-study entry

For one or two projects it is worth filling the details panel properly: the situation, the constraint, what you built, what changed. This is the entry a reviewer reads when they have decided to spend five minutes rather than twenty seconds, and it is where a repository link belongs. Writing a case study covers the shape.

Two of those are enough. A page where every entry is a case study is a page nobody finishes.

Skills, kept short

The skills section takes chips and should stay under a dozen. A long list reads as a keyword field and is discounted as one, whereas a short list of things you would be happy to be tested on reads as a claim. The same reasoning applies to the résumé's skills section, where the list has a different job and a similar limit.

Then check it at both widths

The step before publishing renders the real page at desktop and phone. Engineering pages suffer more than most from long entry names and wide code-like strings, and the phone view is where that shows up. Fixing it is usually a matter of shortening a title rather than changing anything structural.

Publishing claims an address of the form conxfolio.com followed by the handle you choose, and asks for a one-time code sent to an email address. Everything before that point needs no account at all.

What to do about work you cannot show

Most production engineering is behind a private repository, and a page that only carries public work misrepresents the job. The entry still works at one level of abstraction up: the kind of system, the constraint, the change, without the code and without the employer's internal names.

"Cut a nightly batch from four hours to twenty minutes by partitioning the ledger" is publishable where the repository is not, and it invites exactly the conversation you want. What is not acceptable is publishing material your employment agreement covers, or implying a link exists where it does not. A proportion instead of an absolute is usually the safe form and it is still evidence.