“Walk me through a project you're proud of” sounds like a softball. It isn't. It's where a lot of genuinely strong engineers fall apart — not because the work was weak, but because they narrate it as a feature list, lose the thread, and never get to the part the interviewer actually cares about. Here's a structure that fixes it.
What the interviewer is actually listening for
They are not testing whether you can recite what the project does. They're listening for evidence of four things: can you scope a problem, make a defensible decision, understand the trade-off you made, and reflect on it honestly? Everything below is designed to surface those four things fast.
The five-beat structure
Any project explanation fits in five beats. Aim for about two minutes total, then let follow-ups pull out the detail.
1. The problem (1 sentence)
What needed solving and why it mattered. Not the tech — the problem. “Our onboarding emails were sent synchronously, so a slow mail provider could take down signups.”
2. Your role (1 sentence)
What you specifically owned. Interviewers are allergic to “we” with no “I” behind it. “I owned the redesign end to end.”
3. The key decision (the heart of it)
The one or two decisions that mattered, and — critically — the alternative you rejected. “I moved it to a job queue. I considered just adding a timeout, but that didn't fix the coupling, so I decoupled it with a queue and a worker.” The rejected alternative is what signals real engineering judgment.
4. The trade-off (what it cost)
Every decision costs something. Naming it is the single biggest credibility signal you can send. “The queue added operational complexity and eventual-consistency edge cases I had to handle.” Engineers who only describe upsides sound junior.
5. The reflection (1 sentence)
What you'd do differently, or what you learned. “If I did it again I'd add dead-letter handling from day one instead of bolting it on later.”
The mistakes that make strong work sound weak
- The feature tour. Listing everything the project does. Interviewers tune out by the third feature. Pick the one interesting decision and go deep.
- All “we,” no “I.” If they can't tell what you did, they can't credit you for it.
- No trade-off. Describing only the wins reads as not understanding your own system.
- Starting with the tech stack. “It's a React app with a Node backend and Postgres…” tells them nothing about your thinking. Start with the problem.
- No ending. Trailing off into “…and yeah, that's pretty much it” undoes a good answer. Land the reflection.
Prepare two projects, deeply
You don't need to be ready to discuss everything you've built — you need two projects you can go five layers deep on. Pick the ones with the most interesting decisions, not the biggest scope. A small project with a sharp trade-off beats a huge one you can only describe at the surface. More on choosing and framing GitHub projects here.
Rehearse it out loud — ideally on your real code
This structure only helps if you can produce it under pressure, which means saying it aloud until it's automatic. Greenroom reads your GitHub and asks you to walk through your actual projects, then follows up exactly where a real interviewer would — “why not a timeout?”, “what broke?” — so you rehearse the real thing, not a script. Free tier to start.
Frequently asked questions
How do I explain a project in an interview?
Use a five-beat structure: the problem in one sentence, your specific role, the key decision (including the alternative you rejected), the trade-off it cost, and a one-sentence reflection on what you'd change. Aim for about two minutes and let follow-up questions pull out the detail.
What are interviewers looking for when they ask about a project?
Evidence that you can scope a problem, make a defensible decision, understand the trade-off you made, and reflect honestly. They're evaluating your judgment, not testing whether you can recite what the project does.
Why do I ramble when explaining my projects?
Usually because you narrate every feature instead of going deep on one decision, and because you haven't rehearsed it out loud. Picking one interesting decision, naming its trade-off, and practicing the answer verbally fixes most rambling.
How many projects should I prepare to discuss?
Two, but deeply — ones you can go several layers deep on, with an interesting decision and a real trade-off. A small project with a sharp decision beats a large one you can only describe at the surface.