Walk me through your project responsibilities and illustrate the overall architecture with a diagram.
This is the classic 'walk me through a project' opener. The interviewer wants a structured narrative: business context, your role and ownership, system architecture (with a diagram), the key trade-offs you made, the hard problems you hit, and what you would do differently. Treat it as a 5-minute pitch with optional deep-dives. The diagram is the anchor — practice drawing one cleanly.
What the interviewer is actually asking
This prompt looks open-ended but it has a clear shape:
- What was the project? (1 sentence business context)
- What was your role? (scope and ownership)
- What did the system look like? (the diagram)
- What were the hard parts? (technical depth)
- What did you learn / would change? (reflection)
They want to see structured thinking, clear ownership, and the ability to talk at multiple levels of abstraction.
Structure your answer (5 minutes)
1. Set the stage — 30 seconds
"At [company], I led the frontend for [product]. It served ~X users, with [N] engineers. My team owned [scope]; I was [tech lead / principal / IC] specifically responsible for [your slice]."
This anchors scale, your role, and what's yours to talk about.
2. Business problem — 30 seconds
"The core problem was [X]. We needed to [Y] under [constraint Z]."
Constraints are the seed of every interesting design decision. Surface them up front.
3. Architecture diagram — 90 seconds
Draw on the whiteboard or sketch verbally:
┌─────────────┐ ┌──────────────┐ ┌─────────────┐
│ Browser │───▶│ Edge / CDN │───▶│ API GW │
│ Next.js │ │ (Vercel) │ │ (Node) │
└─────────────┘ └──────────────┘ └──────┬──────┘
│
┌───────────────┼───────────────┐
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Postgres │ │ Redis │ │ S3 │
└──────────┘ └──────────┘ └──────────┘Narrate it: "Request hits Vercel edge for static + SSR. Dynamic routes call API gateway. Postgres is the primary store, Redis for sessions and cache, S3 for assets."
4. The hard parts — 90 seconds
Pick 2-3 trade-offs or problems and explain how you decided:
- "Tab data was growing 10x year-over-year, so we moved from in-memory to cursor pagination + virtualization, which dropped TTI from 3s to 800ms."
- "Auth was originally in the gateway, but mobile and web needed different flows, so we moved it to a dedicated identity service."
- "Caching at the CDN was tricky because user content was personalized — solved with stale-while-revalidate + edge functions for the personalization layer."
Numbers + decisions land best.
5. What you'd change — 30 seconds
"In retrospect, we should have [pulled X out earlier / not built Y / picked Z]. The lesson was [...]."
This shows reflection without being self-deprecating.
Diagram principles
- Boxes for systems, arrows for direction of data flow.
- Label arrows with protocol (HTTP, WebSocket, SSE, gRPC).
- Color or group by tier (client / edge / server / data).
- Include scale numbers if you know them.
- Practice this before the interview — drawing a clean diagram on a whiteboard is a skill.
What to AVOID
- Buzzword soup ("we used micro-services, CQRS, event sourcing, DDD..."). Pick what mattered.
- "We" overload — own your part. The interviewer needs to know what YOU did.
- Going off on tangents — keep deep-dives for follow-up questions.
- Missing the business context — engineers love jumping to tech.
- No numbers — "fast", "scalable", "lots of users" tells them nothing.
Anticipate follow-ups
The interviewer will pull one thread to depth. Prepare:
- "Why Postgres over [X]?"
- "How did you handle [auth / caching / state]?"
- "Walk me through a tricky bug you debugged on this system."
- "How did the architecture evolve over time?"
- "What would breaking changes have looked like?"
For each major component, know one war story.
Adapting by seniority
- Mid: emphasize ownership of a specific feature, what you built, decisions you made.
- Senior: emphasize cross-team coordination, trade-offs, mentoring.
- Staff/Principal: emphasize org-level impact, strategy, what you de-prioritized and why.
Mental model
A project walkthrough is a 5-minute pitch with deep-dives on demand. Structure: context → role → diagram → 2-3 hard problems with decisions and numbers → reflection. The diagram is the anchor for everything else. Practice the narrative; don't wing it.
Follow-up questions
- •Walk me through one specific architectural trade-off and your reasoning.
- •What was the hardest bug you debugged on this system?
- •How did the architecture evolve as you scaled?
- •What would you do differently if you started over?
Common mistakes
- •Skipping the business context and jumping into tech.
- •Buzzword-laden architecture descriptions with no concrete decisions.
- •'We' overload — interviewer can't tell what YOU owned.
- •No diagram — purely verbal description loses the audience fast.
- •Going deep on every component instead of letting interviewer pull threads.
Performance considerations
- •Practice the narrative out loud, with a timer. 5 minutes feels short. Have a clean diagram you can draw in under 2 minutes. Memorize the 2-3 most interesting trade-offs.
Edge cases
- •Interviewer interrupts mid-explanation — pivot, don't reset.
- •You worked on a small slice of a huge system — frame your slice clearly.
- •Project was a failure — own it, explain what you learned.
- •Confidential project — describe shape and trade-offs without specifics.
Real-world examples
- •Staff-level interviews almost always open with this question.
- •FAANG L5+ rounds expect a 10-minute deep dive with diagram.
- •Startup interviews often want fewer slides, more raw decisions.