Building a Professional Portfolio: Private First, Public on Your Own Terms

BuildBuild a public portfolio" is common careers advice, and it lands badly with a lot of students — not because the advice is wrong, but because "public" is doing a lot of unstated work in that sentence. It implies that anything worth showing a future employer has to be visible to the entire internet, including the version of it from three weeks ago when it didn't work, and including whoever you're most anxious might see it. That implication isn't true. A portfolio is something you build in private, on your own schedule, and make visible only when — and to whom — you choose. This page is about doing that deliberately, using the two platforms you already have: the department's CSGitLab, and a personal GitHub account alongside it.

Start Entirely Private, and Stay There Until Assessment Is Complete

IfIf you're already working on an assessed project, Issue Tracking: CSGitLab and GitHub covers the academic-integrity reason a project repository must stay Private for the duration of assessment — and that's not a soft default, it's a hard rule: nothing that's still being marked moves to Internal or Public, no matter how confident you feel about it or how ready a piece of it looks. The advice here is related but broader: keep everything private by default while you're a student, not just the one repository currently being marked. A coursework exercise, a weekend experiment, a half-finished attempt at something you saw online — all of it can live in a private CSGitLab project from the first commit, with no decision about who else ever sees it required at that point. Privacy while you're learning isn't a stopgap before the "real" public version; it's the correct default for work you haven't decided what to do with yet, and for assessed coursework specifically, it's the required state until marks are confirmed.

Once marking is finished, there's a second gate before you widen access at all: check with the module leader or your supervisor whether you're actually free to share the work more widely. A piece of assessed coursework often isn't entirely your own copyright to redistribute — a provided brief, starter code, a dataset, sample or reference material, or a framework the department wrote may belong to the university or to a third party it licensed the material from, even though your own implementation sits on top of it. That doesn't mean the work can never be shared; it means the question "am I allowed to?" has an actual answer that isn't yours to guess, and it's worth asking before Internal, not just before Public — the safest position is to ask, and to keep the repository Private until you have.

Three Levels of Visibility, and What Each One Is For

CSGitLab,CSGitLab, like most self-hosted GitLab instances, offers three visibility levels rather than a simple private/public switch¹. Knowing what the middle one actually does is what makes the gradual-confidence approach below practical rather than theoretical:

Level	On CSGitLab	On a personal GitHub account
Private	Visible only to people you add as a project member by name.	Same — visible only to collaborators you invite.
Internal	Visible to anyone with a CSGitLab account — in practice, the department: coursemates, teaching staff, anyone else on the same instance — without you naming each of them individually.	Not available on a personal account. GitHub's equivalent (visible to everyone in an organisation) needs a paid organisation account, which isn't the relevant case here.
Public	Visible to anyone on the internet, including people with no account at all.	Same — visible to anyone, logged in or not.

Internal is the level that gets skipped when people think of visibility as a binary switch, and it's the most useful rung for exactly the anxiety this page is about: it lets you show work to a real, bounded audience of people who already understand what a piece of student coursework looks like — before deciding whether the entire internet should see it too.

The Graduation Problem

Here'sHere's the complication that makes CSGitLab-only portfolio-building a trap: your CSGitLab account stops working once you graduate. Whatever visibility you'd set, whatever history you'd built, whatever a future employer might have followed a link to — all of it becomes unreachable the moment your institutional account is deactivated. A portfolio that lives only on CSGitLab has a hard expiry date built into it, on a timer you don't control.

