How to Talk About Your Own Projects in an Interview (Without Sounding Rehearsed)

"Tell me about a project you're proud of" is where most technically strong candidates give their weakest answer — a feature list ("I built the frontend with React and the backend with Supabase") instead of a story an interviewer can actually evaluate judgment from.

The shape that actually works

Problem, then decision, then result — the exact structure every case study on this site is written in, deliberately, because it's the same structure that works in an interview and for the same reason: it's the shape that reveals judgment, not just output.

• Problem — what was actually broken or missing, stated concretely. "The rental agency was taking bookings by phone and double-booking vehicles" is concrete; "I wanted to learn Next.js" tells an interviewer nothing about judgment.
• Decision — the specific tradeoff you made, and why. "I used a database-level exclusion constraint instead of an application-level check" is a real decision with a real alternative you rejected — that contrast is what actually demonstrates engineering judgment, not the choice in isolation.
• Result — what actually changed, ideally with a real number, but an honest qualitative result beats an invented number every time. A recruiter or engineer can tell the difference, and getting caught inflating a number costs more credibility than not having one.

Why a feature list fails as an answer

"I built X with Y and Z" answers a question nobody asked — what tools you used. It gives an interviewer no way to evaluate how you think, which is the actual thing the question is trying to assess. Two candidates who both used the identical tech stack can give wildly different-quality answers, because the quality lives in the decision and the reasoning behind it, not the tool names.

How to prep this without sounding rehearsed

Write the problem → decision → result structure down for two or three real projects, once, in bullet form — not a memorized script. Rehearsing a script produces a flat, rehearsed-sounding delivery; internalizing the actual shape of the story lets you tell it naturally, adapt it to what the interviewer actually asks, and go deeper on the specific decision they follow up on, because you understand the reasoning, not a memorized paragraph about it.