What Should a Software Engineering Student Put on Their Portfolio?

Short answer: a one-sentence statement of what you build and what role you want; two or three projects with a live link, the stack named and one technical decision explained; a GitHub profile with those projects pinned and documented; a one-page CV linking to both; and a LinkedIn profile that says the same thing. Everything else is optional.

The rest of this is about the parts that are specific to being a student — coursework, group work, no employment history, and the uncomfortable question of what to say about the things you are still learning.

Start from what the portfolio is for

A portfolio is a claim plus its evidence. The claim is "I can do this job". The evidence is work someone can inspect.

That framing settles most of the arguments people have about what to include. A skills section with percentage bars is not evidence. A blog post about a framework you used once is not evidence. A deployed project with a README explaining why you chose a particular data model is evidence.

Everything you add should be answering the question "how would someone check that?"

What to include

The claim, at the top. One sentence: level, specialism, availability. "Second-year computer science student. I build web applications in TypeScript and React. Looking for a summer 2027 internship." Three facts, twenty words.

Two or three projects. Each with a one-line description written for someone who has never seen it, the stack named explicitly, a live link or a demo recording, a source link, and two or three lines on the interesting technical part.

One technical decision per project. The alternative you rejected and why. This is the single strongest differentiator on a student portfolio and almost nobody does it.

A GitHub profile that matches. Profile README with three lines about what you build, the same projects pinned, real descriptions, no secrets in the history.

A one-page CV. PDF, with your portfolio and GitHub as clickable links in the header, and three lines per project that say what you built, with what, and what happened.

Contact details that work. An email address is enough and it is more reliable than a form.

What to leave out

Percentage bars and star ratings on skills. Technical reviewers dislike these consistently. "Python — 87%" is not a measurable claim and it invites a question you cannot answer. Group technologies by what you have used them for instead.

Tutorial rebuilds. A to-do app, a weather app that is exactly the tutorial's weather app, a clone of a well-known site with no changes. These prove you can follow instructions.

Every module you have taken. Your degree transcript is not a portfolio. One line naming your course and university is sufficient.

Aspirational technologies. Listing Kubernetes because you watched a course on it. If you would not be comfortable being asked about it for five minutes, it does not go on the list.

A photo carousel of your hobbies, an animated hero with no information in it, and a custom cursor. Reviewers open a lot of these, usually on a laptop between meetings.

The coursework question

Include it, but upgrade it first.

An assignment as submitted looks like an assignment: not deployed, README is the brief, no error handling beyond the sample data, repository named cs2043-assignment-3. Upgraded — deployed, real README, one feature nobody asked for, a few tests, sensible name — a reviewer cannot distinguish it from a personal project.

That upgrade is about two evenings. Building something new is three weeks. Do the maths.

The one thing to be careful about: check whether starter code from your department can be published. Usually it can. Occasionally it cannot, and it is better to find out before it is public.

The group project question

Include it, and be precise about what you did.

Write it as: "Team of four. I built the authentication service and the API layer; I also set up the deployment pipeline." Then describe your part in detail and the team's part in one line.

Do not claim the whole thing. Interviewers ask which parts you wrote, and vagueness reads as either dishonesty or not understanding the codebase. Being clear about a well-defined contribution is more impressive than implying you built everything.

What to say about things you are still learning

Say them, in a section that is honestly labelled.

A "currently learning" line — two or three technologies, with what you are building to learn them — is genuinely useful. It gives an interviewer an easy opening question, it shows direction, and it lets you mention technologies you are interested in without claiming competence you do not have.

What you must not do is put those technologies in your main skills list. The distinction between "I use this" and "I am learning this" is the whole point, and blurring it is what gets found out in an interview.

Do you need a personal website?

Not mandatory. Close to expected for front-end and full-stack roles, where the site is itself a work sample.

For back-end, data and systems roles, a well-documented GitHub with a deployed project and a good CV is genuinely sufficient. A site still helps — it lets you control the framing rather than leaving a reviewer to form an impression from a repository list — but it is not the thing to prioritise if your GitHub is a mess.

If you do build one: one page, five sections, deployed. Not five pages with three empty ones.

Do you need a blog?

No, and most student blogs actively hurt.

Three posts from eighteen months ago explaining what a for-loop is signals abandoned enthusiasm. If you write, write about something you did — a bug you fixed, a decision you made, a benchmark you ran. One post explaining how you cut a project's memory usage from 1.2 GB to 40 MB is worth more than twenty tutorial summaries, because it is evidence rather than restatement.

If you are not going to keep it up, do not start it.

A word on AI

Use it. Pretending otherwise is unrealistic — professional developers use it daily.

The rule that matters is ownership: you must be able to explain every line you present, because you will be asked to. Use it for scoping, code review of your own work, drafting documentation you then rewrite, and rehearsing explanations out loud. Do not present a project you have not read, and do not claim familiarity with a technology you only watched a model use.

An interviewer establishes this in about ninety seconds and there is no recovery from it.

The check

Show your portfolio to someone who is not on your course and ask one question: what do you think I do?

If their answer does not match the role you are applying for, the positioning is the problem — not the projects. That is a one-evening fix and it is worth more than another feature.

The free toolkit has a 42-point checklist covering everything above, and how to make a developer portfolio is the full walkthrough.