The fix is the same dual-remote setup Issue Tracking recommends for a single assessed project, applied as a standing habit across everything you do: add a personal GitHub account as a second git remote from the start, and push to both. Set GitHub's visibility to match whatever you've chosen on CSGitLab at the time — Private to Private, Internal-equivalent (which for a personal GitHub account just means Private, since Internal isn't available there) to Private, Public to Public. When you eventually raise the visibility of something, raise it on both. Do this from the first commit of anything you might conceivably want later, and the question "how do I get five years of work off a system I no longer have access to" never comes up, because it was never only on that system.

Loosen Visibility Deliberately, Project by Project

TheThe confidence-building path this page is arguing for isn't "go from private to public once, for your whole account." It's a decision made separately, deliberately, for each individual project, whenever you judge it's ready:

1. Private. Where everything starts. Nobody sees it who you haven't named.
2. Internal, on CSGitLab, once it does something — and, for assessed work, once marking is finished and you've checked you're allowed to share it. A coursemate or a member of staff can now find and look at it without you sending a link or granting access individually — a much lower-stakes audience than the open internet, and a genuinely useful one, since the next step depends on someone other than you having actually looked.
3. Public, on GitHub, once you've had it reviewed and you've decided it represents you well. This is the only step that involves a stranger, and it should be the last one, not the first.

Most of what you build as a student should probably stop at step 1 or 2 forever. A portfolio is a curated selection, not a complete archive — deciding that most of your CSGitLab account never goes further than Internal is not a failure to be brave enough, it's what a portfolio actually is.

Get a Second Pair of Eyes Before You Flip the Switch

BeforeBefore moving anything to Public, have someone else look at it first — a coursemate, a supervisor, anyone whose judgement you trust to read it as a stranger would. Ask them to look at the same two things a first-time visitor will: does the README explain what this is and why it exists within thirty seconds of arriving, and does anything in the commit history or the code itself look like something you'd rather a specific person didn't see. A second pair of eyes catches both kinds of problem more reliably than re-reading your own work for the fifth time, and it turns "is this ready?" from a private, anxious guess into an actual answer from someone else.

What a Portfolio Piece Should Actually Show

OnceOnce something is a candidate for Public, it's worth being deliberate about which projects you put forward, because a spec-following exercise and a self-directed extension demonstrate genuinely different things — and a portfolio that only contains one of them tells an incomplete story:

Kind of project	What it demonstrates	What it can't demonstrate on its own
Followed a set brief closely — a module assignment, a client-style specification, a set of acceptance criteria you delivered against	You can take a specification seriously, deliver against constraints you didn't choose, and work the way most paid software work actually happens	Whether you have interests, curiosity, or initiative beyond what was assigned
Went beyond the original spec — added a feature nobody asked for, kept maintaining something after the module ended, built something from a genuine idea of your own	Genuine interest, initiative, and the judgement to decide for yourself what was worth adding	Whether you can also work reliably to someone else's requirements when that's what the job needs

Neither kind substitutes for the other in an employer's reading of a portfolio. A handful of each — a couple of pieces that show you can deliver precisely to a brief, alongside a couple that show what you build when nobody set the brief at all — says considerably more than an equal number of either kind on its own. See Choosing a Final-Year Project's "does it showcase your skillset" question for the same range-over-depth argument applied to picking a single project, rather than curating several.

A Portfolio Is a Deliberate Identity, Not an Accident

What'sWhat's actually being built here is a digital identity: "a persona an individual presents across all the digital communities that he/she is represented in", which reflects how you're viewed and can measurably affect your reputation and opportunities within those communities². Left unmanaged, that persona is whatever happens to be visible about you online, assembled by accident out of everything nobody bothered to make private. Everything on this page — starting private, widening deliberately, choosing what represents you and what doesn't — is the alternative: treating that persona as something you author on purpose, rather than something that simply accumulates³. A curated public GitHub with three well-chosen, well-reviewed projects says more about you, deliberately, than an account where everything you've ever pushed happens to be visible by default.

A Practical Sequence

• From day one: new work starts Private on CSGitLab; add a personal GitHub remote and push to both, matching visibility on each.
• When something works and you're a little proud of it: if it's assessed coursework, wait until marking is finished and check with the module leader or your supervisor that you're free to share it — some assessments are built on university-owned material you don't have the right to redistribute. Once that's clear, set it to Internal on CSGitLab and let it exist somewhere a coursemate could stumble across it.
• When you're considering making it Public: ask someone to review the README and the code first, as a stranger would.
• Before you graduate: confirm every project you want to keep is already pushed to your personal GitHub, at the visibility you want it to have — not planned for "before I leave", actually done, since CSGitLab access ends on a date you don't control.
• Ongoing: keep choosing a mix — some projects that show you can deliver precisely to a brief, some that show what you build when the brief was your own idea.

Related Topics

• Issue Tracking: CSGitLab and GitHub — the dual-remote git setup and the academic-integrity case for privacy during an assessed project, which this page's habit of always pushing to both is built on.
• Choosing a Final-Year Project — picking a project that showcases range in the first place, before the question of publishing it ever arises.
• Process Over Product — why a well-kept commit history is itself part of what a portfolio shows, not just the finished code.

References