'Walk Me Through What You Built' — Answering the New 2026 Interview Question

TL;DR: More interviewers in 2026 are asking candidates to walk through a real project they built instead of leading with "tell me about a time." The shift is driven by AI eroding the signal value of take-home tests and rehearsed behavioral stories — a live walkthrough is harder to fake. Prep for it differently than STAR: pick a project you can defend under follow-up, not the one that sounds most impressive in one line.

You spent weeks polishing five STAR stories. Then the interviewer said, "Let's skip that — walk me through something you actually built," pulled up your résumé bullet, and started asking why you made specific decisions inside it. If your prep was all narrative and no depth, that's the moment it falls apart.

This isn't a new phrasing of an old behavioral question. It's a different format, and it's showing up more often for a specific reason.

Why "Tell Me About a Time" Is Losing Ground

Karat surveyed 400 engineering leaders across the US, India, and China for its 2026 hiring-trends report, and the finding behind this shift is blunt: take-home tests and rehearsed behavioral answers are the hiring signals that degrade fastest under AI. Candidates can paste a take-home prompt into a model and get a working solution with zero visibility into how they actually think. A polished STAR story can be written the same way.

A live walkthrough of your own work is harder to outsource in the moment. You either know why you made a decision or you don't, and a follow-up question exposes the difference in seconds. That's why Karat's leaders describe live interviews as "more valuable because they allow interviewers to observe how candidates work through a problem, make decisions, and use AI" — not because live interviews are new, but because everything else got noisier.

The adoption isn't even across markets. Karat's data shows companies in China are nearly twice as likely to allow AI use openly during live interviews (68% vs. 38% in the US) and far less reliant on take-homes (20% vs. 45%) — a sign this shift toward live, observed problem-solving is accelerating fastest where AI-in-the-workflow is already normalized, not treated as something to hide.

You can see the same logic at the practitioner level. Recruiting guides for data-heavy roles now openly recommend cutting the live SQL-puzzle round and replacing it with a longer presentation slot where the candidate walks two interviewers through something they built and takes pushback — because, as one puts it, a model "writes the same query in roughly fourteen seconds" anyway. The puzzle stopped being a useful filter. The walkthrough still is.

What This Question Actually Tests

Generic "how to present your project" advice treats this as a structured monologue: summarize the project, mention an obstacle, wrap with the outcome. That covers maybe a third of what actually happens.

The real test is the follow-up drilling that comes after your opening summary:

• "Why that approach over X?" — tests whether you understood the tradeoff at the time, or just followed a template/tutorial/teammate's lead.
• "What would you change if you rebuilt it today?" — tests whether you've kept thinking about the problem since you shipped it, or consider it closed the moment it worked.
• "What did that actually cost / how did it perform at scale?" — tests whether you know your own numbers, not just the story you tell about them.
• "Walk me through the failure case" — tests whether you understand the edges of what you built, not just the happy path you're narrating.

None of this shows up if you only prep the narrative. It shows up the moment someone interrupts it.

How to Prepare Differently Than for STAR

STAR prep optimizes for a clean five-sentence arc. Walkthrough prep optimizes for surviving interruption. Concretely:

1. Pick the project you can defend, not the one that sounds best. A quiet internal tool you fully understand beats a flashy public project where a teammate made the hard calls and you can't reconstruct their reasoning.
2. Know your numbers cold, not your story. If you mention scale, latency, or a business result, be ready for a follow-up that asks you to justify the number itself — where it came from, what it excluded, what changed it.
3. Rehearse the "why," not just the "what." For every major decision in the project, have one sentence ready on the alternative you didn't take and why. That's almost always the first follow-up.
4. Pre-answer "what would you change now." Come in with one honest limitation of your own work. Volunteering it before you're asked reads as self-awareness; getting cornered into it reads as evasiveness.
5. Practice being interrupted, not just practice talking. Have someone jump in mid-explanation with a pointed question. The skill this format tests is recovering your train of thought under an unexpected pivot, which a solo run-through never trains.

"But My Project Wasn't That Impressive"

