How To Make A Portfolio For Computer Science

Why Most CS Portfolios Look Like Homework Assignments

I spent three years hiring for backend engineering roles, and the portfolio that actually impressed people was never the one with twelve todo-list apps and a generic blog. The ones that got candidates shortlisted had an odd mix of things: a deliberately broken project with a clean writeup about why it broke, a real system that had crashed at least once in production, and a git history that looked like actual work instead of thirty commits made on the same day. The process starts with deciding who you're showing this to. If you're targeting startups, they want to see that you can ship. If you're going for research labs, they want to see depth. If you're applying to big tech, they want to see that you can read documentation and follow a spec. The portfolio changes depending on the audience, which means you should probably pick a lane before you write a single line of code. I built my first portfolio around 2019. It had eight projects. Every one of them was a tutorial copy. I sent it to maybe forty people over six months. I got one response. That wasn't encouragement. So I threw most of it away and rebuilt around three projects instead. The drop-off rate from eight to three is painful, but it's also where you learn what to keep.

Start With Three Projects, Not Twelve

You do not need a lot. You need depth in three areas that prove you can think. Here's what works in practice. Project one: something you shipped and then watched break. This is more valuable than any tutorial clone. I remember building a small real-time collaboration tool for a friend. It worked fine locally. The first time someone outside my apartment opened it, the WebSocket server deadlocked under three concurrent connections. The fix involved understanding publish-subscribe patterns and connection pooling. Writing about that deadlock and how I diagnosed it using stack traces and connection logging ended up being the longest read on my entire portfolio. Recruiters don't read everything, but the engineering leads do. They stopped at that section and usually asked a follow-up question in the interview. Project two: something that demonstrates systems thinking. This doesn't need to be a database. A custom key-value store, a basic load balancer, a mini ORM, a CLI tool that does one thing extremely well — these all count. The metric here isn't complexity. It's whether you made deliberate tradeoffs and can explain them. I once built a simple URL shortener as my systems project. The interesting part wasn't the shortener itself. It was the choice to use an in-memory HashMap instead of a database, the cache invalidation strategy, and how I handled collisions. That project got me more interview callbacks than the distributed caching system I built two months later.

Project three: something that shows you solve problems other people have. This is the hardest category. It could be an open-source contribution. It could be a tool you made for your own workflow. It could be a library you published. I found that the most effective version of this project was a small Python package that parsed a niche log format at my old job. I published it on PyPI, wrote rough documentation, and got three GitHub stars and two issue reports. The stars didn't matter. The issue reports mattered because they forced me to handle edge cases I hadn't considered.

Structure Matters More Than Code Quality

Most people treat the portfolio website like a gallery. It isn't. It's a document. The structure should make it easy for someone who has thirty seconds to understand what you can do. Every project page should have the same four sections. A one-paragraph summary that states what the project is and why it exists. A tech stack list that's honest — if you used a library because you were stuck, say so. A architecture or design decisions section where you explain what you chose and what you rejected. And a live demo or repository link. Skip any of these and you lose half the readers before they reach the end. I learned this the hard way when a hiring manager at a mid-size company told me he scrolled through my portfolio in under a minute and couldn't find the repo links. He closed the tab. I had spent three weeks styling the hero section. He never saw it because the repository links were buried under a navigation menu that required a hover state to reveal.

Use a Minimal Framework and Host It Cheaply

Do not build a custom frontend framework for your portfolio. Use something that renders fast and doesn't require maintenance. I've used Hugo, Eleventy, and plain HTML with a stylesheet. The plain HTML version loaded in under two hundred milliseconds and took me two days to finish. The others took a week because I kept tweaking configurations. Host it on GitHub Pages, Vercel, or Cloudflare Pages. These are free, they handle HTTPS automatically, and they don't introduce deployment complexity. I tried Netlify once for a project, migrated to Vercel for another, and ended everything on GitHub Pages. The migration took ten minutes. The cost difference between all three is zero because all three are free at this scale. If you want the source for a minimal template, I use a single HTML file with a CSS grid layout and a projects directory. You can find similar setups on GitHub by searching for static portfolio templates. There's no reason to pay for a theme when you're just showcasing code.

