Project walkthroughs
How to explain your project in an interview.
You explain a project well by walking through it in a clean order — what it was and why it existed, what you personally did, the key decision or hardest problem, and how it turned out — and by rehearsing that walkthrough out loud until it lands. "Walk me through something you built" is one of the most common technical and co-op questions there is, and most people either dump jargon or ramble without reaching the point. Below: what the question really tests, a four-beat structure that keeps the walkthrough tight, the variants you should expect, and how to drill it out loud against an AI interviewer that scores every answer.
What it is
"Walk me through a project you worked on" is a test of how you think, not what you know.
The interviewer already has your resume. The walkthrough is where they find out whether you can explain your own work to another person. They are watching how you frame a problem, what decisions you owned, and whether you can tell the story without them having to dig. This is a structured-interview staple, and the structured interview is the strongest predictor of job performance employers have, at an operational validity of .42 (Sackett, Zhang, Berry & Lievens, 2022). A clear walkthrough reads as clear thinking; a jargon dump reads as someone who did the work but can't account for it.
The question wears a few costumes — "tell me about something you built," "describe a project you're proud of," "what have you shipped recently" — but the ask is the same. Pick one real project and walk the listener through it. The trap is one of two failure modes: burying them in implementation detail before they know what the thing is, or rambling through context and never reaching what you actually did.
How to structure it
Four beats keep the walkthrough complete without letting it sprawl.
A strong walkthrough falls into the same shape almost every time, whether or not the speaker plans it. The order below opens with the point, puts you at the center, spends its weight on the substance, and closes on impact — so the listener always knows what the thing is before they hear how it works.
-
The one-line what and why
Open with a single sentence: what the thing is and the problem it solved. Lead with the point so everything after it has somewhere to land; the stack and the history can wait for later.
-
Your role, in "I"
What you personally owned. Say "I." They're hiring you, not the team. Be precise about the part that was yours.
-
The key decision or hardest problem
One real obstacle or choice, and how you worked through it. This is the substance — spend most of your time here, and show the reasoning behind the fix.
-
The result
What happened. Shipped, measured, learned — with a number where you have one. Close on the impact: what it changed, and what it was worth.
Match the depth to who is across the table. A recruiter wants the one-liner and the result; an engineer wants the decision and the trade-offs you weighed. The same project can be a ninety-second summary or a ten-minute deep dive, and reading which one the interviewer wants is half the skill.
Own your contribution honestly. If it was a team project, say "we" for the group's work and "I" for yours, and be exact about the line between them. Don't inflate your part into sole authorship, and don't hide it behind the group either — either one costs you credibility the moment they probe.
Be ready for the follow-up. Every choice you name is a door the interviewer can open: "why did you choose X over Y?" The walkthrough is the doorway; the real conversation is the follow-up. Have a reason ready for the decisions you mention, so a probe deepens the story instead of stalling it. For the technical version of this back-and-forth, see the technical interview practice guide.
What to expect
The forms the question takes.
The walkthrough shows up in a few predictable shapes. One project you can go deep on, plus a reason behind each choice you made, meets all of them.
"Walk me through a project you worked on."
Pick one you can go deep on rather than the flashiest one you barely touched. Depth you can defend beats scale you can't explain.
"What was your specific role?"
Where they check whether "we" is hiding the fact you did little. Name your part plainly, and draw the line between the team's work and yours.
"What was the hardest problem you hit?"
They want your thinking under difficulty. Pick a genuine obstacle and walk through how you reasoned your way to the fix — the reasoning is the part they're listening for.
"Why did you choose X over Y?"
Every tool and decision you mention is a door. Have the trade-off ready: what you weighed, what you gave up, why it was right for the case.
Problem → Solution
You can plan the perfect walkthrough on paper and still lose the room saying it out loud.
An outline reads clean on the page and then falls apart in the telling: three minutes of setup before the point, the key decision buried, a blank when the follow-up asks "why that approach?" The skill lives in the live walkthrough and the questions after it, not in the plan. Doing the walkthrough out loud is what makes it stick: at a one-week delay, a tested group recalled 56% of material versus 42% for a group that only re-read it (Roediger & Karpicke, 2006), and specific, immediate feedback is what turns a rep into an improvement (Wisniewski, Zierer & Hattie, 2020).
Walk through your project out loud and get scored on where it lands and where it drifts. In Rehearsal Room you give the walkthrough to an AI counterpart that pushes back with the real follow-ups — "what was your part?", "why that choice over the alternative?" — and the forensic debrief afterward grades the shape of it: whether the setup ran long, whether the decision actually came through, whether you closed on a result, and the exact line where the listener lost the thread. You build the walkthrough before the room, so you own it by the time you walk in.
Pick a project, give the walkthrough out loud without notes, and read where it ran over or drifted. Tighten the opening line, sharpen the decision, and run it again with the follow-ups turned up. Reps are what make it hold, and stopping after one good take collapses the gain (Karpicke & Roediger, 2008), so space a few passes across a week until the structure holds without you thinking about it.
Questions & answers
Explaining your project, in plain terms.
How do you explain a project in an interview?
Open with one sentence on what it was and why it existed, say what you personally did in "I," spend most of the answer on the key decision or hardest problem, and close on the result. Keep the setup short so you reach the substance quickly, and match the depth to whether you're talking to a recruiter or an engineer.
How do you answer "walk me through a project you worked on"?
Pick one project you can go deep on rather than the most impressive one you barely touched, and structure it: what and why, your role, the hard part and how you solved it, the result. Have a reason ready for every choice you mention, because the follow-up is where the real conversation happens.
How long should a project walkthrough be?
Aim for about two minutes to open, then let the follow-ups pull the depth. If you're past three minutes before the interviewer has said a word, you've buried the point. The goal is a clear opening that invites questions, not an exhaustive monologue.
What if I worked on the project as part of a team?
Be honest and precise. Say "we" for the group's work and "I" for the part that was yours, and make the line between them clear. Don't inflate your contribution into sole authorship, and don't hide it behind the team — either one falls apart the moment they probe.
What is the best way to practice explaining my project?
Out loud, against follow-ups you didn't script, with feedback on where it ran long or lost the thread. Reading a good walkthrough only teaches you to spot one; giving your own out loud is what builds the skill. Rehearsal Room lets you give the walkthrough to an AI interviewer, fields the follow-ups, and scores the structure in a forensic debrief — built to drill the skill, not to feed you answers.
Rehearse your project walkthrough out loud. Get scored on where it lands.
Walk through what you built against an AI interviewer, field the follow-ups, and get a forensic debrief on where it ran long or lost the thread. Rehearsal, not cheating.
Start practicing →More from Rehearsal Room: co-op interview practice · technical interviews · Git interview questions · all interview guides.