Portfolio, GitHub, Writing, and Public Evidence

What public evidence must accomplish: every link spends trust

A link on a senior engineer’s resume is not decoration. It is an invitation to inspect your judgment.

The person who follows it may find a careful account of a difficult migration. They may also find six abandoned repositories, a grand claim in a README, a broken demo, and an internal hostname left in a screenshot. The link has added information in either case. You do not control how long the reader stays or which clue they treat as representative.

This is why public evidence is optional. Much of the best senior engineering work cannot be published: it belongs to employers and customers, or sits inside regulated, security-sensitive, and private systems. A sparse GitHub profile does not cancel years of production ownership. Nor does a crowded contribution graph establish it.

Share an artifact when it gives a relevant claim somewhere useful to land. If it cannot do that safely, leave it out of the hiring path.

Evidence model: begin with the question you want the artifact to invite

Suppose your resume says that you led a platform migration used by several product teams. A hiring manager could reasonably ask:

• How did you keep old and new clients compatible?
• What made teams adopt the new path?
• Which rollout risks did you own?
• What happened when the migration met a service that did not fit the plan?

Those are good questions. They lead toward senior work. The public artifact’s job is to make one of them more answerable before the interview.

Now consider the material you could share. A small infrastructure repository might display clean code, but it cannot prove cross-team adoption. A technical talk might show how you explain the migration, but not whether you operated it. An open-source patch might show care in review, but it belongs to another system. A sanitized case study could preserve the compatibility decision, rollout sequence, and organizational constraint without exposing the company.

The right choice depends on the claim. For this one, the case study is probably the primary evidence. The repository might remain as narrower evidence of implementation discipline. Asking one artifact to prove both production leadership and code quality would inflate it.

Use three questions before adding any link:

1. Relevance: Which claim in this application does the artifact support?
2. Scrutiny: What can a careful reader actually verify or question here?
3. Permission: Is every disclosed detail yours to publish?

If the first answer is vague, the artifact is noise. If the second is much smaller than your description, narrow the description. If the third is uncertain, do not publish it.

Selection rules: build a packet, not a museum

A portfolio for a senior engineer is often just a short index. It helps a busy reader choose where to spend attention. It does not need animated project cards, an elaborate personal brand, or a complete history of your interests.

For the migration example, the index entry could read:

Moving a shared deployment path without a flag day

Why it is here: a sanitized case study of compatibility and adoption during
a multi-team platform migration.

My role: designed the compatibility contract and rollout gates; partnered with
service owners on adoption. I did not build every migrated service.

Worth inspecting: the rejected flag-day plan, exception path, rollback trigger,
and evidence used to retire the old path.

Boundary: company, service, vendor, and volume details have been generalized.

Who reads the packet and what they infer

That is enough direction. A recruiter can understand the subject. A hiring manager can see ownership and scope. An interviewer has several places to probe. The boundary prevents the sanitized material from masquerading as a complete production record.

Choose one or two artifacts that support the role you are actually pursuing. Three may be useful when they reveal genuinely different strengths. Beyond that, each addition should face a high bar: does it change the hiring team’s understanding, or merely make the portfolio look occupied?

Old work does not have to be deleted from the internet. It only has to stop crowding the path you deliberately share. A tutorial repository can remain part of your history without being pinned. A conference talk can remain online without appearing in a backend application. Curation changes emphasis; it need not rewrite your past.

Before-and-after: a repository at its honest size

GitHub encourages expansive inference. A polished side project is easily described as “production-ready,” and a visible open-source project can tempt a candidate to borrow the project’s stature. Resist both.

A repository can provide strong evidence of how you frame a problem, choose interfaces, test behavior, explain trade-offs, and respond to review. Unless it has actually been operated under production conditions, it does not show what you learned from real traffic, support, incidents, cost, or long-lived ownership.

The README should make that distinction easy. Compare:

A production-grade deployment controller for Kubernetes.

with:

A focused controller that explores rollout state, idempotent reconciliation, cancellation, and recovery after process restart. It does not implement multi-tenant authorization, fleet observability, upgrade compatibility, or an operational support model.

The second account is not timid. It identifies the engineering inside the artifact and the conditions outside it. A reader can inspect the state model, tests, and recovery behavior without being asked to pretend that omitted production work has already happened.

Before featuring a repository, make its first screen answer four questions in plain language: what problem is bounded here, which decisions deserve attention, how can the behavior be tested, and where does the design stop? Then check the repository itself. A thoughtful README cannot compensate for exposed credentials, proprietary examples, a demo that no longer runs, or tests that contradict the claim.

