Last week I was staring at my CV thinking, “This could belong to literally anyone in my degree.” Same bullet points, same verbs, same vague claims about being “passionate.” I closed the doc and realized the problem was simple: I was telling, not showing.
You build a strong portfolio by treating it like a live lab of your work, not a museum of claims. Pick a clear focus, ship real projects, show your process, and make it ridiculously easy for someone to click, skim, and say, “Yes, this person can actually do the thing.”
What “Show, Do Not Just Tell” Really Means
At some point in a lecture I realized grades are basically “telling” while projects are “showing.” A transcript says you passed Data Structures. A GitHub repo with a working pathfinding visualizer proves you can think, code, debug, and finish.
Anyone can claim “I am good at X”; a portfolio is where you prove it fast, with links, screenshots, and real outcomes.
This sounds simple, but most student portfolios end up as prettier CVs. Same vague lines. Extra colors. No depth.
The “show” version does three things:
- Gives concrete examples instead of abstract claims
- Reveals how you think, not just what you finished
- Let readers experience your work in 30 seconds or less
If your portfolio feels like a collection of posters, you are still in “tell” territory. If it feels like a series of experiments and stories, you are getting closer to “show.”
Step 1: Decide What Your Portfolio Is Actually For
I used to think a portfolio was a fancy scrapbook. Then during a lab I watched a teaching assistant scroll through a student’s work. They spent maybe 25 seconds on the site. No one has time for a scrapbook.
You need a target:
- Are you aiming at internships?
- Early-stage startup roles?
- Grad school or research labs?
- Freelance gigs to fund your degree?
Your answer changes what you should show and how much detail you need.
| Goal | What they care about | What you should show |
|---|---|---|
| Tech internship | Can you ship code and work in a team? | GitHub repos, shipped side projects, team hacks, contributions |
| Design / product role | How you think about users and tradeoffs | Case studies, mockups, before/after examples, usability tests |
| Startup roles | Bias to action, ownership, learning speed | Scrappy projects, experiments, metrics, failures and pivots |
| Research / grad school | Depth, rigor, curiosity | Papers, experiments, code, reading notes, small replications |
If everything in your portfolio is equally important, nothing in your portfolio is important.
Pick 1 or 2 goals. Then ask: “If my future self in that role opened this site, what would they want to see first?”
Step 2: Choose Projects That Prove Something
A portfolio is not “every assignment I have ever done.” It is closer to a highlight reel with director commentary.
When you pick projects, ask three questions:
- What skill or trait does this project prove?
- Is there a link, demo, or artifact I can show?
- Can I explain the story in 4 sentences?
Here is a simple filter that helps cut away weak projects:
| Project type | Weak “tell” version | Stronger “show” version |
|---|---|---|
| Course assignment | “Built a web app for class.” | Link to deployed app + short note on a tricky bug you solved. |
| Hackathon | “Participated in 24h hackathon.” | Demo video + what you cut to ship on time. |
| Research project | “Worked on an ML project with Prof. X.” | PDF, code repo, what part you owned, and one key result. |
| Club role | “Organized events.” | Before/after numbers: attendance, revenue, or reach. |
If a project cannot answer “What did this change?” or “What did I learn that I did not know before?” it will be hard to “show” anything.
A smaller number of sharp, well-documented projects beats a long list of forgettable ones.
The 3-5 Project Rule
Aim for:
- 1 flagship project: the one you are proudest of right now
- 2-4 supporting projects: each proving a different skill
Example setup for a student interested in startups and product:
- Flagship: A small app with 200 users and real feedback
- Project: A pivoted idea that “failed” but taught you something
- Project: A club project where you shipped a feature to a real audience
- Project: A design case study for a feature improvement
If you have more than 5, group the rest into a “smaller experiments” section with short notes, not full pages.
Step 3: Turn Each Project Into A Mini Story
During a project studio class I realized the students who got the most interest were not the ones with the most complex work, but the ones who could tell a clear story around their work.
Each project page should answer these in a tight, readable way:
- Context: What is this and who is it for?
- Problem: What were you trying to solve or learn?
- Process: How did you approach it?
- Outcome: What happened?
- Reflection: What would you change next time?
You can keep the structure compact. Something like:
“I designed a budgeting app for first-year students who kept running out of food money. They did not trust existing apps, so I focused on clarity over features. I ran three short interviews, sketched flows on paper, then built a basic prototype in Figma. Out of five testers, four said they would use it weekly. If I had more time, I would test with students who hate budgeting entirely, not just the ones already trying.”
No buzzwords. Just clear cause and effect.
Show Your Process, Not Just Polished Screens
This is where “show, do not just tell” becomes very literal.
Instead of “I follow a user centered design process,” you can include:
- Scans of messy notebook sketches
- Iteration screenshots with short captions (“Version 1: too cluttered”)
- One or two feedback quotes from users or mentors
- A before/after comparison of a key decision
For technical work:
- Short code snippets that capture important tradeoffs
- Benchmarks or small graphs, if relevant
- Tickets or issues you filed and closed
- Tests you wrote for tricky logic
Think of your project page as a short director’s commentary, not a museum plaque.
Step 4: Make It Ridiculously Easy To Skim
Hiring managers and startup founders read portfolios like busy students read long readings: they skim for the interesting bits and only dive deep if something hooks them.
So your job is not to dump your life story. Your job is to design for skimming.
Practical layout tips:
- Use clear section headings: “What I built,” “My role,” “Challenges,” “Outcome”
- One idea per paragraph; short sentences over long ones
- Summaries at the top of each project: 2-3 lines max
- Big, obvious buttons for links: “View code,” “Try demo,” “Read report”
If someone can only spare 45 seconds on your portfolio, what do they walk away knowing for sure about you?
A simple test: Open your own portfolio on your phone. Give yourself 30 seconds. Then close it and write down 3 facts you remember. If those 3 facts do not match what you want people to remember, your “show” is not clear enough.
The Above-The-Fold Test
The screen that loads before you scroll matters a lot. On that first screen, a reader should understand:
- Who you are in one line (“Student designer who likes turning confusing UIs into simple tools for real people”)
- What you are focused on right now (e.g. “building tools for student communities”)
- Where to click next (featured project or “Start here”)
Avoid vague headers like “Welcome to my portfolio.” That space is your most valuable real estate.
Step 5: Quantify, Do Not Inflate
Every guide says “use numbers,” and they are right, but in practice students tend either to avoid numbers or to exaggerate them until they sound fake.
You do not need huge numbers. You need honest ones.
Replace:
- “Improved user engagement.”
- “Massive growth in signups.”
With:
- “5 of 7 testers completed the main task without asking for help.”
- “Event attendance went from 30 to 75 over three weeks.”
- “Page load time dropped from 3.2s to 1.4s on average.”
- “Reduced drop-off on the form from 60 percent to 40 percent.”
You can also quantify learning:
- “Tried 4 database options before settling on Postgres.”
- “Read 3 papers on recommendation systems to design the approach.”
- “Sketched 12 different layouts before picking one.”
Smaller, precise numbers feel more believable than vague claims about “huge improvement.”
If you genuinely do not have numbers, you can still be clear:
- “The project did not ship to real users. I treated classmates as proxy users and learned X.”
- “I did not track metrics at the time. Next version would include simple logging and surveys.”
Honesty is a signal. It shows self-awareness and seriousness.
Step 6: Let Your Personality Show Without Oversharing
The best student portfolios I have seen feel like they belong to a real person, not a resume robot.
You do not need to overshare personal stories. You do need to sound like a human with a point of view.
Places where personality can appear:
- Your one-line intro
- Project reflections (“In hindsight, I overcomplicated the backend here.”)
- Writing style on your “About” page
- Optional short posts on what you are learning
Example “About” section that shows without bragging:
“I am a third-year computer science student who likes building small tools that save people from boring tasks. Recently I built a timetable generator that 40 classmates used during registration week. I enjoy the early messy phase of projects where the idea is still shifting, and I am trying to get better at finishing things faster instead of perfecting them forever.”
That says more than “I am passionate about technology and teamwork.”
Use Writing To Show How You Think
One underrated part of a portfolio is short, casual writing. Not thought pieces. Just notes from the trenches.
You can start a very light “Notes” section:
- 1-page writeup: “What I learned from shipping my first side project”
- Short reflection: “Why I deleted 60 percent of my Figma frames”
- Breakdown: “How I tested my idea without writing code”
These do not need to be frequent. Two or three strong pieces already set you apart, because they show you reflect on your work.
Step 7: Build For Clicks, Not Just Screenshots
A surprising number of portfolios look fine in a screenshot but fall apart when you actually use them. Dead links. Demos that crash. Repos with incomplete README files.
From a recruiter’s side, nothing kills interest faster than “404” or “This project is private.”
Treat every link like a promise:
- If you link a demo: Make sure it loads fast and works on mobile.
- If you link code: Add a short README with setup steps and a 3-line overview.
- If a project is sensitive: Blur data, anonymize, or share redacted versions.
- If a project is not ready: Do not link it yet. A “coming soon” wall is frustrating.
If something cannot survive a cold click from a stranger, it is not ready to headline your portfolio.
A simple pattern that works well:
- Big button: “Try the live app”
- Secondary button: “View the code”
- Short note: “Best viewed on desktop” if that is the case
If your project is not a digital product (for example, an event or research study), link what you can:
- Slides or posters
- Short explainer PDF
- Photo gallery, if relevant
- Published abstract or preprint
Step 8: Use Constraints To Your Advantage
As students, we rarely have unlimited time, money, or teammates. That can feel like a disadvantage compared to polished industry case studies, but in a weird way it is your strength.
People reading your portfolio know you are early in your journey. They are mostly asking:
- Can this person learn?
- Can they work within constraints?
- Can they finish something real?
So instead of hiding constraints, surface them:
- “Built in 36 hours during a hackathon.”
- “Could not access real user data, so I mocked a dataset.”
- “Worked solo because team members had conflicting schedules.”
Then show how you adapted:
- “Focused on the two core flows instead of five extras.”
- “Used Airtable as a temporary backend to save time.”
- “Reused open-source components to cover the basics.”
This answers the silent question: “What will this person be like when things are messy?” Startups and labs care about that more than perfect polish.
Step 9: Make Your Campus Work Count
You do not need to wait for a fancy internship to have portfolio content. Campus life is full of raw material. The trick is to treat it like real work, not just “extracurriculars.”
Here are some student contexts and how to turn them into “show”:
Course Projects
Instead of “This was just homework,” try:
- Extend a course project slightly beyond the requirements
- Refactor the messiest part after grades are in
- Write a small note on what you would change if this were a real product
Portfolio angle:
“This started as a course assignment, but I kept working on it to handle real-world data sizes. The original version crashed on large CSV files, so I rewrote the parsing logic and added streaming. Now it can handle files 50x larger without freezing.”
Now it shows perseverance and technical growth, not just course compliance.
Club Work and Campus Organizations
You might be:
- Designing posters for a student group
- Managing the social media for a club
- Handling logistics for events
- Running a small tutoring circle
Portfolio angle:
- Show before/after visuals of posters or content
- Track attendance or signups
- Explain one bottleneck you fixed (e.g. messy signups)
- Share one system you set up so the group can run smoother
Again, concrete and honest.
Side Projects On Campus Problems
The best student products often start from corridor complaints:
- “The course registration site is a mess.”
- “We never know when machines are free in the lab.”
- “Finding teammates for projects is random.”
If something annoys you enough to rant about it during lunch, it is probably a good source for a portfolio project.
You might:
- Build a simple matching tool for project groups
- Create a micro-website that tracks laundry room usage
- Design a clearer version of a confusing campus interface (even if it is only a concept)
Here the “show” is clear: campus people will get it instantly, and recruiters will see that you notice problems and try things.
Step 10: Do Regular Small Updates, Not Huge Redesigns
I made the mistake of thinking I needed to rebuild my whole portfolio every semester. The result: long gaps, half-finished redesigns, and outdated projects at the top.
A better approach is to treat your portfolio like a work-in-progress notebook.
Regular, small updates:
- Every month: Add a sentence or two about what you are working on right now
- Every two months: Polish one project page or add a new one
- Once per term: Archive older work to a “Previous projects” section
Your portfolio should feel alive, not frozen at the moment you bought the domain.
This rhythm also forces you to keep making things, not just talking about future projects.
Step 11: Ask For Harsh Feedback, Not Just Compliments
It is very tempting to send your shiny new portfolio to friends who will say “Looks great!” That feels nice and does not help.
Ask different questions:
- “What confused you or felt unnecessary?”
- “If you had to guess what I am good at, what would you say?”
- “If you were hiring me, what is still missing for you to feel confident?”
- “Which single project made you more or less interested in working with me?”
Even better, ask people outside your circle:
- Alumni from your program
- People at startups you like
- Mentors from clubs or hackathons
You might hear things you do not like:
- “I could not tell what your focus is.”
- “The first project looks shallow compared to the third one.”
- “Your writing sounds more formal than you actually are.”
That hurts a bit. It also shows you exactly what to fix.
Step 12: Common Portfolio Traps (And Better Alternatives)
Here are some habits I have seen repeatedly among students, including my past self.
| Trap | Why it weakens “show” | Better approach |
|---|---|---|
| Long skill lists (“Python, Java, C++, Figma, SQL, …”) | Hard to tell if you can actually use any of them. | Mention tools inside concrete projects: “Wrote the backend in Python with FastAPI.” |
| Stock phrases (“Hard-working, passionate, team player”) | Everyone says this. No evidence. | Describe actual behaviors: “Led a 4-person team across 2 time zones for 3 weeks.” |
| Visual overload and animations | Distracts from content; slows pages down. | Clean, simple layout where content is the focus. |
| Hiding failures | Makes you look unrealistically polished. | Include one “failed” project with an honest reflection and lessons. |
| No context for team projects | Readers cannot tell what you actually did. | Explicitly list your responsibilities and what others did. |
Concrete stories replace buzzwords. Evidence replaces adjectives.
Step 13: Simple Structure You Can Copy Today
If you feel stuck on structure, here is a lightweight template that keeps “show, do not just tell” front and center.
Homepage
- 1-line intro: who you are + what you like working on
- Current focus: 1 short sentence (“Right now I am building small tools for student communities.”)
- Featured project with image and 2-line summary
- List of 2-4 more projects with short blurbs
- Simple “About” link and contact info
Project Page Template
Use the same sections for each project so readers know where to look.
- Title + one sentence summary
- Links: live demo, code, docs
- “Context”: When, where, and who it was for (3-4 lines)
- “My role”: What you took responsibility for
- “Process”: Short story with key steps and 1-3 images
- “Outcome”: Results, numbers, or feedback
- “What I would change”: 2-3 bullet points of future improvements
About Page
Keep it simple and honest:
- Short paragraph about your background
- What you enjoy working on and why
- What you are actively trying to learn this year
- Links to CV, email, and maybe LinkedIn / GitHub
You do not need a life story. You need a clear snapshot of where your head is.
From “Portfolio As Decoration” To “Portfolio As Proof”
At some point, every student realizes the same thing at 2 a.m.: no one is going to read every line of your CV, and no one owes you their attention. You have to earn it.
“Show, do not just tell” is not a slogan. It is a design rule for your future:
- Pick projects that actually prove something.
- Tell tight stories around them.
- Expose your process, not just the shiny parts.
- Refresh it as you grow, not once every few years.
If your portfolio makes a busy person think, “I can see exactly what this student can do, and I want them on my team,” then you have done the job.
