How to build a portfolio that shows real work

Quality beats quantity. A reader will look at your first two or three projects and probably stop. Pick the ones that show your best and most relevant work, and leave out the rest.

Choose projects that match the jobs you want. If you want to be a backend developer, a polished API with documentation and tests will say more than a pretty landing page.

For every project, answer a few questions in plain language. You can do this in a short page or a README.

• What is it and who is it for? One or two sentences.
• What problem does it solve?
• What did you build, and which parts did you do yourself if it was a team project?
• Which tools did you use, and why did you choose them?
• What was the hardest part, and how did you deal with it?
• What would you improve if you had more time?

The last two questions are the ones that matter most. They show how you think, which is what a hiring manager actually wants to see.

A live link beats a screenshot, and a screenshot beats nothing. If you can host a project for free, do. If it needs a login, add a demo account on the page.

Check every link before you share your portfolio. A broken demo link is one of the most common reasons a good portfolio fails.

For code, a clean repository with a clear README is part of the product. State what the project does, how to run it, and how to run the tests.

Most people start here, and it is fine. You can build credible projects without a client.

• Rebuild something real: a small booking tool for a local business, a tracker for something you care about, a tool that fixes an annoyance in your own life.
• Contribute to an open-source project, even with a small fix or a documentation improvement. It shows you can work in other people's code.
• Do a volunteer project for a friend, a community group or a small shop. A real user with real needs teaches more than any tutorial.
• Write about what you learned. A short post that explains a problem and how you solved it shows your thinking.

Avoid presenting a tutorial project as your own original idea. Interviewers have seen the same to-do app and weather app hundreds of times. If you followed a tutorial, say so, then show what you changed or added.

For design roles, polished screens are not enough. Show the problem, your early sketches, the options you rejected and why, and the result. Hiring managers want to see how you decide.

If you can, add what happened after launch: what changed, what users said, what you would do differently. If you cannot share a client's work for confidentiality reasons, say so and describe the case in general terms.

Your portfolio site does not need to be a showpiece. A clean, fast page with your name, a short introduction, your projects and your contact details is enough.

• Make sure it works on a phone, because many people will open the link there.
• Keep the loading time low and avoid heavy animations.
• Put your email and links to your GitHub and LinkedIn where they are easy to find.
• Include a short, friendly line about what kind of work you are looking for.

Update it every few months. A portfolio that was last changed three years ago suggests you stopped growing, even if you did not.

Ask a friend or a former colleague to open your portfolio and tell you what they understood in the first minute. If they cannot say what you do and what you want, the first screen needs work.

• Read every project description aloud. Cut anything that sounds like marketing and keep what is plain and true.
• Remove secrets from your code, such as API keys and passwords, and check your commit history too.
• Make sure you have the right to show each project. Do not publish a client's private work without their permission.
• Use the same name and photo across your portfolio, GitHub and LinkedIn, so people know they are looking at the same person.

When you apply for a job, link to the two projects most relevant to that role instead of the whole site. It saves the reader time and shows you read the post.