Building and Presenting Your Portfolio

A portfolio is where your projects from the previous lesson actually get seen. It does not need to be elaborate — it needs to be clear, and it needs to exist. A brilliant project with no portfolio page describing it might as well not exist to someone screening candidates.

• Who you are and what you do, in one or two sentences — not a life story.
• Two or three projects, each with a live link, a source code link, a short description of the problem it solves, and the specific technologies used.
• A way to contact you — email at minimum, visible without hunting.
• Optional but useful: a short note on what you're learning next, which shows momentum rather than a finished, static state.

For each project, three short things matter more than a long writeup: what problem it solves, what you specifically decided or built (not just the tech stack), and what you'd do differently now. That last one matters more than it seems — it shows judgment has developed since you built it, which is exactly what a reviewer wants to see.

• No live link. A GitHub repo alone asks the reviewer to run your code locally, and almost nobody will. Deploy it — a free static host or a simple platform is enough for most student projects.
• No screenshots or a broken deploy. Check live links work before sending them anywhere. A dead link is worse than no link.
• Overwritten with generic template text. "Lorem ipsum", placeholder images, and unedited starter-kit text signal the project was abandoned before it was finished.
• Burying the good project under weaker ones. Lead with your strongest work, not chronological order.

A single clean page, or even a well-organised GitHub profile README with pinned repositories, is enough to begin applying. Building an elaborate portfolio site is a reasonable project in itself, but do not let building it become the reason you delay applying anywhere.