How to Talk About a Project You Built Solo in an Interview

TL;DR

Most candidates describe their project without explaining the problem it solves, the decisions they made, or what was hard. That's what interviewers actually want to hear.
The five-minute walkthrough has a structure: problem, approach, technical decisions, what was hard, what you'd do differently.
When they ask about a technology choice you made without much thought, say so honestly and explain what you know now.
A project that didn't go well can still be talked about well. The learning matters more than the outcome.
Practice the walkthrough out loud. It will feel disorganized until you've done it four or five times.

In almost every entry-level engineering interview, someone will say "tell me about a project you've worked on." If you've built anything substantial outside of coursework, that means your solo project is going to come up.

Most candidates are not ready for this. They describe the project in vague terms ("it's a web app that lets you track your workouts"), mention the tech stack, and then trail off. The interviewer asks a follow-up. The candidate gets flustered.

This happens because talking about a project well is a different skill from building it. The interview requires you to narrate technical decisions, explain tradeoffs, and be honest about what was hard and what you'd do differently. Building the project doesn't automatically give you that narrative. You have to construct it separately.

Here's how.

What Interviewers Are Actually Listening For

When an interviewer asks about your project, they have several questions running in parallel:

Does this person understand what they built? Not just what it does, but why it works the way it does. Can they explain their decisions at a technical level?

Did they make real decisions, or did they just follow a tutorial? Tutorials produce code, but they don't produce engineers who understand why the code is structured the way it is. The follow-up questions will surface this difference quickly.

Can they identify what was hard and why? This signals self-awareness and genuine engagement with the problem. It's much more interesting than a list of features.

Would they do it differently with more experience? Engineers who reflect on their work and can articulate what they'd improve are more likely to grow. Engineers who think the first version was fine often aren't.

Your project walkthrough needs to give the interviewer answers to all of these without them having to pry it out of you.

The Five-Minute Walkthrough Structure

Practice a version of this structure until it flows naturally. You're not memorizing a script. You're building a mental map of your project's narrative so you can adapt it based on how much time you have.

1. The problem (30-60 seconds)

Start with what problem the project solves and why it's worth solving. This does not need to be a world-changing problem. It needs to be a real problem, even a small one.

"I built a CLI tool to manage my local development environment configs. I kept forgetting which version of Node I needed for different projects and kept breaking things. I wanted something that would store those settings and let me switch between them quickly."

That's more interesting than "I built a CLI tool in Python." It shows that there was a real motivation. Interviewers want to understand what you were trying to do before they hear how you did it.

2. The approach (1-2 minutes)

Describe your technical approach at a high level before getting into specifics. What kind of architecture did you use? What was the main data model? What were the core components?

"The core of it is a JSON config file per project stored in a hidden directory. The CLI reads and writes those files, and I have a small shell script that sources the right environment variables based on which directory you're in."

This gives the interviewer a mental model before you go deeper. It also demonstrates that you can explain a technical system clearly, which is a skill they're evaluating.

3. Key technical decisions (1-2 minutes)

Pick two or three decisions you made that were actually decisions: things where you had options and chose one. Explain why you chose what you chose.

"I considered using a database to store the configs instead of flat files, but for the scope of the problem flat files felt simpler to distribute and didn't require any setup. If I were building this for multiple users to share configs, I'd probably reconsider that."

This is where most candidates miss the mark. They describe what they built but not why. The "why" is what interviewers are actually after. It shows you understand tradeoffs.

4. What was hard (1 minute)

Pick one thing that was genuinely difficult. This doesn't need to be a dramatic bug. It can be a design question you had to think through, a concept you didn't understand initially, or a constraint that forced you to rethink your approach.

"The hardest part was handling the edge cases around path resolution. When you're multiple directories deep in a project, figuring out which config to apply required some trial and error. I ended up reading about how shell variable scoping works, which I hadn't really understood before."

Interviewers remember this part of the answer. It tells them you engaged with real problems rather than avoiding them.

5. What you'd do differently (30-60 seconds)

This is the reflection that separates candidates who are still growing from candidates who have stopped. Name something concrete.

"If I were rebuilding it, I'd write tests from the start. I added a few after the fact but there are edge cases I'm still not confident about. I didn't appreciate how much tests would have saved me during the debugging phase."

You don't need to criticize the whole project. One specific, honest reflection is enough.

