"Tell me about a project you have worked on." It is the most predictable question in any developer interview, and builders still fumble it. Not because they do not know their project — they know it better than anyone alive — but because knowing something and explaining it in ninety seconds to a stranger are different skills. This post gives you the second one.
Why builders struggle with the easiest question
Most answers fail in one of two directions. The first is the feature tour: "So it has login, and then a dashboard, and then you can add items, and there is a settings page..." — a list of screens that tells the interviewer nothing about how you think. The second is the tech-stack recital: "I used React, Node, Express, MongoDB, JWT, Tailwind..." — a list of nouns that any tutorial produces.
Interviewers are not asking what the project has. They are asking what decisions you made and whether you understood them. Once you know that, the structure writes itself.
The five-part script
1. Problem (10 seconds)
One sentence, in human language, about who has the problem and why it hurts. "Splitting the hostel mess bill across forty people was a monthly WhatsApp war." No technology yet.
2. Decision (20 seconds)
The one or two most important choices you made and why. Not the stack — the decision. "I stored every expense as an event rather than updating balances in place, because people kept editing old entries and the balances would drift."
3. Trade-off (20 seconds)
What that decision cost you. This is the part that separates builders from copiers, because you only know the cost if you paid it. "That meant recomputing balances on every load, which got slow past a few hundred expenses, so I added a cached snapshot per month."
4. Result (15 seconds)
What happened when real people used it, or what it can do now. Be concrete and modest. "Twelve people in my hostel use it every month. Settlements dropped from about fifteen transfers to three or four."
5. What you would change (15 seconds)
Every good engineer has a list. Saying yours proves you have kept thinking. "If I rebuilt it I would move settlement logic to the server, because the client-side version cannot handle two people editing at once."
Total: about ninety seconds. Then stop talking and let them ask.
A full sample answer
"I built a mess-bill splitter for my hostel. Forty people, one kitchen, one monthly bill, and every month a two-hour argument on WhatsApp about who owed what. The main design decision was to treat every expense as an immutable event instead of updating balances directly — people kept editing old entries, and with direct updates the totals would silently drift. The trade-off was speed: recomputing everything on each load was fine at first but got sluggish after a few hundred entries, so I added a monthly snapshot and only replay events after it. Twelve people on my floor use it now, and settlements went from around fifteen transfers a month to three or four, because I compute the minimum set of payments. If I did it again I would move the settlement logic server-side; right now two people editing at once can produce a wrong total, and that is the bug I would fix first."
Read that aloud. It is under ninety seconds, it names one problem, one decision, one trade-off, one result and one regret, and there is not a single framework in it. The interviewer now has five things to dig into, and every one of them is something you actually did.
Mistakes that sink good projects
- Starting with the stack. "It's a MERN app" is the least interesting sentence you can open with. Open with the problem.
- Claiming the whole thing when it was a team. Say exactly which part was yours. Interviewers will ask, and vagueness reads as dishonesty.
- Hiding the ugly parts. The bug that ate a weekend is your best material. It proves the project was real and that you debugged it.
- Not being able to go one level deeper. If you say "I used JWT for auth", expect "why not sessions?" If you cannot answer, do not lead with it.
- Talking for four minutes. Ninety seconds, then let the interviewer steer. A conversation beats a monologue.
How AI interviews probe project depth
More first rounds are now run by AI interviewers, and they are very good at exactly this question. A well-built AI interview reads your project before it asks anything, so the questions are specific from the start: "Why events instead of direct balance updates?" — and it follows up when an answer is vague. It also checks that what you say matches what the code shows.
That is good news for people who built their own work. The five-part script maps directly onto what the interviewer is scoring: a clear problem, a justified decision, awareness of the trade-off, a concrete outcome, and honest reflection. Our AI interview preparation guide goes deeper on what to expect and how to set up.
Practice, the boring way
Write the five parts as five lines. Say them to a wall with a timer. Do it five times. Then have a friend ask "why?" after every sentence until you hit something you cannot answer — that is what you study tonight. By the fifth attempt the awkwardness is gone and the ninety seconds feel like nothing.
On Iber, this conversation is built into how you get hired: your verified project and your 60-second demo feed a structured AI interview, and companies see all three together — the work, the demo, and how well you understand what you built. If you have a project worth explaining, apply for Wave 1. Builders are always free.