Home / Blog / How to answer "tell me about this project" (the 30-second method)

How to answer "tell me about this project" (the 30-second method)

PrepHike · 5 min read

"Tell me about this project" is the question most engineers answer worst. They ramble for four minutes, list technologies, and never say what they actually did. This guide gives you a two-layer structure: a tight 30-second spoken answer, then a deep dive the interviewer pulls out of you on purpose.

Why this question decides the interview

"Tell me about a project you worked on" sounds like small talk. It is not. It is the moment the interviewer decides how senior you really are. Your answer tells them whether you understand systems or just close tickets, whether you make decisions or follow them, and whether the work on your resume is yours or your team's.

Most engineers in the 2 to 6 year range lose points here for the same reason. They know their project cold, so they assume the interviewer does too. They start in the middle, drown the listener in detail, and run out of breath before they say anything that matters. The fix is not more detail. It is structure, and a clear split between what you say first and what you say when asked.

The two-layer model

Every strong project answer has two layers. Layer one is a 30-second spoken summary you deliver unprompted. Layer two is a technical deep dive you reveal in pieces as the interviewer probes. Do not collapse them into one monologue. The interviewer wants to steer. Give them a clean handle to grab.

This is the same structure we build inside the Hone phase of our SHIFT method, and in practice it is where most of the consulting time goes, because this is where interviews are actually won or lost.

Layer one: the 30-second answer

Thirty seconds is roughly 75 words spoken at a calm pace. It has four parts:

• Context (one line): what the system does and who uses it. "It is the payments reconciliation service for a B2B lending platform, about 40,000 transactions a day."
• Your role (one line): what you specifically owned. Say "I" not "we." "I owned the reconciliation engine end to end, from design to production."
• The hard part (one line): the technical challenge that made it interesting. "The hard part was matching bank statements to our ledger when the bank file format changed without notice."
• The outcome (one line): a number if you have one. "Manual reconciliation dropped from six hours a day to about twenty minutes, and mismatches fell by 90 percent."

That is the whole opener. It is specific, it is short, and it hands the interviewer three or four threads to pull: the matching logic, the format problem, the ledger design, the measurement. They will pick one. Now you go deep.

Layer two: the technical deep dive

The deep dive is not a second monologue. It is a set of prepared answers to the questions you know are coming. Prepare four areas:

• Architecture. Be able to draw or describe the components and how data flows between them in under a minute. Name the datastore, the queue, the services, and why each one is there. If you cannot explain why a component exists, the interviewer assumes you inherited it without understanding it.
• Key decisions. Pick two or three real decisions you made and the reasoning. "We chose Postgres over MongoDB because reconciliation needs strong consistency and we query across relations constantly." A decision with a reason behind it is the single clearest signal of seniority.
• Trade-offs. Every decision cost you something. Name it. "Batch processing was simpler to build and easier to audit, but it added up to fifteen minutes of latency. For reconciliation that was acceptable. For a live payment path it would not have been." Engineers who only list upsides sound junior. Engineers who name the cost sound like they have shipped.
• What you would change. Have one honest answer ready. "If I rebuilt it I would move from a nightly batch to event-driven, because the business now needs near real-time visibility." This shows you still think about the system after shipping it.

Showing ownership without inflating

Ownership is the hardest thing to fake and the easiest to undersell. Two rules keep you honest and credible at the same time.

First, separate "I" from "we" deliberately. Use "we" for the team's scope and "I" for your contribution. "The team rebuilt the checkout flow. I owned the inventory locking logic and the retry mechanism." This is more believable than claiming the whole thing, and it tells the interviewer exactly where to test you.

Second, never claim a number you cannot defend. If you say latency dropped 40 percent, expect "how did you measure that?" If your answer is "I think it felt faster," you have just lost more credibility than the number ever earned you. Only use metrics you watched move on a dashboard or a report. An honest "we did not measure it formally, but support tickets about timeouts stopped coming in" beats a confident fake. This same discipline runs through how we coach STAR stories that do not sound rehearsed: real detail, defendable claims, nothing invented.

A worked example, start to finish

Interviewer: "Tell me about a project you are proud of."

"Sure. It is the notifications platform at my current company, an ed-tech product with about two million users. I owned the delivery service, which decides which channel a message goes out on, email, SMS, or push, and handles retries. The hard part was that during exam-result days, traffic spiked to roughly 50 times normal in a two-hour window. I redesigned it from synchronous sends to a queue-based system with priority lanes. On the last result day we delivered 8 million notifications with no dropped messages, where the year before we had crashed."

That is 95 words, about 35 seconds. Notice it ends on a thread the interviewer will almost certainly pull: priority lanes, the queue choice, what "crashed" meant before. When they ask "why priority lanes?", you go into the decision and the trade-off. You are no longer presenting. You are in a conversation, which is exactly where you want to be.

How to prepare this for your own projects

Pick your two strongest projects. For each, write the 30-second answer in four lines, then write down the five questions an interviewer would most likely ask and your real answer to each. Say them out loud and time the opener. If it runs past 40 seconds, cut it. The goal is not to memorize a script. It is to know the shape so well that you can adapt it to whatever angle the interviewer takes.

This works best when the underlying material is solid, which is why we start by surfacing your real work and numbers in the market-value audit most engineers skip. Get the facts straight first, then build the story on top. A clear project answer, backed by honest numbers, is often the difference between a lateral move and a real jump.