Publish nothing you would not want opened on a projector

Every line you publish carries the weight of a conversation you might not yet have had.

When a recruiter, hiring manager or future teammate opens a link, they assume a ready‑to‑talk moment is waiting for them. That moment is a silent interview: the artifact speaks, the decisions behind it are on display, and your intent is inferred from the level of polish and clarity you leave behind. Treat each artifact as a microphone in a crowded room and calibrate your pitch accordingly.

Every linked artifact is an interview waiting to happen

Think of the digital artifacts on your GitHub profile, personal site, or portfolio as a series of micro‑interviews. A README is a cover letter, an issue thread is a conversation starter, a demo video is a live demo. When someone clicks a link, they are not simply looking for code; they are looking for the story you tell with that artifact.

The first question they ask is: “Is this ready for discussion?” If the artifact looks like a rough sketch, the conversation will likely turn to the shortcomings rather than the ideas. The second question is: “Did I understand the decisions behind this?” An artifact that documents reasoning invites dialogue; one that simply shows output invites confusion.

Half‑finished demos teach them you ship half‑finished

When you create a demo, you usually want to impress. The temptation is to build a feature‑rich, polished experience before sharing. However, a polished demo can mask gaps in your understanding and leave interviewers guessing about the underlying architecture. A half‑finished demo that clearly shows progress, reveals trade‑offs, and invites questions can be far more valuable.

1. Show the journey, not the destination, a demo that stops mid‑implementation demonstrates that you are actively working toward a solution. It signals to the interviewer that you are comfortable iterating and that your process involves continuous improvement.
2. Highlight the pain points, point out where you ran into roadblocks. That invites the interviewer to discuss problem‑solving, not just feature lists.
3. Provide a clear next‑step plan, end the demo with a “here’s what comes next.” It shows you have a roadmap and are thinking ahead.

By exposing the unfinished parts, you set the expectation that you are a candidate who delivers incremental progress, learns from failure, and communicates openly. This is a stronger signal than a finished product that tells little about your approach.

A tiny repo with a README that explains decisions outscores a big one that does not

The size of a repository is not a metric of quality. A sprawling codebase with no documentation can be harder to grasp than a single, well‑structured folder. The true value lies in the decisions captured in a README or a dedicated design document. A tiny repo that articulates the rationale for architecture choices, the constraints you faced, and the trade‑offs you made is more compelling than a large repo that hides those insights.

• Clarity over volume, an explanation of why you chose a particular pattern or library provides insight into your thinking. Interviewers value clear reasoning because it indicates that you are not just following trends blindly.
• Reusability, a small repo with explicit intent is easier to fork and adapt, signaling that you are a contributor as well as a creator.
• Focus, a tightly scoped repository keeps the interviewer’s attention on the core problem you solved, rather than getting lost in peripheral code.

When you design a small repo, think of it as a pitch deck slide: every line should convey a point and lead the reader toward a clear takeaway. A README that reads like a conversation invites the next speaker to ask follow‑up questions. That turns the artifact into a dialogue, not a monologue.

If it would embarrass you in the room, pull it now

The digital presence you curate is often the first thing that precedes a face‑to‑face meeting. A piece of code that contains a hack, a hard‑coded secret, or a bug that causes a crash will make you uneasy when an interviewer runs it. It can also give the impression that you lack professionalism or attention to detail.

Steps to avoid embarrassment

1. Audit before publishing, run static analysis, linting, and unit tests. If your artifact fails to pass basic checks, it is likely not interview‑ready.
2. Remove sensitive data, no secrets, credentials, or personal identifiers should appear in public repos. A quick git filter-branch or bfg-repo-cleaner can scrub history if necessary.
3. Verify compatibility, test your artifact on a clean machine or CI environment. If it breaks, you have a story to tell about environment differences; if it passes, you’re ready for scrutiny.
4. Peer review, have a colleague or a community member look at your repository. Fresh eyes often catch issues you miss.
5. Keep a staging area, if you’re experimenting, keep that code in a private branch or a separate repository. Only merge to a public branch once you’re confident it meets your interview standards.

Pulling a buggy or unfinished artifact before it lands in a recruiter’s inbox eliminates the risk of a “Oops” moment. It also signals that you respect the time and intelligence of those who evaluate your work.

Maintaining a portfolio as a continuous interview channel

Once you understand that each artifact is an interview, the next step is to treat your portfolio as an active, evolving conversation:

• Version your artifacts, keep a changelog that explains what changed and why. It lets future readers track your learning trajectory.
• Add commentary, in the issue tracker or pull request descriptions, explain the problem context, the approach, and the outcome. These comments become interview notes you can reference.
• Link to related discussions, if your project sparked a talk, a blog post, or a meetup, link to those. It shows you are engaged with the community.
• Schedule reviews, set a monthly reminder to walk through your portfolio as if you were an interviewer. Update or remove artifacts that no longer represent your best practice.

A portfolio that is treated as a live interview channel becomes a self‑sustaining source of insight for recruiters and hiring managers. It reduces the need for live demos and allows interviewers to come prepared with specific questions.

In practice, it’s about transparency and intent

The practice of publishing nothing you wouldn’t want opened on a projector boils down to three core behaviors:

1. Intentionality, each link is chosen because it tells a specific part of your professional story.
2. Clarity, README files, issue threads, and documentation are written to answer the most obvious interview questions.
3. Readiness, artifacts are cleaned, tested, and documented before they become public.

When you align your online presence with these behaviors, you create an environment where interviewers can focus on the value you bring, rather than on troubleshooting or guessing. Your portfolio becomes a living conversation starter, a bridge that turns curiosity into a productive dialogue.

The next time you consider adding something to your profile, pause and ask: If this were a room full of people waiting to ask me questions, would I be comfortable letting them see this? If the answer is yes, you have just added a quality interview artifact. If no, it is time to pull or polish.

Comments

[Emily Woods]

I'd keep an unfinished project public when the README clearly labels what's working, what's proposed and what still fails. The scope is part of the explanation. A small company specific exercise on prachub could become a useful repo if you add your own implementation, boundary tests and a note explaining one decision. I'd judge that by the evidence someone can inspect, rather than by how finished the demo looks.