What to put in a developer portfolio
Two or three finished projects, each with a clear README, beat a long list of tutorials. What reviewers look for and how to present your work.
Published
A portfolio answers one question for the person reviewing it: can this person do the work? Here is how to make that answer obvious.
Choose fewer, finished projects
Two or three complete projects are more convincing than ten tutorials. "Complete" means:
- It runs, and someone else can run it from your instructions.
- Web projects are deployed and the link works.
- The code is in a public repository with a sensible commit history.
Pick projects that show judgement
Copying a tutorial shows you can follow instructions. Changing it shows you understand it. Add a feature the tutorial did not have, use a different data source, or solve a problem you actually have.
Good portfolio projects usually include:
- Real data: a database, an external API, or a file you process.
- Something that can go wrong, handled well: validation, errors, empty states.
- A test or two, even simple ones.
Write a README for every project
A good README has:
- What the project does, in one or two sentences, and a screenshot.
- How to run it locally.
- The main technologies and why you chose them.
- One difficult problem you solved and how.
- What you would improve next.
Reviewers often read the README and nothing else. Make it count.
Present it simply
A single page that links to each project, its live demo and its repository is enough. Spend your time on the projects, not on animations.
Be honest
Say which parts you built and which came from a template or tutorial. Interviewers will ask, and honesty about what you learned is worth more than a polished claim you cannot explain.
Want to practise this properly?