Skip to main content
Back to module
Foundations for Software, Data, Design & Tech Education Careers · Building Evidence

Portfolios that get interviews

Reading1h 6mLesson 1 of 3 in this module

Plan three portfolio pieces that show the skills your target role's postings ask for.

Why it matters

For most tech roles, a portfolio is the strongest evidence you have before your first job. A hiring manager reading 200 applications looks for one thing: proof that you can do the work they need. A CV says "proficient in SQL"; a portfolio piece shows a real question answered with SQL, with the query, the chart and the conclusion. That is often the difference between being skipped and being interviewed.

The core idea: evidence for a specific role

A good portfolio is small, targeted and finished. Three strong pieces aimed at one role beat ten tutorial clones.

Each piece should answer four questions in its README or case study:

  1. Problem: what were you trying to solve, and for whom?
  2. Approach: what did you do, and why did you choose that approach?
  3. Result: what does it do, with a link, screenshot or numbers?
  4. Reflection: what would you improve, and what did you learn?

What a good piece looks like, by role

RoleStrong pieceWeak piece
Software / UI / mobile developera deployed app solving a real problem, with tests and a clear READMEan unchanged to-do list from a tutorial
Data analyst / scientistan analysis of a public dataset answering a real question, with code, charts and a written conclusiona notebook that only loads a famous dataset
Machine learning engineera small model served behind an API with monitoring notesa copied Kaggle notebook
Cybersecurity engineera home-lab write-up: hardening a virtual machine, or analysing logs from a safe practice environmenta list of tools you have installed
Cloud engineer / DBAinfrastructure as code that deploys a small app on a free tier, with a cost and cleanup note; or a database tuning write-upscreenshots of a console
Systems analyst / IT PMa requirements document or project plan for a real (even volunteer) projecta template with no content
UI/UX designer / game designera case study with research, iterations and testing; a playable prototype with a design docfinal screens with no process
Technical trainer / CS teachera short lesson or workshop with objectives, materials and learner feedbacka slide deck with no learning goals

Worked example: improving a weak idea

Weak: "A weather app." Thousands of applicants have built one from the same tutorial.

Stronger: "A frost alert for my community garden. It checks the overnight forecast and emails the volunteers when the temperature will drop below 2 °C. It has run for a month and sent three correct alerts."

What changed:

  • a real user (the garden volunteers)
  • a specific problem (protecting plants from frost)
  • evidence it works (a month of real use)
  • the same technical skills (an API, scheduling, email), now with a story an interviewer will ask about

For a data analyst, "Titanic survival analysis" becomes "Which bus routes in my city are most often late, and at what times?", using the city's open data.

Presenting it

  • Pin your best three pieces at the top of your GitHub, Behance or personal site.
  • Put the live link and a screenshot at the top of each README.
  • Write for a reader with two minutes: the problem and result first, details after.
  • Remove or archive old half-finished work from the front page.
  • Keep secrets out: no API keys or passwords in public repositories.

Common mistakes

  • Tutorial clones. If it looks identical to a popular tutorial, it shows you can follow instructions, not solve problems.
  • No README. Reviewers will not dig through code to guess what it does.
  • Unfinished work on display. Finish fewer things.
  • Ignoring the target role. A game prototype does little for a database administrator application.
  • Using private or employer data. Use public, synthetic or your own data.

Quick recap

  • Three finished, targeted pieces beat many unfinished ones.
  • Each piece explains problem, approach, result and reflection.
  • Real users and specific problems make ordinary skills stand out.
  • Lead with the result and a link; keep secrets out.

Try it

Open the Do tab to plan three portfolio pieces for your target role.

Also in this lesson: