Portfolio projects: what to build so you actually get hired

The governing principle

A portfolio project does one job: convince a stranger that you can be trusted with work. Everything else is detail.

Which leads to a practical conclusion: choose not what interests only you, but what resembles the work you want to be given.

Choosing a subject

Look at the postings you like. Write down what they ask for. If five of seven mention the same set of technologies, there's your stack.

Take a problem from the field you're aiming at. Going into financial services? Build something about money and accounting. Healthcare? Records and scheduling. It shows you understand what you're walking into.

Solve a real problem of your own. The most convincing projects grew out of a personal annoyance. People talk about those differently — with detail, not from memory.

What the project should be

• Finished. There's a link that opens and works.
• Small. One clear problem, solved completely.
• Full-cycle. Storage, logic, interface, deployment. Even a small project can show all four.
• Explicable. For any "why this way", you have an answer.

What doesn't work

• Projects built along with a course, following the instructor.
• Clones of well-known services with no idea of your own.
• Vast unfinished ambitions: "building a social network, sign-up is done".
• Five projects in a row on the same theme and stack.

How many

Two or three strong ones beat seven weak ones. Whoever reads your CV will open the first, maybe the second. If the first doesn't convince, they never reach the third.

What strengthens any project

Working with others. If it was built with someone, you gain what solo builders lack: an account of how you negotiated, split the work and reviewed each other's code.

And if your part was described by the person you worked with, the question "what exactly did you do" answers itself — especially with your change history visible next to it, ready to be opened.