Skip to content

Intermediate example

Three projects with a consistent back-end story

Final-year student with a part-time support job. Several assignments and one side project. Applying for graduate back-end roles.

Target role

Graduate back-end engineer

The header

The only job of the header is to answer “who is this and what do they build?” before anyone scrolls.

Priya Raman — back-end developer
Final-year computer science student. I build APIs and data pipelines in Python and Go. Available from July 2027.

The projects

Three projects, ordered by strength rather than by date.

1. Society Events Platform

Event sign-ups for three university societies. Ran a full term with about 400 registrations.

StackDjango, PostgreSQL, Redis, deployed on Fly.io
Evidence shownLive site, source, architecture diagram in the README

The technical decision it leads on. Used a database-level unique constraint plus a transaction for capacity, after load-testing showed two simultaneous sign-ups could both take the last place.

2. Log Analyser

Ingests and queries server logs larger than available memory, with a dashboard for error rate over time.

StackGo, SQLite, HTMX
Evidence shownDemo video, benchmarks in the README, source

The technical decision it leads on. Streamed the file line by line rather than reading it into memory, which took peak usage from 1.2 GB to 40 MB on a 2 GB log.

3. devkit

A small CLI of everyday developer utilities. Published to Homebrew.

StackGo, Cobra, GitHub Actions
Evidence shownInstall command, 90% test coverage, CI badge

The technical decision it leads on. Chose Go over Python so the tool ships as a single binary with no runtime dependency.

Why this portfolio works

  • Three projects that tell one coherent story: this person does back-end work.
  • Every project has a number attached to it — registrations, memory usage, coverage — and none of them look invented.
  • The published CLI is installable in one command, which is unusually easy to verify.
  • The technical decisions all name the alternative that was rejected.
  • There is real evidence of process: CI, tests, load testing, benchmarks.

What it would still improve

Every portfolio has gaps. Naming them is more useful than pretending the example is finished.

  • No writing. One post explaining the memory fix would extend the reach of the same work.
  • The site itself is plain, which is fine for back-end but a small missed opportunity.

The ten-second read

A final-year student with a clear back-end direction and evidence of engineering judgement, not just completed features.

What to take from this

Copy the structure, not the content. The claim, the projects, the technical decisions and the voice have to be yours — those are the parts a reviewer is assessing, and a borrowed About section reads as exactly what it is.

If you want to work through your own version, the complete walkthrough is here and the free toolkit has the checklists and the case-study template that produce the project write-ups above.

Want the complete 14-day system?

Developer Portfolio Builder takes you from “I need a portfolio” to application-ready in 14 days: seven modules, 30 project briefs, every template, and a 100-point scorecard to check your work.

See what’s included