Open source reveals conduct as well as code

A small open-source contribution may be better evidence than a large personal project because another maintainer had to understand and accept it. The value may live in the issue analysis, failing test, compatibility concern, review exchange, or decision not to widen the patch.

Describe that work at its real size:

I reproduced an intermittent timeout, reduced it to a failing test, proposed a change to retry-state cleanup, and revised the patch after maintainer feedback about backward compatibility. I did not design or maintain the library.

This gives the reader something exact to inspect. “Contributor to a major project” does not. A famous repository cannot lend you ownership you did not have, and an unmerged proposal remains an unmerged proposal.

The same discipline applies when the visible artifact is a documentation fix, an issue investigation, or a migration guide. Senior judgment often appears in restraint: preserving an API contract, finding the smallest safe change, or making a confusing boundary legible for the next user.

Writing and talks need a live decision

Technical writing is strongest hiring evidence when it lets the reader follow a consequential choice. A survey of message queues can show knowledge. An account of why a team kept a database-backed queue during a migration can show judgment—if the account makes the constraints, alternative, and consequence visible.

The useful center is rarely the technology itself. It is the moment where two reasonable paths diverged:

• a compatibility layer bought a safer rollout but prolonged old behavior;
• a simpler design reduced operational load but limited future flexibility;
• a backfill improved completeness but created a new reconciliation risk;
• a team’s elegant platform lost to an approach product teams could adopt.

A talk can make the same reasoning inspectable, especially when the slides or recording preserve diagrams, failure cases, and what changed after the original decision. A generic explanation is not worthless, but it supports a smaller claim: you can explain the topic. Describe it accordingly.

Do not manufacture conflict to make the piece dramatic. The actual constraint should create the tension. If there was no production outcome, say so. A design exploration can still be useful when it is labeled as one.

A sanitized case study must survive subtraction

Private work presents the hardest editorial problem. Remove too little and you betray information entrusted to you. Remove too much and the case study becomes a sequence of assertions no one can examine.

Start with the decision rather than the system’s identity. For the platform migration, the teachable core might be this: a flag-day switch was attractive because it ended compatibility work quickly, but several product teams could not coordinate their release windows. The adopted design kept both paths alive, made usage observable, established an exception process, and required evidence before the old path could be retired.

That reasoning can remain intact after names, exact traffic, internal diagrams, customer data, vendor terms, dates, and private topology are removed. The case study can still identify your role, the work owned by service teams, the rejected plan, the rollout gates, the recovery path, and the observable result.

Some material does not survive subtraction. A security lesson may depend on a vulnerability that is not yours to disclose. An incident may be identifiable from its date and symptom. A business decision may reveal an unreleased plan. In those cases, choose another artifact. Sanitization is not permission to publish a recognizable secret with the labels rubbed off.

Use outcomes at the precision you can defend. “Adoption completed without a coordinated cutover” may be both safer and more honest than an invented percentage. If a number is approximate, identify it as approximate. If you did not measure the result, describe what was observed rather than supplying a metric-shaped guess.

Before release, ask a stricter question than “Could I get away with this?”

Would a former teammate, customer, or employer recognize something here that was not mine to make public?

Uncertainty is an answer. Keep the case verbal, reduce it further, obtain clear permission, or use different evidence.

Defects and review workflow: follow the path as a stranger

Public profiles are often reviewed one artifact at a time and never read as a whole. Reverse that habit. Begin at the exact resume you intend to send and follow every public link from there.

Read the first screen quickly. What kind of engineer does it imply before you reach the details? Open the featured artifact without relying on your memory. Can you find the problem, your contribution, the important decision, and the boundary of the claim? Try the setup instructions. Check links from conference bios, profile pages, pinned repositories, and old portfolio entries. Look for private data, internal URLs, screenshots, credentials, and claims that have outgrown the artifact beneath them.

Then write the first interview question each featured item is likely to produce. Keep the link only if you would welcome that question and can answer it without revealing what the public version carefully withheld.

Practice and rewrite

The public packet is ready when it makes a few true things easier to examine and leaves everything else at its honest size. It does not have to prove an entire career. Its success is a better question in the next conversation.

Chapter 15 takes up that conversation: how to connect the evidence you selected to the work you want next without turning your career into a rehearsed story.

Self-review checklist and field reference

Related links

• Chapter 6: The Seven-Signal Model
• Chapter 10: Choose the Right Role Before Preparing
• Chapter 13: The Senior Resume
• Chapter 15: Build the Career Narrative