Tell the story of a project

Learning outcome

By the end of this lesson, you will be able to explain your project's decisions, trade-offs, and results in a way that shows your thinking — whether in an interview, a README, or a portfolio.

Why storytelling matters

Technical skill gets you an interview. Communication gets you the job. When you describe a project, you are not just listing what you built. You are showing how you think.

The STAR framework

For every project, prepare four sentences:

| Letter | Stands for | Example | |--------|-----------|---------| | S | Situation | "I noticed our team spent 30 minutes each morning restarting a crashed service." | | T | Task | "I needed to make the service recover automatically." | | A | Action | "I added a health check endpoint and configured Docker to restart on failure." | | R | Result | "The service now recovers in under 10 seconds, saving the team 2.5 hours per week." |

What a good project description includes

A README or portfolio entry should answer:

1. What does it do? One sentence.
2. Why did you build it? The problem it solves.
3. What technology did you use and why? Show intentional choice.
4. What was the hardest part? Shows depth.
5. What would you do differently? Shows growth.

Example: URL shortener

I built a URL shortener because I wanted to understand how redirects work. I used Python and Flask for the server and SQLite for storage. The hardest part was handling concurrent requests without corrupting the database — I learned about database locks and connection pooling. If I rebuilt it, I would add analytics to see how many times each link is clicked.

Notice this does not just list technologies. It shows reasoning and learning.

Common beginner mistakes

• Listing technologies without context. "Built with React, Node, and MongoDB" says nothing. "Chose React for the interactive dashboard, Node for the real-time API, and MongoDB for flexible event storage" shows intent.
• Being vague about results. "It worked well" is forgettable. "It handles 1000 requests per second with 200ms latency" is specific and memorable.
• Avoiding mistakes. Every project has things that went wrong. Describing what you learned from a mistake shows more maturity than pretending everything was perfect.

Practice task

Write a STAR description for your last project (even a small one). Read it aloud. If it sounds confusing, rewrite it. Ask a friend if they understand what you built and why.

Recap

• Use STAR (Situation, Task, Action, Result) to structure project explanations.
• A good README answers what, why, technology choices, hardest part, and lessons learned.
• Show intent behind technology choices, not just a list of buzzwords.
• Include mistakes and what you learned — it shows growth.

Next step

You have completed the full curriculum path. The next step is to keep building projects, share them, and revisit these lessons when you need a refresher. Welcome to the craft.