Portfolio anatomy

What you will be able to do

Plan projects that show what you can do, in a form that a busy reviewer can check in a few minutes. A small project that is clear and honest is worth more than a large one that nobody can understand.

Before you startWhat to know and to have readyAbout 35 minutes

What you need to know

• You completed Module 4.
• Frame, baseline, evaluation and the cost of errors, from Problem framing: Four questions that frame a problem and From baseline to deployment: Step 1: the baseline.

What you need

• Your eight-week plan and its deliverable, under ## Eight-week plan in notes.md, from Manage tools and costs: Guided practice: your eight-week starter plan.
• Your inventory with evidence, under ## Inventory with evidence, from Evidence over self-ratings: Guided practice: update your inventory. Each project brief names skills from it.
• Your project brief, under ## Project brief, from Team and business context: Guided practice: write a project brief, is useful here.

What a portfolio is for

A portfolio is a small collection of your work that other people can look at, usually two to four projects. Its job is simple: to give evidence for the skills that you claim.

A reviewer, for example a hiring manager, often spends only a few minutes on each project. In that time, they ask:

1. What problem does this solve, and for whom?
2. Does it work? How do I know?
3. What did this person do, and what did they decide?
4. Do they know its limits?

The project’s README answers these questions. A README is the first file that people read in a project: a short text document that explains it. On GitHub, it appears under the list of files.

The parts of a good README

Section	What it contains	The reviewer’s question
Problem	Who has the problem, what decision it affects, and why it matters. Two to four sentences.	What does it solve?
Data	Where the data comes from, how much, what it contains, and whether it is synthetic.	Can I trust the input?
Approach	What you built, and the main choices, with one reason each.	What did they do?
Evaluation	How you measured it, the result, and the baseline that you compared it with.	Does it work?
Demo	How to run it, with the expected output, or a screenshot or a short recording.	Can I see it?
Limitations	What it does not do, where it fails, and what you would do next.	Do they know its limits?
My part	What you did yourself. In a team project, be exact.	What did this person do?

These sections are the same parts that you met in Module 3: frame, baseline, evaluation and the cost of errors. A good portfolio project is a small version of a real AI project.

Worked example: Daniela’s README

Daniela’s week-8 deliverable is a script that finds duplicate invoices. Here is the outline of her README:

Problem. Accounts teams pay some supplier invoices twice, because the same invoice arrives by email and by post with small differences. This script finds likely duplicates before payment, so an accountant can check them.

Data. 200 synthetic invoices, made by me, with 24 duplicates planted on purpose: 12 exact copies and 12 near-duplicates (different spacing or dashes in the invoice number, or a date one day apart). No real company data.

Approach. I clean each invoice number (remove spaces and dashes, use capital letters), then compare the supplier, the amount and the cleaned number. I chose rules, not a model, because the problem types are known and the rules are easy for an accountant to check.

Evaluation. Baseline, exact match on all fields: finds 12 of 24 duplicates. My script: finds 22 of 24, with 3 false alarms in 200 invoices.

Demo. python check_invoices.py invoices.csv prints the likely duplicate pairs. Example output included.

Limitations. It misses duplicates when the second invoice has a different amount, for example after a partial credit. It is tested only on synthetic data. Next step: test it on a public invoice dataset.

My part. All of it. The problem types come from my seven years in accounts.

Notice what she does not write: “an AI-powered invoice solution”. It is a rules-based script, and she says so. The evaluation, with a baseline and false alarms, shows more skill than a big claim would.

Link every claim to evidence

Every claim in your CV or profile needs an arrow to a piece of evidence. A claim without one is a gap.

Text description of the diagram

• “I can write Python to check data” → the invoice-checker script, with tests.
• “I can evaluate a method honestly” → the results table, method compared with baseline.
• “I know where invoice checks go wrong” → the README, with 6 problem types and an example of each.
• “I can build machine learning models” → gap: no evidence yet. Remove the claim, or plan a project that gives evidence.

Do this check for every skill that you claim. For a gap, you have two honest options: remove the claim, or add a project to your plan that gives the evidence.

Plan two projects

Two projects are a good start. Choose them so that together they show your primary role:

• Project 1: small and soon. Your deliverable from the eight-week plan. It shows that you finish things.
• Project 2: closer to the target role. Later in your route. It shows the main skill of the role, for example evaluation for an evaluation specialist, or an AI feature for an AI engineer.

Where you can, use your domain. A project about a problem that you know from the inside is easier to explain, and it shows your head start.

Guided practice: two project briefs

1. In notes.md, add a heading: ## Project briefs.
2. Copy the template below twice: once for project 1 and once for project 2.
3. Fill in each line. For project 2, the approach can be uncertain: write what you plan.
4. For each project, write which skills from your inventory it gives evidence for.

Project:
Problem (who, which decision, why it matters):
Data (source, size, synthetic or public, licence):
Approach (what I build, and one reason):
Baseline:
Success measure (a number):
Limitations that I expect:
Skills that it gives evidence for:
Week when it is finished:

Check: each brief has a baseline and a success measure with a number, and data that you are allowed to publish.

Common mistake

A portfolio of tutorial copies

Symptom: your portfolio has three projects: a film recommender, a handwritten-digit classifier and a chatbot. Each one follows a popular online tutorial. A reviewer has seen the same projects many times, and cannot tell what you did.

Cause: tutorials are good for learning, but a copy shows that you can follow steps, not that you can make decisions.

Fix: change at least one important thing, and explain why. Better, choose a problem from your domain, with your own data or a public dataset. Write the evaluation against a baseline, and the limitations. Those sections show decisions, and decisions are what reviewers look for.

Check your understanding

Why is 'finds 22 of 24 duplicates, compared with 12 for exact matching, with 3 false alarms' stronger than 'finds 92% of duplicates'?

Show the answer

It gives the real numbers, so the reviewer can see how small the test was. It compares with a baseline, so the reviewer knows that the method adds value. It reports the false alarms, which shows that the author understands both kinds of error. “92%” alone hides all three.

Check your understanding

Your CV says 'experienced in deep learning', but your portfolio has no deep learning project. What are your two honest options?

Show the answer

Remove the claim, or plan a project that gives evidence for it, and keep the claim off your CV until the project is finished. A claim without evidence often leads to an interview question that you cannot answer, which damages trust in your other claims too.

Recap

• A portfolio gives evidence for the skills that you claim.
• A good README has: problem, data, approach, evaluation with a baseline, demo, limitations and your part.
• Link every claim to evidence. A claim without evidence is a gap: remove it or plan it.
• Plan two projects: a small one soon, and one closer to your target role, in your domain if possible.

Next, you practise how to talk about your decisions and your part in a project, without exaggeration.

Next: Explain decisions