How to explain a coding project in an interview
A plain way to walk through a small coding project in an interview: what you built, where you got stuck, and what you would change next.
An interviewer says "Tell me about a project you built." What do you actually say?
Short answer: tell it in four parts. What it does and why you built it, how it works, where you got stuck and how you got unstuck, and what you would change next. Keep the first pass to about two minutes, then let the interviewer pick what to dig into.
This post gives you that structure, a worked example using a small project, the follow-up questions you should expect, and the mistakes that make a good project sound weak. The project doesn't need to be big. A small one you understand completely beats a large one you can't explain.
Why interviewers ask this
The question isn't really about the project. It is a way to find out things a quiz can't:
- Do you understand your own code? Can you explain why it works, not just that it works?
- How do you handle problems? Every project has a moment where something broke. What did you do?
- Can you explain technical things clearly? You will do this every week on a team.
- Do you think about trade-offs? Knowing what you would change shows judgment.
That is good news. You don't need an impressive app. You need a project you can talk about honestly and in detail.
The four-part walkthrough
Use this order. It works for a tip calculator and for a full-stack app.
- What and why (20 seconds). One sentence on what it does, one on why you built it.
- How it works (40 seconds). The main pieces and how data moves through them. Pick the one or two most interesting parts, not every file.
- Where you got stuck (40 seconds). One real problem, what you tried, and what fixed it. This is the part interviewers remember.
- What you would change (20 seconds). One improvement and why. It shows you can look at your own work critically.
That is about two minutes. Then stop and let them ask questions. A short, clear walkthrough invites follow-ups. A ten-minute monologue doesn't.
A worked example: a tip calculator
Say you built a tip calculator, like the project in Project Tip Calculator (opens in a new tab). It takes a bill, a tip percentage and a number of people, and shows what each person pays. Here is the core of it:
function splitBill(bill, tipPercent, people) {
if (people < 1) return null
const total = bill * (1 + tipPercent / 100)
return Math.round((total / people) * 100) / 100
}
splitBill(84.5, 18, 3) // 33.24Here is how the four parts might sound out loud.
What and why: "I built a tip calculator that splits a restaurant bill between friends. I wanted a small project where I had to handle user input and do math that had to be exactly right, because people notice when money is off by a cent."
How it works: "There is one function, splitBill, that takes the bill, the tip percentage and the number of people. It works out the total with tip, divides it, and rounds to two decimal places. The page reads the three inputs and shows the result."
Where you got stuck: "At first the results had long decimals, like 33.236666. I tried toFixed(2), which looked right, but it returns a string, so the next calculation that used it started joining text instead of adding numbers. I switched to Math.round on the value times 100, then divided by 100, which keeps it a number. I also realized nothing stopped someone entering zero people, so I added a check that returns null for that."
What you would change: "Rounding each person's share means the shares don't always add up to the exact total. Next I would work in whole cents and give the leftover cent to one person, so the numbers always match the bill."
Notice what that does. It is short, specific and honest. It shows you understand the difference between a string and a number, that you test edge cases, and that you can see your own code's limits. That is far more convincing than a big feature list.
Questions to expect, and how to answer them
After the walkthrough, interviewers dig in. Prepare for these:
| They ask | What they want to know | How to answer |
|---|---|---|
| "Why did you build it this way?" | Whether you made choices or copied | Name one decision and the alternative you considered |
| "What was the hardest part?" | How you handle problems | One specific bug, what you tried, what worked |
| "How would you test it?" | Whether you think about edge cases | List inputs that could break it: zero, negatives, empty |
| "What would you do with more time?" | Judgment and self-awareness | One concrete improvement and why it matters |
| "Can you walk me through this line?" | Whether you understand your own code | Explain it in plain words, then what it returns |
| "Did you use AI for this?" | Honesty, and whether you understand it | Say yes or no, then explain what you checked or changed |
That last one comes up more often now. There is nothing wrong with having used an AI assistant. What matters is that you can explain every line as if you wrote it. Are coding interviews dead? What AI changed covers how interviews have shifted.
How to prepare
The night before is too late to understand your project. A week before, do this:
- Pick one project. Choose the one you understand best, not the one that sounds most impressive.
- Reread the code. Make sure you can explain every function. If a part is fuzzy, that is what they will ask about.
- Write down your stuck moment. One real problem, in a few sentences. If you can't remember one, break something on purpose and fix it.
- Say it out loud. Time yourself. Aim for about two minutes. Say it to a friend, or record yourself.
- Have the code ready. If the interview is remote, have the project open so you can share your screen and point at the line you are talking about.
Common mistakes
- Listing features instead of telling a story. "It has login, a dashboard, dark mode and search" says what, not how or why. Pick one part and explain it properly.
- Picking a project you can't explain. A big project you followed from a tutorial falls apart at the first "why". A small one you built yourself holds up.
- Saying it had no problems. Every project has problems. "It went smoothly" sounds like you didn't build it, or didn't notice.
- Talking for ten minutes. Give the two-minute version and let them choose where to go deeper.
- Getting defensive about weaknesses. When they point out a flaw, agree if it is fair and say how you would fix it. That is exactly the conversation they want.
Quick recap
- Use four parts: what and why, how it works, where you got stuck, what you would change.
- Keep the first pass to about two minutes, then let the interviewer ask.
- A small project you understand completely beats a big one you can't explain.
- Your stuck moment is the most memorable part. Prepare it.
- If you used AI, say so, and be ready to explain every line.
Frequently asked questions
How long should I talk about a project in an interview?
About two minutes for the first walkthrough. That is long enough to cover what it does, how it works, one problem and one improvement. Then let the interviewer ask follow-up questions.
What if my project is small or simple?
That is fine, and often better. Interviewers care more about how well you understand it than how big it is. A small project explained in detail shows more than a large one explained vaguely.
Should I talk about a tutorial project?
Only if you changed it or extended it yourself. Explain what you added and why. If you only followed along, interviewers usually find out with the first "why did you do it that way?" question.
What if I used AI to help build my project?
Be honest about it. What matters is that you understand the code and can explain the decisions in it. Say what the AI helped with, and what you checked, fixed or changed.
What if they ask about something I don't know?
Say you don't know, then say how you would find out. "I haven't handled that yet. I would start by testing it with an empty input and see what breaks" is a strong answer.
Practice
Build something small you can explain end to end. The Project Tip Calculator (opens in a new tab) project is a good size for this walkthrough, and Project About Me (opens in a new tab) is a shorter option. Each runs in your browser, so there is nothing to install. When you are done, practice the four-part walkthrough out loud. Then read JavaScript interview questions for junior developers for the technical questions that often follow.
Keep going
JavaScript Basics (opens in a new tab) gives you small projects you can explain line by line, which is exactly what this question rewards. When you want a bigger project to talk about, Intermediate JavaScript (opens in a new tab) ends with an app that fetches and filters real data.
