Explain decisions

What you will be able to do

Explain a project so that the listener trusts you. Interviewers and colleagues learn the most from how you explain choices and failures, not from the list of tools that you used.

Before you startWhat to know and to have readyAbout 30 minutes

What you need to know

• The parts of a good README, and how to link each claim to evidence, from Portfolio anatomy: The parts of a good README and Portfolio anatomy: Link every claim to evidence.

What you need

• Your two project briefs, under ## Project briefs in notes.md, from Portfolio anatomy: Guided practice: two project briefs.
• For the practice, a way to measure two minutes, such as the clock on your phone.

Tell the decision, not only the result

“I built a duplicate-invoice checker in Python” tells the listener what exists. It does not tell them how you think. A decision story does. It has five parts:

1. The situation: what you needed to decide.
2. The options: at least two real alternatives.
3. The choice and the reason: what you chose, and why it fit this problem.
4. The cost: what the choice made worse. Every choice has one.
5. Looking back: what you would keep, or change, now.

Here is Daniela’s decision story:

I had to decide between fixed rules and a machine learning model for finding duplicates. A model could learn patterns that I had not thought of. But I knew the problem types from my work, I had no labelled real data, and accountants must be able to check why an invoice was flagged. So I chose rules. The cost is that the rules miss types that I did not write, such as duplicates after a partial credit. Looking back, I would keep the rules, and add a report of the near misses, so that new problem types become visible.

It takes about 40 seconds. It shows domain knowledge, a real alternative, a reason tied to the users, an honest cost, and a next step.

Talk about failure cases

Every system fails somewhere. People who have built real systems know this, so they listen for it. Saying where your project fails is not weakness. It shows that you tested it.

A good failure description has a specific case, the reason, and what you did or would do:

Weak: “It works well in most cases.”

Strong: “It misses two of the 24 duplicates. Both are invoices where the supplier sent a credit for part of the amount, so the amounts differ. I documented this as a limitation, rather than make the matching looser, because looser matching gave 15 false alarms instead of 3.”

Say exactly what you did

In team projects, the listener needs to know your part. “We” hides it. Use “I” for what you did, and “we” or a role name for what others did.

Exaggerated or vague	Honest and specific
“I built an AI system for invoices.”	“I wrote a rules-based Python script that flags likely duplicate invoices.”
“We built the classifier.”	“The ML engineer trained the model. I wrote the test set of 300 warranty tickets and found why warranty results were low.”
“It is 99% accurate.”	“On 200 synthetic invoices, it found 22 of 24 planted duplicates, with 3 false alarms.”
“Expert in machine learning.”	“Completed courses in Python and statistics. One project with a baseline and an evaluation.”

Honest language does not make your work look smaller. Interviewers ask follow-up questions. An exaggerated claim fails at the second question, and then they doubt everything else. A specific claim survives every question, because it is true.

The two-minute walkthrough

A walkthrough is a short spoken explanation of one project, for example at the start of an interview. Two minutes is about 250 to 300 spoken words. Use this shape:

Time	Part	Content
0:00–0:20	Problem	Who has it, and why it matters.
0:20–0:40	Data and approach	What you used and built, in one or two sentences.
0:40–1:10	One decision	A short decision story.
1:10–1:35	Evaluation and failure	The result against the baseline, and one failure case.
1:35–2:00	Limits, next step, your part	What you would do next, and what you did yourself.

Two minutes is short on purpose. The listener chooses what to ask about next. A good walkthrough makes them want to ask.

Worked example: Daniela’s walkthrough outline

An outline is notes, not a script. Daniela writes:

• Problem: accounts teams pay invoices twice, because one invoice arrives by email and post with small differences. In my job, we found several each year, usually after payment.
• Data and approach: 200 synthetic invoices, 24 planted duplicates. A Python script that cleans invoice numbers and compares supplier, amount and number.
• Decision: rules versus a model. Rules, because I knew the problem types, had no labelled real data, and accountants must see why an invoice was flagged.
• Evaluation and failure: exact matching found 12 of 24. Mine found 22, with 3 false alarms. It misses duplicates after partial credits.
• Next and my part: test on a public invoice dataset, report near misses. All of it is mine. The problem types come from seven years in accounts.

Guided practice: your walkthrough

1. In notes.md, add a heading: ## Walkthrough.
2. Write a walkthrough outline for your project 1, with the five parts. Use notes, not full sentences.
3. Write one decision story with all five parts: situation, options, choice and reason, cost, looking back.
4. Say the walkthrough aloud, and time it.
5. If it is longer than two minutes, cut details from the approach, not from the decision or the failure case.

Your project may not be finished yet. Then write the outline with your planned decisions and expected results, and mark them as planned. Update it when the project is finished.

Check: your walkthrough has a baseline, a failure case, and a clear sentence about your part. It contains no claim that your evidence cannot support.

Independent variation: ask a friend or colleague to listen, and to ask you two questions afterwards. Write down the questions. They show you what was unclear, and what interviewers may ask.

Common mistake

Exaggerating to impress

Symptom: in an interview, you describe your project as “an AI system that automates invoice checking”. The interviewer asks, “Which model did you use, and how did you train it?” You must explain that there is no model. The interviewer now doubts your other answers.

Cause: you used the words that sound most impressive, not the words that describe the work.

Fix: describe the work exactly: “a rules-based script”. Then explain why rules were the right choice. A clear reason for a simple solution impresses experienced people more than a large word without a reason.

Check your understanding

Why should a decision story include the cost of the choice?

Show the answer

Because every real choice has one, and people with experience know it. If you name the cost, you show that you compared real alternatives and understood the trade-off. If you name no cost, it sounds as if you did not see the alternatives, or are hiding the weak side.

Check your understanding

In a team project, the model was trained by someone else. You built the evaluation. How do you describe your part?

Show the answer

Say it exactly: “A colleague trained the model. I built the evaluation: I chose the test cases, wrote the scoring rules, and found the cause of the low warranty results.” Use “I” for your work and name the role for the other work. Evaluation is valuable work, and saying it clearly is stronger than a vague “we built a model”.

Recap

• Tell decision stories: situation, options, choice and reason, cost, and looking back.
• Describe failure cases specifically. It shows that you tested your work.
• Say exactly what you did. Use “I” for your work, and name the roles of others.
• A two-minute walkthrough covers problem, approach, one decision, evaluation with a failure, and your part.

Next, you map your evidence to a real job advertisement, and plan your interview practice.

Next: Prepare for applications