How to answer "Tell me about your project" in a technical interview

"Tell me about your project" sounds simple, but it is one of the most important technical interview questions for experienced candidates. Many candidates answer it like a status update or resume summary. They explain the product, list the tech stack, and mention a few features. That answer does not tell the interviewer much.

The interviewer is trying to understand your technical maturity. They want to know what problem the project solved, what part you owned, what decisions mattered, what trade-offs existed, and whether you can explain the work clearly. They are not waiting for a product pitch. They are waiting for a clear engineering story.

A strong first answer should give enough context without becoming a long story. If the first answer is too broad, the interviewer has to work hard to find your real contribution. That extra work creates a subtle negative impression even when the work itself was good.

The question also opens the rest of the interview. If your answer gives the interviewer clear threads to pull on, the follow-up questions will be natural. If your answer is too vague, the interviewer has to fish for those threads, which can feel uncomfortable for everyone.

Here is a weak answer to this question: "So we were building an e-commerce platform. I worked on the backend. We used Node.js and PostgreSQL. I built some APIs and also worked on the payment integration. The project went well and we shipped it on time."

That answer is not wrong, but it leaves the interviewer with very little to work with. What exactly did you build? Why did you make those choices? What was technically interesting? What did you personally own? What trade-offs did you handle? None of that is visible.

Here is a stronger answer to the same project: "This was an e-commerce platform for a mid-size retail client. I owned the order processing service. The main problem we had was order status updates becoming inconsistent during high traffic periods, because we were using synchronous API calls across services. I moved the order status updates to an async queue-based flow. The trade-off was that status visibility had a small delay, which the client accepted. We also had to build proper retry and dead-letter handling. It reduced the inconsistency issues by about 80% and made the failure cases much easier to debug."

That answer is not longer for the sake of it. It is stronger because it shows the problem, the decision, the trade-off, and the personal contribution. The interviewer now has five good follow-up paths: queues, retry logic, consistency trade-offs, testing approach, and your ownership of the service.

A useful structure is: context, problem, your role, technical decision, trade-off, and result. You do not need to spend equal time on every part. The goal is to make the answer easy to follow and easy to probe.

Context means one or two lines about what the system was and who used it. Problem means the technical or operational issue you were dealing with. Your role means what you specifically owned, not what the team did. Technical decision means one meaningful choice you made. Trade-off means what you accepted or gave up. Result means what changed because of your work, even if the outcome is practical rather than a perfect metric.

Do not treat this as a rigid script. The goal is to give the interviewer a clear view of what you built, why it was built that way, and what you personally contributed to it.

After your first answer, expect follow-up questions. The interviewer may ask why you chose that approach, what else you considered, what failed, how you tested it, or what you would improve now. These are not trick questions. They are how any curious engineer would respond to a story they find interesting.

The easiest way to prepare is to create a small project map. Write down your top two projects. For each one, note the architecture, your role, one difficult problem, one trade-off, one incident or bug, and one learning. This gives you enough material to answer naturally without memorising a script.

Do not prepare a word-for-word script. A script can sound polished but fragile. When the interviewer changes the angle even slightly, a scripted answer breaks. Prepare the thinking instead, so you can adapt. The goal is to understand your project well enough that any question about it has a clear, honest answer.