Most engineers I know are weirdly bad at talking about their own code. They built the thing. They made every decision. And then in an interview, when someone asks "tell me about a project you're proud of," they default to a kind of polished, abstract summary that sounds like a LinkedIn bio. The interviewer nods, asks one follow-up, moves on, and writes "communication: average" in the scorecard.
This is mostly fixable. The problem is rarely the project — it's the way you've been trained to talk about it. Below is what actually works, based on running and sitting in maybe 200 of these interviews.
What interviewers actually want to hear
The mistake most candidates make is treating this question as a chance to describe the project. The interviewer can read the README. They can scroll the repo. What they can't see is your reasoning. The whole point of the question is to find out:
- Did you make decisions, or did you just execute someone else's?
- When you made a decision, did you understand the trade-off you were making, or did you pick the default?
- What did you learn that you couldn't have learned from a tutorial?
If your answer doesn't surface at least one of these, you're not actually answering the question. You're giving a tour.
The "what / why / what broke" structure
This is the format I coach people to use. It's not a magic script — it's a way of forcing yourself to include the parts interviewers actually care about.
What it is (15 seconds, max)
One sentence. No history of how you started building it. No "I had this idea while I was at..." Just: what does it do, and who uses it.
Don't: "So I was on a flight back from a conference and I realized that there's this whole space of recipe apps that aren't really designed for..."
Do: "It's a CLI tool that diffs two database schemas and generates a migration. About 200 engineers use it now."
Why you built it the way you did (the meat — 2-3 minutes)
This is where most candidates fall flat. They describe the stack. "We used React, Node, Postgres." Nobody cares. What the interviewer wants is the fork in the road — a decision where you could've gone another way, and you didn't, and you know why.
Don't: "I used Postgres for the database."
Do: "I started with SQLite because the data fit on disk and I didn't want to run a server. When users wanted to share migrations between teammates, I moved to Postgres — not because SQLite couldn't have worked, but because the operational story for 'how do I let two laptops sync' was much cleaner with a shared connection string than with file replication."
Notice what just happened. You named a tool (Postgres). You named the alternative (SQLite). You named the constraint that forced the change (shared access between teammates). And you signaled that you considered the lazier path and rejected it for a specific reason. That's three signals in one paragraph — and you didn't say a single buzzword.
What broke, or what surprised you (1-2 minutes)
Every real project has a "huh, I didn't expect that" moment. The deploy that didn't work. The library that promised one thing and did another. The user who used the feature in a way you never anticipated. Interviewers light up at this part of the answer because it's the only part you can't fake — you either lived it or you didn't.
Do: "The thing that surprised me was how much state ended up in the URL. I started with a clean React-Router setup, and within a month every filter, sort order, and modal was a query param because users kept asking me to send them links to specific views. That was the right call — but it made the URL parser the most-edited file in the repo, which I didn't see coming."
The "github-aware" follow-ups that catch people out
Increasingly, interviewers will look at your repo before the call. (Some of us build tools that automate this, which is partly why I'm writing this post.) The follow-ups they generate from that scan tend to be uncomfortable, because they're asking about decisions you may not remember making.
"Why is this commit message empty?"
Honest answer: you were tired. Better answer: "Looking at it now, that was a five-minute fix for a UI bug — I should've written 'fix: dropdown z-index on mobile.' My commit hygiene drops when I'm context-switching, which is something I've worked on by writing the commit message before I write the code." That's not defensive — it's self-aware.
"Why did you choose [library X] when [library Y] is more standard?"
The wrong answer is to invent a justification on the spot. The right answer, if it's true, is: "I tried Y first. I hit [specific friction]. I switched to X." If you genuinely don't remember why, say so: "Honestly, I picked it because [colleague / blog post / I'd used it before]. If I were starting today I'd probably re-evaluate." Interviewers don't punish "I don't remember" nearly as hard as they punish a bad on-the-spot rationalization.
"Why isn't there a test for this function?"
Either own the gap ("I was moving fast and didn't backfill tests — that's a real weakness in the repo") or explain the trade-off ("That's a thin wrapper around a third-party SDK; I tested the SDK integration end-to-end instead of unit-testing the wrapper"). Both are fine. The wrong answer is to pretend the test exists somewhere.
One drill that actually works
Pick your most interesting repo. Open a voice recorder. Talk for three minutes about the most interesting decision you made in it. Don't write a script. Just talk. Then listen back.
The first time, you'll hear filler ("um, so basically, what I did was..."), false starts, and a tendency to describe instead of explain. The third time, you'll sound like someone who knows their own work. That's it. That's the whole secret. The interview version of this conversation is just the same drill with someone on the other end.
What not to do
- Don't lead with the tech stack. If your answer starts with "we used Next.js, Tailwind, and tRPC," you've already lost the interviewer's attention.
- Don't pretend a side project is bigger than it is. "Production traffic" with 12 users is fine — just call it 12 users. Interviewers smell inflation immediately.
- Don't bring a project you can't go deep on. If you contributed one PR to a library, that's not your project. Bring something where you wrote at least 60% of the meaningful code.
- Don't avoid your weaknesses. "If I were doing this again I'd structure the data layer differently" is one of the strongest things you can say. It means you've thought past the thing you shipped.
The compounding effect
Engineers who can talk about their code well don't just do better in interviews — they do better in standups, design reviews, and one-on-ones with their manager forever. The skill is not "how to interview." It's "how to be legible about your own work." Interviews are just the highest-stakes place that skill shows up.
Frequently asked questions
How do I talk about my GitHub projects without sounding rehearsed?
Prepare the structure, not a script: what it does, why you built it that way, and what broke. If you can answer unexpected follow-ups about real decisions, you'll sound natural — because you're remembering, not reciting.
What do interviewers want to hear about my projects?
Judgment: the decision you sweated over, the trade-off you accepted, the bug that taught you something. They're listening for evidence you understand your own code, not for a feature tour.
What are GitHub-aware follow-up questions?
Questions drawn from your actual code: "why this schema," "what happens when this cache dies," "why didn't you use X here." Interviewers increasingly skim your repos before the call — Greenroom trains you for exactly this by reading your GitHub and asking those questions first.
Should I rehearse project explanations word for word?
No — memorized answers collapse at the first follow-up. Drill the five beats (context, problem, decision, trade-off, result) out loud until the structure is automatic and the words stay fresh.