The Sections Nobody Talks About

A resume is a list. A portfolio is evidence. The gap between the two is where most people get stuck because they don't know what to include beyond project links. Technical narrative page. This is a short paragraph or two about how you think about problems. I wrote mine around the idea that debugging is more important than coding because you spend more time in the failure state. It was honest, it was memorable, and it gave interviewers something to ask about. One person at a fintech startup asked me to walk through a debugging process from a recent project. I did. She offered me a second-round interview on the spot. A contributions or OSS page. Even if you've only fixed a typo in someone else's README, list it. The point isn't volume. The point is signal. It shows you've worked within someone else's codebase and followed their conventions. I contributed one small fix to a documentation repo for a Rust crate. It was the only open-source entry I had for six months. Hiring managers noticed anyway because most applicants don't have anything there at all.

A readings or learning log. This isn't mandatory, but it's useful if you're transitioning into a new domain. I listed the books and papers I'd read over a two-month period when I was learning distributed systems. The list was twelve items long. An interviewer from a cloud infrastructure company asked about two of them during a phone screen. That conversation turned into a take-home assignment and eventually a return offer.

What to Exclude

Don't include project screenshots that are just UI mockups without backend logic. Don't list every language you've ever touched in a skills section. Don't link to tutorials you followed without adding your own notes about what you changed. Don't use generic headlines like Passionate programmer seeking opportunities. It doesn't add information and it wastes the reader's time. I also removed a project that was technically impressive but impossible to evaluate. It was a machine learning model that classified images with ninety-four percent accuracy. The problem was that the dataset was synthetic, the training code wasn't reproducible, and the model ran on a GPU I no longer had access to. I replaced it with a simpler project that I could explain clearly and that anyone could run locally. The simpler project got more meaningful feedback because it was actually testable.

A Specific Edge Case I Faced

There was a point where I needed to show that my projects were mine, not ones I copied from a course. I had enrolled in a backend development bootcamp and completed three projects as part of the curriculum. I wanted them on the portfolio because they were the best implementations I had at the time. But listing them without context felt dishonest, and listing them with the bootcamp attribution felt like admitting I hadn't built them independently. The workaround was to rebuild one of the bootcamp projects from scratch without looking at the solution, then document the differences. I kept the original bootcamp project as a reference but added a note explaining that the deployed version was a reinvention. I also added a changelog showing what I changed and why. This took about six hours of extra work, but it resolved the authenticity problem and gave me a concrete example to discuss in interviews about how I approach code ownership.

Review Before You Publish

Have two people look at your portfolio. One should be technical. One should not be. The technical person will find missing dependencies and broken links. The non-technical person will tell you which project description they understood and which one made them skip ahead. I learned that my second project description was so dense with jargon that a non-engineer friend described it as sounding like a terms of service agreement. I rewrote it in plain language. It became the most linked-to section of the portfolio within three months. Also check page load speed with Lighthouse. If your portfolio takes more than three seconds to load on a decent connection, you've already lost people who are evaluating multiple candidates. I trimmed my image assets and switched to a system font stack. The load time dropped from four seconds to one point one seconds. That's a material difference when someone is scrolling through twenty portfolios in an afternoon.

When a Portfolio Doesn't Help

A portfolio won't replace a strong resume if your resume is empty. It won't compensate for a complete lack of foundational knowledge in an interview. It won't help if you're applying to roles where portfolio submission isn't expected, like some government contracts or highly regulated industries that prioritize certifications over demonstrated work. In those cases, your GitHub activity and any relevant publications matter more than the portfolio site itself. Also, maintaining a portfolio is ongoing work. If you add a new project, you should update the narrative page and remove something that no longer represents your current skill level. I've seen people leave projects on their portfolio from two years ago that used outdated patterns, and it signals that they haven't thought critically about their own growth. The honest version of how to make a portfolio for computer science is that it's not about showing everything you've ever done. It's about curating evidence that you can solve problems, communicate about them, and keep learning. Three good projects with clear documentation beat twelve vague ones every time.