A portfolio without commercial experience: what belongs in it

Why it exists

A CV says what you can do. A portfolio shows it. For someone without experience it's the only proof, and it's looked at more often than people assume.

The visit is usually short: open the repository, read the description, skim the commit history, glance at a couple of files. Five minutes. Those five minutes decide whether you're invited.

How many projects

Two or three finished. Not twenty started.

Twenty repositories of course exercises work against you: the viewer sees a graveyard and concludes you finish nothing.

The rule: three completed beats fifteen abandoned. The rest can be made private or archived.

What carries weight

In descending order:

A team project. Valued highest, because it addresses the employer's main fear: not knowing whether you can work with people. Code review, a shared history and divided tasks are all visible.

Be sure to state what you personally did.

A project solving a real problem. However small. A site for a tradesperson you know, automating a report from your previous job. A real client and real requirements are visible immediately.

A project someone uses. Even ten people. That's rare and a strong argument.

Contributions to open projects. They show you can read someone else's code and submit changes to the rules.

A personal project with no problem behind it. Another to-do list. Weak: there are thousands.

Coursework as submitted. Almost no value: thousands submitted it identically.

Presenting the repository

This is half the impression, and half of it is neglected.

A description at the root. What the project is, who for, what it does, how to run it, which technologies. With a screenshot or a short video if it has an interface.

The test: someone opening the repository understands within a minute what's here. If not, the description is bad.

A comprehensible commit history. Meaningful messages instead of "fix" and "updates". The history shows how you work, and it does get looked at.

A running version behind a link. Being able to click around a live version is worth more than one more feature. Many can't be bothered to deploy — a mistake.

Cleanliness. No commented-out code, no files with passwords, no dependency folders in the history.

A few checks. At least some automated tests. Their presence in a beginner's project is rare and stands out.

What to do with coursework

Don't publish it as is. That isn't your project, it's a completed assignment.

Either extend it. Take the coursework and add something of your own: new capabilities, proper presentation, tests, deployment. Then it becomes yours and becomes interesting.

Or label it honestly. "Course project, I added the following" is fine. Passing it off as independent work is not: it's visible and it casts doubt on everything else.

Talking about it

An interview will certainly ask about a portfolio project. Prepare to answer four questions:

• What it does and why.
• How it's built, in broad strokes.
• What was hardest and how you solved it.
• What you'd do differently now.

The last is the most revealing. "It's all fine, I wouldn't change anything" sounds worse than an honest "I chose the data structure badly, and because of that I had to rework the reports later".

The ability to look critically at your own work is valued above the work itself.