This is the most common panic point, and it shows up constantly in candidate forums: engineers whose day-to-day work is low-traffic maintenance, worrying they have nothing scale-y or dramatic to bring to a "project deep dive" round. One recurring thread on r/Blind put it plainly — asked repeatedly about scaling and business impact on a low-visibility internal system, one candidate wondered aloud whether to "spend a couple months carefully making something up with detail" instead of using the real thing.

Don't do that. Interviewers aren't grading the size of your project; they're grading whether your explanation holds up under questions. A small, well-understood project you can defend from every angle outperforms a big one where the first "why" question reveals you were reciting someone else's decisions. If you genuinely didn't design the architecture, say that directly, then talk about what you did own — an extension you built inside it, a tradeoff you personally hit, a bug you traced that taught you how the system actually worked.

The failure mode interviewers are specifically screening for, per real reports from candidates who've been rejected at this stage, is claiming ownership of decisions you can't actually defend once someone asks "what would you do differently now." Owning a smaller, real contribution beats overselling a bigger one you can't back up.

A Simple Structure for the Live Walkthrough

When the format allows it, keep something visual on screen — a diagram, a repo, even a rough sketch — so the interviewer has a concrete thing to point at when they interrupt. Then structure your open like this:

1. One sentence on the problem you were solving and for whom.
2. One sentence on the approach, stated as a decision ("I chose X over Y because...") not a description.
3. Stop talking. Let the interviewer drive the next five minutes with follow-ups. Resist the urge to keep narrating past this point — the walkthrough format is designed for them to steer, and over-talking here just delays the part that's actually being scored.

The hardest part of this format isn't knowing your project. It's staying composed when a follow-up lands on a detail you weren't expecting to defend, live, with no chance to edit your answer first. That's genuinely difficult to simulate alone — it's the exact moment real-time interview assistance is built for, quietly surfacing your own project's numbers, timeline, or the tradeoff you're being asked to justify while you're mid-answer, so a sharp follow-up doesn't blank you out.

If you're building STAR stories for the rest of your loop alongside this, our STAR method guide covers that half, and our software engineer behavioral interview guide is worth pairing with this one since most 2026 loops still run both formats back to back.

FAQ

Is this replacing behavioral interviews completely, or just adding to them?

Adding to them, mostly. Karat's 2026 survey of engineering leaders found live problem-solving and work-sample discussion now rank above take-homes and canned behavioral answers as trusted signals, but few companies have dropped STAR-style questions outright. The realistic prep target is a loop that includes both, with the walkthrough round carrying more weight than it used to.

What if the project I'd want to talk about was mostly maintenance, not something impressive I built from scratch?

Pick the project where you can answer follow-ups, not the project that sounds best in one sentence. A boring maintenance project you understand cold beats a flashy one where you'll freeze on "why did you choose that approach." Interviewers are listening for how you think under a specific detail, not for the size of the codebase.

What do I do if I didn't design the architecture myself, or I'm not sure I could explain what I'd change now?

Say what you actually owned, honestly. If you inherited the design, say so, then talk about the parts you did decide: how you extended it, a tradeoff you hit while working inside it, or a change you'd make if you had time now. Claiming ownership you didn't have is the failure mode this question is built to catch, and it's usually obvious the moment a follow-up lands on a decision you can't defend.

How is this different from just rehearsing my project for a portfolio review?

A portfolio review is largely one-directional: you present, they listen, maybe a question or two at the end. A work-sample walkthrough is adversarial by design — interviewers jump in mid-explanation with "why not X instead," "what would that cost at 10x scale," or "what did the data actually say." Rehearsing a smooth narration doesn't prepare you for being interrupted; rehearsing your reasoning does.

Should I bring a real demo or slides, or just talk through it verbally?

Bring something to point at if the format allows it — a diagram, a repo, a screenshot, even a napkin sketch works over video. It's not about production polish; it's about giving the interviewer a concrete thing to ask follow-ups against, which is exactly what this format is testing for. A purely verbal description makes it easier to gloss over details you'd rather not defend.

---

Author · Alex Chen. Career consultant and former tech recruiter. Spent 5 years on the hiring side before switching to help candidates instead. Writes about real interview dynamics, not textbook advice.