Important things to know
Most technically skilled people struggle to talk about their own work. They can build the thing, but the moment someone asks "walk me through it," the explanation turns into a wall of jargon, a chronological info-dump, or both. That gap between doing good technical work and being able to describe it well quietly costs people interviews, promotions, and buy-in on their ideas.
This isn't a personality trait some people have and others don't. It's a skill, and a fairly learnable one, once you understand why explanations go wrong in the first place.
Why Smart People Explain Their Work Badly
There's a well-known psychology finding behind this, and it's worth knowing because it reframes the whole problem. In 1990, Stanford researcher Elizabeth Newton ran an experiment with two roles: "tappers," who tapped out the rhythm of a well-known song on a table, and "listeners," who had to guess the song from the taps alone. Tappers predicted listeners would guess correctly about half the time. In reality, listeners guessed correctly on <cite index="25-1">only about 2.5% of the 120 songs tapped</cite>. The tappers could hear the full melody in their heads as they tapped; they simply couldn't imagine what it sounded like to someone who couldn't.
That gap has a name: the curse of knowledge. Once you know something deeply, it becomes genuinely difficult to remember what it's like not to know it. This is exactly what happens when a developer explains a project to a recruiter, a hiring manager, or a non-technical stakeholder. You're tapping out a rhythm you can hear perfectly. They're just hearing taps.
The fix isn't "dumb it down." It's structure and that's what the rest of this guide covers.
1. Lead With the Problem, Not the Tech Stack
The most common mistake is starting with "I used React, Node, and PostgreSQL to build..." That tells the listener what tools you touched before they know why any of it mattered.
A better opening structure:
- State the problem in one sentence, in plain language: "Our team was manually reconciling spreadsheets every week and it kept causing errors."
- Only then introduce the tools, and only the ones relevant to the point you're making.
- Save deep technical detail for when someone asks a follow-up question, it signals you can go deeper without forcing everyone to sit through it upfront.
This single reorder (problem before tools) does more to make a technical explanation land than almost anything else on this list.
2. Use a Structure, Not a Chronological Retelling
Unstructured storytelling ("so first I tried X, then that didn't work, then I looked into Y...") is exhausting to follow and buries the point.
The STAR framework (Situation, Task, Action, Result) solves this, and it's not just a job-seeker trick. It's structured enough that firms like Boston Consulting Group reportedly coach candidates to use it, precisely because it gives interviewers the kind of clear, comparable answer that's actually useful to evaluate.
How to apply it to a technical project:
- Situation: One or two sentences of context on what was going on before you started.
- Task: What you specifically were responsible for (not the whole team).
- Action: The decisions you made and why, not just the steps you followed.
- Result: What changed, ideally with a number attached: time saved, errors reduced, users served.
Career coaches who study this closely note something important: <cite index="19-1">roughly 75–80% of a strong STAR answer should be the Action section</cite>, because that's the part that actually shows how you think, not just what happened around you.
3. Talk in Decisions, Not Just Steps
"I built a caching layer" is a step. "I added a caching layer because the database was getting hammered by repeated identical queries, and I chose Redis over an in-memory cache because we needed it to survive a server restart" is a decision and decisions are what actually demonstrate judgment.
Practical ways to build this habit:
- For every project you might discuss, write down one sentence answering "what was the alternative I didn't choose, and why?"
- Practice saying "I chose X over Y because Z" out loud until it feels natural, not scripted.
- If a project had a mistake or a wrong turn, keep that in the story. Recognizing what didn't work signals more maturity than a suspiciously perfect narrative.
4. Adjust the Altitude for Your Audience
The same project needs a different explanation depending on who's listening, and the biggest professional communication mistake is giving everyone the same version.
A simple way to calibrate:
- For a non-technical stakeholder or recruiter: stay entirely in outcomes and plain language. No framework names, no library names unless asked.
- For a hiring manager who's technical but not a specialist in your exact stack: name the tools, but explain the "why" behind each major choice.
- For a peer engineer: go as deep as they want; this is the one audience where more technical detail usually helps rather than hurts.
A good test: if you can't explain the project at the "non-technical" altitude at all, you likely don't fully understand why you made the choices you did, only that they worked.
5. Rehearse Out Loud, Not Just in Your Head
Explanations that sound complete in your head often fall apart the moment you say them out loud, because speaking forces you to commit to an actual sequence instead of jumping around associatively.
How to practice without it sounding memorized:
- Say your explanation to someone outside your field a friend, a family member, anyone who'll ask "wait, what does that mean?" honestly.
- Keep each project explanation to roughly one to two minutes. Longer answers tend to lose the listener well before you get to the interesting part.
- Don't memorize a script word-for-word. Memorized answers tend to sound flat and fall apart under a follow-up question that breaks the sequence you rehearsed.
Common Mistakes That Undercut a Technical Explanation
- Opening with tools instead of the problem. It forces the listener to guess why any of it matters before you've told them.
- Narrating chronologically instead of structurally. "Then I did this, then this" is hard to follow and buries the outcome.
- Describing only what you built, not what you decided. Steps show effort; decisions show judgment.
- Using the same explanation for every audience. A version built for a peer engineer will lose a recruiter, and a version built for a recruiter will bore a peer engineer.
FAQ: Talking About Technical Projects Professionally
How long should my answer be when someone asks about a project in an interview? Roughly one to two minutes for the full explanation. Long enough to cover Situation, Task, Action, and Result briefly — short enough that you haven't lost the listener before the outcome.
Should I mention things that went wrong in the project? Yes, briefly. A project that went perfectly with no obstacles tends to sound less credible, not more. Naming a real setback and how you handled it usually builds trust rather than undermining it.
What if the person asking isn't technical at all? Strip out tool and framework names unless they ask for them, and stay focused on the problem and the outcome. You can always go deeper if they ask a follow-up — you can't easily recover if you lose them in the first thirty seconds.
Is the STAR method only useful for interviews? No — it works just as well explaining a project to a manager, a client, or a cross-functional team, because the core need is the same: give the listener structure instead of a chronological dump.
Being able to talk about a technical project clearly isn't a soft add-on to real skill for most interviewers and most managers, it is how your skill gets evaluated in the first place. Nobody can see the code you didn't show them. What they can see is whether you understood your own decisions well enough to explain them simply.
Start with one project. Write out the Situation, Task, Action, and Result in a few sentences each. Say it out loud to someone outside your field. If they can follow it, you're no longer just someone who can build things you're someone who can be trusted to explain them, which is most of what "professional" actually means.
