A Personal Site That Earns the Link

A personal site is a line on your resume that costs a click. It earns that click only if it contains something the resume couldn’t: the reasoning behind a piece of work, at a length a bullet can’t hold.

Most don’t. The common version is a landing page with your name, a short biography, a technology list, and the same three projects that are already on the page the reader just came from. A reviewer who clicks that has spent attention to learn nothing, and the link has cost you rather than helped.

What a site can do that a resume can’t

Show reasoning at length. A resume gives you two lines per idea. A write-up gives you a thousand words, which is enough for a problem, a wrong hypothesis, a diagnosis, and a decision. That is the whole thing interviews are trying to assess, and you can hand it over in advance.

Make internal work citable. Most of your best work is behind a corporate login and always will be. You cannot link the design document, but you can publish the general version of the same problem — the pattern, the trade-off, the failure mode, with the specifics of your employer removed. That is the linkable substitute discussed in design documents, RFCs, and what they show.

Demonstrate that you can write. Technical writing is scarce and correlated with almost everything else the job requires. A page of clear prose is direct evidence in a way that “excellent written communication skills” is not.

Be a work sample in itself. How your site loads, whether it works on a phone, whether it is navigable by keyboard — these are all being observed whether you intended them to be, particularly if you are applying as a frontend or platform engineer. See the frontend engineering resume on that risk.

Publish the reasoning, not the summary

The highest-value thing on an engineer’s site is a piece about something that was hard, written specifically. Five shapes that work:

The debugging story. Symptom, first hypothesis, why it was wrong, what the evidence actually said, root cause, fix, and what you added so it could not recur silently. This is the single most persuasive thing you can publish, because the structure of the story is the skill being assessed.

The decision write-up. Two viable options, the constraints that decided it, and the condition under which you’d choose differently. Short — a few hundred words is plenty.

The measurement. A benchmark you ran, with the method stated and the caveats named. Engineers trust a stated method far more than a conclusion, and publishing the caveats is what makes it credible rather than promotional.

Notes on a tool you built. Why it exists, what it does badly, what you’d change. This reads better than a polished project page, because it sounds like an engineer talking rather than a product.

An explanation of something you had to learn properly. Consensus, isolation levels, TLS handshakes, cgroups, floating point. Only worth publishing if you add something the documentation doesn’t — your own confusion, resolved, is the value. A restatement of the official docs is not.

What to leave off

A restated resume. If your site’s content is your work history, link the resume and skip the site. Two copies of the same document is a maintenance problem and a wasted click.

A skills grid with progress bars. The same objection as on the resume — nobody knows what a four-fifths-full Python bar means, and it is now taking up a screen instead of a line. The tech stack list problem applies here unchanged.

“Hire me” energy. Availability, a rate card, and a call-to-action turn a credibility artefact into an advert. One quiet line on a contact page is enough.

Anything your employer would object to. Unreleased products, internal architecture in identifiable detail, customer names, incident specifics, security details, or numbers that aren’t public. Write the generic version of the problem instead — it is usually the more useful article anyway, and it removes the risk entirely. If you are unsure whether something crosses a line, it does.

Half-finished sections. “Blog — coming soon” and an empty projects page are worse than not having them. Ship a smaller site.

Opinions you’d rather not be interviewed about. Everything on the site is fair game in a conversation. That is mostly a feature; occasionally it isn’t.

How much is enough

Three good pieces. Not thirty.

The value is entirely in demonstrating that you can think and write about engineering, and three pieces prove that as well as thirty do. A site with three substantial write-ups and no filler reads better than one with a long archive of short posts, and it is achievable in a few weekends rather than as a lifestyle.

There is also no requirement to publish regularly. A site with three pieces from last year is not stale; it is a portfolio. The apologetic “I haven’t posted in a while” note at the top is the only thing that makes it look stale, so leave it out.

The technical hygiene, which is being graded

Nobody will say this to you, but engineers do notice.

Fast. Static hosting and no client-side framework is entirely sufficient for a site made of text, and it loads instantly on a train. Readable on a phone. Keyboard-navigable, with visible focus and real headings. Working links. No cookie banner, because there is no reason for one on a personal site made of prose. Text that is actually text rather than an image of text.

An engineer’s personal site is a small system you own end to end, and it is the only one a reviewer can inspect at their leisure. Making it obviously well-built is a cheap signal and making it slow is an expensive one.

Where the link goes, and whether to include it at all

One link in the contact block, next to or instead of the code link. Whether the site or the repository host gets the slot depends on which is stronger — the reasoning in what a link to your code actually proves applies to both.

If a specific write-up is directly relevant to the role, link that piece from the bullet it supports rather than making the reviewer find it. A parenthetical is fine and it is far more likely to be read than a homepage.

And the honest case for not having one: a personal site is optional, it takes real effort, and plenty of strong engineers have none. Judging candidates on unpaid weekend output filters on who has spare time, which most competent hiring teams are trying not to do. If you don’t want to write, don’t — put the effort into the work history instead, where most of the return is anyway.

But if you do have one thing worth explaining at length, this is the cheapest place to put it, and it works on every application rather than one.

The check

Open your site as a stranger and ask what a reviewer learns in two minutes that the resume didn’t tell them.

If the answer is nothing, the site is a duplicate and the link is a cost. One write-up about something that was genuinely hard converts it into the most useful line on the page.