How to Practice the Walkthrough

This structure will feel stilted the first time you say it out loud. That's expected.

The way to get comfortable with it is to explain your project to someone who doesn't know anything about it. A friend, a family member, anyone. If they can follow along and understand what you built, why you built it, and what was hard, you're ready. If they look confused, you need to work on the explanation.

Also practice on your own, out loud. Talking through a technical project feels different from thinking through it. You'll discover things you don't know how to explain in words, which tells you where your understanding has gaps.

Time yourself. A five-minute walkthrough that covers all five elements is the target. If you're running over eight minutes unprompted, you're probably going too deep on implementation details. If you're done in two minutes, you're probably leaving out the decisions and the hard parts.

After you've practiced a few times, have someone ask follow-up questions. The follow-ups are where you need to be ready to go deeper.

When They Ask About a Technology Choice You Made Without Much Thought

This happens often. "Why did you choose Postgres over SQLite for this?" And you chose Postgres because it was what the tutorial used, and you didn't actually think about it.

The wrong answer is to fabricate a justification you don't have. Interviewers will probe it and the facade will fall apart.

The right answer is honest and shows curiosity: "Honestly, I chose it partly out of familiarity. In hindsight I'm not sure that was the most considered decision. If I were making the choice now, I'd think more about [what you'd actually consider]. Is there something about that choice that stands out to you?"

That answer does three things. It's honest, which is disarming. It signals that you think about decisions, even when you didn't make the first one carefully. And the final question invites the interviewer into a conversation where you can actually learn something.

Interviewers don't expect junior engineers to have made every decision perfectly. They do expect you to be honest about what you know and curious about what you don't.

How to Talk About a Project That Didn't Go Well

Some candidates feel they can't talk about a project that failed or was never finished. That's not true. You just need to frame it correctly.

The framing: what you were trying to do, what went wrong and why, what you learned, what you'd do differently.

"I started building a real-time chat application and I ran into serious performance problems when I tried to implement presence (showing who's online). I didn't understand WebSocket state management well enough at the time and I got stuck. I ended up stepping back to learn more about the underlying concepts before trying again. I never finished the original project but I understand the problem much better now."

That answer shows more maturity than a candidate who only talks about polished finished projects. It tells the interviewer that you can face difficulty honestly and reflect on it without getting defensive.

What to avoid with a struggling project: framing it as something that was abandoned without any reflection ("I just ran out of time" or "it got complicated"). That answer tells the interviewer nothing useful.

For more on how to present your projects on paper before the interview, see how to write a project case study for your portfolio.

Common Follow-Up Questions and How to Handle Them

"How would you scale this?"

This is common even for simple projects. You don't need to have a detailed distributed systems answer. You need to show you can think about it.

"Right now it's a single server with no caching. If I had to scale it, the first thing I'd look at is where the bottlenecks actually are, probably database reads. I'd consider read replicas or a caching layer depending on the read/write pattern. But I'd want to measure first rather than assume."

"What would you add if you had more time?"

Have a real answer ready that shows you understand what the project actually needs, not just what would be cool to add.

"Did you work with anyone on this?"

If it was solo: "I built this on my own, which meant I had to make all the decisions myself. That was challenging because there was no one to sanity-check my approach, but it also forced me to think through everything more carefully."

"How does this compare to similar tools that already exist?"

This tests whether you researched the space before building. If you did: great, explain what you found and what your project does differently. If you didn't: say so honestly and note what you know now.

Connecting Your Project to the Role

When you know what role you're interviewing for, you can connect your project to it. If the company builds consumer web apps and your project is a web app, connect the domains. If they work with a tech stack similar to yours, mention that. If the problem your project solves is adjacent to what the company works on, note that.

This isn't about overselling. It's about helping the interviewer see you in context. "I built this as a way to understand how [technology] works, which I know you use pretty heavily here" is a simple, natural connection.

For guidance on which projects are worth building in the first place, see how to pick a portfolio project. For how to handle behavioral questions about past work more broadly, see behavioral interviews: what they're actually testing.

Your project walkthrough is one of the most controllable parts of an entry-level interview. Unlike algorithmic problems, you already know everything about your project. The work is in building a clear, honest narrative about it and practicing until that narrative is fluent.

That's preparation you can do before the interview, not during it.

If you want structured support preparing your project narrative and overall interview approach, here's how the Globally Scoped program works.