Stop Reciting Project Details in Interviews

Many technical people I've interviewed have solid project experience. The problem is, the way they present it sounds like reciting a laundry list of details.

It's not that their technical skills aren't strong enough; it's that their delivery buries the highlights.

For example, I often hear something like this:

Our system uses Kafka as the message queue, the frontend is React, the backend is written in Java Spring Boot, deployed on AWS, and we use CloudFormation for automation... Our team has four people, and I was responsible for developing two of the modules, involving log analysis, caching strategies...

If you were the interviewer, what would you remember after hearing that?

Honestly, eight out of ten candidates talk in a similar way, piling up technical buzzwords. It sounds like they're reciting a PRD or reading a project README. The result is either information scattered everywhere or no clear focus.

It's not that these details are useless, but:

What you want the other person to remember is your judgment, your contribution, and your problem-solving approach, not how many keywords you can stack.

Why Does Reciting Details Cost You Points?

One core reason is: the rhythm of an interview conversation is different from a technical report at work.

A work report is continuous communication within a team, while an interview is a first impression formed by a stranger in 30 minutes. If you start dumping details right away, the interviewer is like getting into a car without navigation—they have no idea where you're trying to go.

There's also a more subtle issue:

We go into too much detail because we're afraid of not appearing professional enough, afraid of "missing something." But an interview is not an exam; you don't get extra points for covering every technical detail. In fact, it's the opposite—

Saying too much buries the one point you really want them to remember.

So How Should You Present It?

It's not about deliberately simplifying details, but about knowing what level of detail to give at what time.

The following three steps are the structure I often use when presenting projects in interviews:

1. Start with the choice: why this project is worth talking about

Use one sentence to explain the core reason you're presenting this project, for example:

This was the first time I made a key improvement to system stability, ultimately reducing the user error rate from 2.3% to 0.1%, and my boss specifically praised it at the quarterly meeting.

One sentence, without explaining too much background or rushing to throw out technical terms. The interviewer's attention is immediately drawn in: "Oh, this is a project where you made a real impact."

That's how you grab attention.

2. Then talk about the challenge: let people know what difficult problem you solved

Don't jump straight into what features you built; instead, clearly explain the contradiction you faced.

For example:

Our system had a tricky problem at the time: when request volume spiked, the cache hit rate actually dropped, causing backend CPU to surge. Everyone initially thought it was a Redis issue, but after repeatedly reviewing the logs, I found that the real cause was that the cache key granularity was designed too fine, causing hot data to be scattered.

Notice how this kind of presentation brings out your technical perspective.

You're not just someone who codes features; you're someone who can cut through the chaos, identify the root cause, and make a judgment.

That's the judgment and depth interviewers want to see.

3. Finally, talk about the strategy: what you did and what the result was

At this point, when you talk about details, it's not piling up; it's selectively presenting.

Continuing with the example above, you could say:

I ended up designing a two-level cache structure, mapping fine-grained keys to high-frequency hotspot dimensions, and introduced a sliding expiration strategy. As a result, the system's CPU during peak times dropped to 40% of the original. This approach was later reused by other teams.

See, this isn't dry technical detail; it shows the entire chain of your analysis → choice → result.

It's Not That You Can't Explain the Technology; It's That the Highlights Are Buried

When presenting projects, we often fall into the habit of trying to cover everything we've done.

But interviewers don't care about everything you did; they care more about:

Your role in the project
What difficult problems you encountered
How you judged the direction
What results you ultimately delivered

If you can't articulate these clearly, no amount of detail is anything more than background noise.

If you can articulate them clearly, even if you only talk about one thing, the other person will remember you.

It's Not a Formula; It's a Practice Method

Many people hear this and say, "Yeah, that makes sense." But when they get to the actual interview, they revert to detail-reciting mode.

The reason isn't complicated: they haven't practiced distilling, so they're not fluent.

When I practice, I force myself to answer these three questions:

If I could only say one sentence, how would I describe the value of this project?
If this project had failed, what would have been the reason?
If I could only optimize one more thing, what would it be?

Each time is different, and each time it forces me to step out of the details.

Finally, a Contrast: The Most Impressive Presenter Wasn't the Strongest Technically

Once I interviewed a candidate who worked on a fairly common project: optimizing the refund process in a payment system.

But the way she presented it left a deep impression on me.

She didn't start by describing the system architecture; instead, she said:

We process about 20,000 refund requests every day, and 5% of them require manual intervention. Each manual refund takes 5 minutes, which adds up to over 80 hours a day. This project wasn't about adding a feature; it was about saving those 80 hours.

She then talked about how she refactored the processing logic using a state flow, how she validated the rollout for compatibility, and how she worked with the operations team to improve the refund completion rate.

The technology wasn't the flashiest, but she presented the project like a product owner. You could tell right away she had a grasp of the overall business.

We ended up giving her an offer.

Your project experience is a career story you've written yourself. How you tell it—so that others are willing to listen, can understand, and will remember—is the core of expressive power.

Stop being a detail-reciting machine. Telling a story moves people more than showing a pile of architecture diagrams.