"Tell me about a project you've worked on" sounds like the easy part of the interview. It is where a surprising number of strong engineers lose rounds, and almost always the same way.
They give an architecture tour. React on the front, Node behind it, Postgres, Redis for caching, deployed on Kubernetes, message queue for the async parts. It's accurate, it's fluent, and after ninety seconds the interviewer knows what the system was made of and nothing about what you did.
The listener needs three things, and the stack isn't one of them: why the thing existed, what was hard about it, and what you decided.
The four beats
| Beat | The question it answers | Length |
|---|---|---|
| The problem | Why did anyone pay for this to exist? | 20s |
| Your part | What was yours, and what wasn't | 15s |
| The hard bit | What made it non-obvious, and what you decided | 90s |
| What happened | The outcome, and what you'd change | 30s |
Two and a half minutes if uninterrupted, and you will be interrupted — usually in the third beat, which is the point. The structure exists to get you to the interesting part fast enough that the interruption lands somewhere useful.
The third beat is the entire answer. The other three are context that makes it legible.
Worked, on an ordinary project
Deliberately not a glamorous one. Most engineers' best story is from unglamorous work.
The problem. "We had a reporting page that took forty seconds to load, and about a third of our customers never used it because of that. It mattered commercially — sales demoed it, and demoing something that takes forty seconds is bad."
Notice: no technology yet. The stakes are in seconds and customers, which anyone in the room can hold onto.
Your part. "I owned it end to end — investigation, the fix, and the rollout. I didn't own the data model it sat on, which turned out to matter."
The hard bit. "The obvious answer was caching, and I spent two days on that before I realised it was wrong. The reports were per-customer, per-date-range, and almost never repeated — so the cache hit rate in staging was about four percent. I'd have shipped a cache that made things slower and harder to reason about.
What was actually happening was that the page ran one query per row to fetch a related record — a few hundred round trips. It was invisible in the code because the relation was loaded lazily three layers down in a template helper.
The decision was whether to fix that one query or change how the model loaded relations generally. Fixing the one query took an afternoon and I knew we'd have the same problem again somewhere else. Changing the loading strategy was a two-week job touching things I didn't own.
I did the afternoon fix, and I wrote down the general problem with three other places I'd found it, and took that to the team that owned the model. That was the right call at the time and I'd make it again — but it did mean the general problem was still there eight months later."
What happened. "Forty seconds to about two. Usage of the page roughly doubled over the next quarter, though I'd be careful attributing all of that to the fix — sales also started demoing it more once it was fast, so the two reinforce each other.
What I'd change: I'd have spent thirty minutes looking at the actual queries before spending two days on the cache. I went to the solution I already knew instead of measuring first."
Three minutes. One hard problem, a wrong turn admitted, a decision with a named cost, and a result with a caveat on it.
The two days wasted on caching is the most valuable part of that answer. It's the part candidates edit out, and it's the part that makes an interviewer believe the rest — because everyone in that room has spent two days on the wrong thing. A project story with no wrong turn in it reads as a story that's been told many times, and polished stories are discounted heavily.
How deep to go
The most common anxiety is pitching the depth wrong. The answer is to let them set it, and to say a sentence that makes it easy for them to.
After the hard-bit beat, a single line: "I can go into how the lazy loading was actually being triggered, or I can move on to what we did about it — which is more useful?"
That does three things. It shows you know there's more depth available. It hands the interviewer control, which they want. And it prevents the two failure modes at once: the candidate who goes six levels deep into a detail nobody asked about, and the candidate who stays so high-level that the story could be anyone's.
If the interviewer is non-technical — a recruiter screen, a founder, a hiring manager from another discipline — the beats don't change but the hard bit does. Replace the mechanism with the shape of the mechanism: "the page was asking the database hundreds of small questions instead of one big one, and that was invisible from the code." No jargon and no loss of substance.
The architecture tour
“It was a React frontend talking to a Node API, Postgres for persistence, Redis for caching, deployed on Kubernetes with a RabbitMQ queue for the async jobs.”
Fluent and empty. It describes a stack that thousands of teams share, contains no decision, and gives the interviewer nothing to ask about except technology choices you probably didn't make.
The problem and the wrong turn
“A page took forty seconds and a third of customers avoided it. I spent two days on a cache before realising the hit rate would be four percent.”
Stakes, then a mistake, then the real cause. The interviewer now has three things they could ask about, and every one of them leads somewhere you know well.
When they interrupt
Interruption is a good sign — it means something landed. The failure is treating it as a derailment and trying to get back to your script.
Answer the question fully, then re-enter with a short bridge: "That's the caching side. Where I'd got to was why the cache was the wrong answer." One sentence, no apology, no recap of what you'd already said.
If the interruption takes the conversation somewhere better than your prepared story, go there. The story was a vehicle for showing how you think; if their question does that more directly, you've lost nothing.
Choosing the project
Three tests, and most people's instinct fails at least one:
- You made a decision in it. Not "I implemented the spec". If the interesting choices were someone else's, pick something else — you'll be asked and the answer will be thin.
- You can name what it cost. Every real project traded something. A story with no trade-off in it is a story that hasn't been examined.
- You remember the details. Under pressure you'll reach for texture, and a project from four years ago that you half-remember will fail exactly when you need it.
Scale doesn't matter nearly as much as candidates assume. A well-examined bug fix beats a vaguely-remembered platform migration.
If English isn't your first language
There's a specific trap here, and it's the opposite of what people expect. The instinct is to reach for technical vocabulary because the technical words are the ones you're most confident in — they're the same in every language. So the explanation becomes dense with nouns and thin on the connective reasoning, which is the part that carries the meaning.
The fix is to deliberately use the simplest available sentence for the mechanism and spend your fluency on the because. "It was asking the database hundreds of small questions instead of one big one" needs no specialised vocabulary at all and communicates more than "we had an N+1 query problem in the ORM layer".
The related habit — slowing down at the exact moment the content gets hard, rather than speeding up — is covered here: speaking pace in technical interviews. And if the project story is part of a take-home follow-up, the shape of that conversation is here: the take-home coding assignment.
Practical target: tell your project story out loud with a rule — you may not name a single technology. No framework, no database, no language. Most people find this impossible on the first attempt, and the second attempt is usually the best version of the story they've ever told, because removing the nouns forces the reasoning to carry it.
