Tell Me About Your Project: Interview Questions and How to Survive Them
Project questions are where interviewers validate the claims on your resume and the level at which you actually operated.
Quick answer
Start with the outcome you need
You want to make project answers specific, credible, and resilient to follow-up questions.
What to remember
An open question with a strict grading rubric
Tell me about a project you worked on invites a monologue, and that is the trap. The interviewer has a mental checklist: is this real, do you understand it beyond your own task, can you defend the decisions, is your contribution accurately scoped.
Nothing about the phrasing tells you that, which is why candidates who improvise here underperform candidates with no more experience who prepared the structure.
Two minutes, then branches
Prepare a two-minute overview and stop. Problem, constraints, what you built, what happened. Then stop talking and let the interviewer choose the direction. Candidates who talk for eight minutes fill time the interviewer wanted for follow-ups, and get scored on the summary alone.
Then prepare branches, because the follow-up will go somewhere specific: architecture, data model, performance, reliability, delivery process, or a failure. Each branch needs two or three minutes of real material.
The branches are the actual preparation. The overview is easy and everybody has one.
Making it verifiably real
Specificity is what distinguishes a real project from a plausible one. Not a large user base but roughly what number. Not it was slow but which operation, at which percentile.
Include something that went wrong, because real projects have friction. A migration that took three attempts, a library that did not do what the documentation claimed, a deadline that forced a compromise. Frictionless projects sound invented.
Include a decision made with incomplete information and what you did to limit the downside. That is what most engineering actually is, and describing it is hard to fake.
Ownership, stated precisely
You will be asked which part was yours. Prepare the sentence in advance: what you decided, what you built, what you reviewed, what someone else owned.
Do not inflate. The follow-ups go wherever you claim, so an overclaim leads directly into territory you cannot defend, which is worse than a modest accurate claim.
If the interesting part of the project was not yours, say so and explain what you did understand about it. Understanding a system you did not build is a legitimate and common engineering situation.
Practice checklist
- 01Time your overview and cut it to two minutes.
- 02Prepare four branches with two to three minutes of material each.
- 03Replace every vague quantity with a number or an honest range.
- 04Include one thing that went wrong and how it was resolved.
- 05Write your ownership sentence before the interview, not during.
- 06Have someone pick a branch at random and push three levels deep.
Questions to practice aloud
Why was this project important at that time?
What was your hardest personal decision?
Which result can you directly attribute to your work?
What did the team learn after launch?
Frequently asked questions
Which project should I choose?+
The one you can defend deepest, not the one that sounds most impressive. A modest project you understand completely outperforms a prestigious one you touched a corner of, because follow-ups find the boundary.
How do I discuss a project under an NDA?+
Describe the problem shape, the constraints, and your reasoning without naming the company, product specifics, or figures. Interviewers accept this readily; what they will not accept is vagueness about your own decisions.
What if the project failed or was cancelled?+
That can be a strong answer. Explain what was attempted, what went wrong, what you saw coming and when, and what you would do differently. Cancelled projects often contain the clearest lessons.