The fastest way to answer "tell me about a project you worked on" is to name the project in one sentence, state the hardest technical decision you owned, and end with a number that shows impact. Everything else is detail you add on request. Most engineers do the opposite: they narrate the whole project chronologically, spend three minutes on setup, and never reach the part the interviewer is actually scoring. This guide gives you a structure that front-loads signal, plus the follow-up questions to prepare for.
This is different from a pure behavioral answer. When we run mock interviews, the project discussion is where strong resumes fall apart, not because the work was weak, but because the candidate can't isolate their own contribution or explain why they chose approach A over approach B. If you want the behavioral-storytelling mechanics, our STAR method guide for engineers covers those separately. Here we focus on the technical project deep dive.
What the project deep dive actually tests
The "project deep dive" is now a standard round at many companies, sometimes replacing a coding screen entirely. Formats vary, but the evaluation target is consistent. Interviewers evaluate the same thing: ownership, architectural judgment, and depth of understanding. These rounds typically run 30 to 60 minutes. Some companies build their whole loop around it. At Ashby, for example, the process is explicit that there are no leetcode or whiteboard exercises, and the interview dives into past projects and simulates working together through pair programming and discussing decisions.
The level you're interviewing for changes what a "good" project looks like. The big difference between project deep dive interviews for senior versus staff is the scope of the project, its complexity, the impact it had, and the skills it took to drive the project to successful completion. A mid-level answer can be a single service you built well. A staff answer needs cross-team scope and a decision that others deferred to you on.
So before you pick a project, ask: does this let me demonstrate ownership, a real trade-off, and impact? If it only shows one of the three, pick a different project or reframe.
Pick the right project (and have a backup)
Choose two projects you can discuss for 20 minutes without notes. Not the most impressive on paper: the one where you personally made the hard calls. Criteria we tell candidates to use:
- You owned a real decision. If the answer to "why did you build it this way?" is "that's how the team already did it," it's a weak choice.
- There was a genuine trade-off. Latency versus cost, consistency versus availability, ship-fast versus refactor. If everything went smoothly, there's nothing to probe, and interviewers read that as shallow.
- You can quantify impact. Requests per second, p99 latency, dollars saved, hours of manual work removed, error rate reduction. Vague impact ("it improved performance") gets discounted.
- You can go three questions deep. Interviewers drill down. If your knowledge runs out after the summary, it looks like you rode along rather than led.
Have a backup ready for a different signal. If your main project shows system design breadth, keep a second one that shows debugging depth or a nasty production incident.
A structure that front-loads signal
Use this order. It works whether the prompt is "walk me through a project" or "what are you most proud of."
- One-line context (15 seconds). What the system does and who uses it. "A payments reconciliation service that matched 4 million daily transactions across three providers."
- Your role and the problem (30 seconds). What was broken or missing, and what you specifically owned.
- The key decision and the alternatives (2 minutes). This is the core. State the option you chose, the ones you rejected, and why. Name the constraint that drove it.
- Impact with a number (30 seconds). The measurable result and how you know.
- What you'd do differently. One honest reflection. This signals seniority more than any success story.
Notice that the technical decision gets the most time. That is deliberate. Interviewers are listening for how you reason under constraints, not for a feature list.
Here is the difference in practice:
Weak: "I built the notification system. It used a queue and
workers. It scaled well and users liked it."
Strong: "Notifications were dropping under load at 10k/min.
I chose a pull-based worker model over push because
our providers rate-limited us and push caused
retries to stampede. Trade-off: slightly higher
latency (200ms) for zero dropped events. Drop rate
went from 3% to under 0.01%. If I redid it, I'd add
per-provider backpressure earlier."
The strong version is shorter and says more. Every sentence carries a decision, a constraint, or a number.
Prepare for the follow-ups (this is where rounds are won)
The deep dive is really a tree of follow-ups. Your opening answer is just the root. Expect the interviewer to pick one branch and push until you hit your limit. Prepare answers to these for each project:
| Follow-up | What they're checking |
|---|---|
| "Why not use X instead?" | You considered alternatives, not just the first idea |
| "What broke in production?" | You've operated the system, not just built it |
| "How would this scale 10x?" | You know the bottlenecks in your own design |
| "What would you change now?" | Self-awareness and growth |
| "Who disagreed with you and what happened?" | Collaboration and influence |
The scaling question overlaps heavily with system design fundamentals, so the same reasoning you practice for back-of-the-envelope estimation applies here. If you can estimate where your system tips over (connections, memory, write throughput), you turn a project story into a design discussion, which is exactly the signal senior interviewers want.
One rule: never bluff at the edge of your knowledge. Saying "I didn't own that part, but here's what I understood about it" scores better than a confident wrong answer. Interviewers probe specifically to find where confidence outruns understanding.
Common mistakes we see every week
- Chronological narration. Starting at "so first we had a planning meeting." Cut straight to the problem and decision.
- "We" with no "I." If we can't tell what you did versus the team, we can't score you. Say "I designed the schema; a teammate built the ingestion."
- No numbers. "It was faster" is not impact. Even a rough, honest estimate ("roughly halved our batch time, from about 40 to 20 minutes") beats nothing.
- Over-selling a smooth project. No trade-offs means no depth to explore. Pick the messy one.
- Memorizing a script. A rigid monologue collapses on the first follow-up. Internalize the structure, not the sentences.
The connective tissue between projects and the algorithmic rounds is the same skill: explaining your reasoning out loud as you go. A candidate who can narrate why they chose a hash map over sorting on a problem like Find Duplicate Subtrees, or why they reached for DP on Domino and Tromino Tiling, is using the exact muscle the project deep dive tests. If your project explanations feel rusty, practicing think-aloud on coding problems sharpens both.
FAQ
How long should my initial project answer be?
Aim for 90 seconds to 2 minutes before pausing for questions. Cover context, your role, the key decision, and one impact number, then stop and let the interviewer steer. A 5-minute uninterrupted monologue is a red flag; it suggests you can't prioritize what matters.
What if my best project was a team effort?
Talk about the team's goal briefly, then isolate your contribution explicitly. Use "I" for your decisions and "we" for shared context. Interviewers expect collaboration; what they can't score is a story where your individual judgment never appears.
Can I talk about a personal or side project?
Yes, especially early-career. It should still show a real decision and a trade-off, not just "I followed a tutorial." A side project where you chose a database and can defend why, or handled a performance problem, works well. For senior roles, favor production work with real users and scale.
What if the interviewer asks about a technology I only used briefly?
Be honest about your depth: "I integrated with it but didn't own the internals." Then offer what you do know. Interviewers respect a clean boundary far more than a confident guess that unravels under one more question.
Should I prepare projects differently for a startup versus a big company?
Somewhat. Startups often weight end-to-end ownership and shipping speed, so emphasize what you built alone and how fast. Larger companies weight scope, cross-team influence, and operating at scale, so emphasize the hard decision and the measurable impact. Same structure, different emphasis.