For a junior candidate with limited work history, discussing projects is often where most of the actual interview happens. Getting this right matters more than almost anything else covered so far.
What it does (one sentence) → why you built it / what problem it solves → what you specifically built and decided → a real challenge you hit and how you solved it → what you'd improve now. The middle two are what most candidates skip, and they are what actually distinguishes a real answer from a rehearsed summary.
"What was a challenge you ran into" is almost always asked, in some form, and it is the strongest opportunity to show real problem-solving. A specific technical obstacle, described honestly — what went wrong, how you diagnosed it, how you fixed it — is far more convincing than claiming everything went smoothly, and it is more interesting to listen to.
Weak: "It went pretty smoothly, no major issues."
Stronger: "The trickiest part was getting the drag-to-reorder feature
working with local storage — the order would reset on refresh because
I was only storing the task data, not the order. I ended up storing
an explicit position field on each task and sorting by that on load."An interviewer will often go deeper on one detail rather than moving to the next project: why this approach and not another, what would happen at a larger scale, what would break it. This is not hostility — it is exactly how a real interview checks whether you understood what you built or copied a working pattern without following it, which is the difference the earlier self-assessment lesson raised directly.
Before any interview, re-read your own code for the projects you plan to discuss. It is a common and avoidable mistake to forget the specifics of your own decisions under pressure, simply because time has passed since you wrote it.
Be precise and honest about your specific contribution rather than describing the whole project as though you built it alone. "I worked on the authentication flow and the dashboard UI; a teammate handled the backend API" is a stronger, more credible answer than a vague "we built this together" that leaves your actual role unclear.
Lead with the project you understand most deeply and can defend under sustained questioning — not necessarily the most visually impressive one. A simple project you can discuss for ten minutes without running out of substance is worth more in an interview than an elaborate one you can only describe at the surface.