Walk me through a frontend architecture you designed and the decisions you made.
This prompt asks for a narrative around your decision-making, not a tech listing. Structure: the problem and constraints, the options you considered, the decisions you made and why, how you got the team aligned, what you measured, and what you learned. The interviewer wants to see judgment, communication, and ownership — not which framework you used.
What the question really tests
Not 'what stack did you use' — that's a 30-second answer. The interviewer wants:
- How you frame problems.
- How you make architectural decisions under constraints.
- How you build alignment in a team.
- How you measure success.
- How you learn from results.
It's a senior-engineer / lead question. Treat it that way.
Structure (5-7 minutes)
1. Context and constraints (1 min)
"At [company], we were [building / rebuilding] [product]. Key constraints:
- Team of N engineers, mixed seniority.
- SLA: [latency target / uptime].
- Existing system: [what we had to work with or replace].
- Timeline: [N weeks/months]."
Constraints are the soil. Without them, every architecture sounds plausible.
2. The decisions I owned (1 min)
"My role was to make decisions on:
- Framework choice.
- Data-fetching model.
- State management approach.
- Build / deploy pipeline.
- Component library / design-system contract.
- Testing strategy."
Be specific about your decisions vs your team's.
3. Walk through one major decision in depth (2 min)
Pick one with real trade-offs. Example:
"For data fetching, we considered three options:
- Client-side fetch in components with SWR.
- Loader-based with Remix / Next App Router.
- Pure REST with manual cache layer.
We picked [2] because [reason] — specifically because our pages had nested data dependencies that were causing waterfalls in option [1]. The downside was [cost], which we mitigated by [...]."
This is the heart of the answer. Show real options, real reasoning, real trade-offs.
4. How I got the team aligned (1 min)
"I wrote a short RFC outlining the options and decisions. We discussed in a design review with the team. I demoed a prototype of the recommended approach. After alignment, I wrote starter templates and ran a workshop. For the first month, I did pair-PR reviews to keep us on the pattern."
Architecture is socialization, not just tech selection.
5. What we measured (1 min)
"We tracked:
- Initial JS bundle (target: <200KB gzipped).
- TTI and INP for the top 5 routes.
- PR merge time (proxy for DX).
- Hot-path error rate.
After 3 months: bundle 180KB, TTI dropped from 3.2s to 1.4s, PR merge time held."
Numbers prove the architecture wasn't just aesthetic.
6. What I'd do differently (1 min)
"In retrospect, we underinvested in [X]. The cost showed up when [Y]. If I were doing it again, I'd [Z]."
Show reflection without self-flagellation.
Decisions to be ready to discuss
- Framework (Next / Remix / Vite SPA / etc.)
- Routing model
- Data fetching (loader / hook / server actions / RSC)
- State management (local / Zustand / Redux / Jotai / TanStack Query)
- Component library / design system
- Styling (CSS Modules / Tailwind / CSS-in-JS / vanilla-extract)
- Testing (Vitest / Jest / Playwright / RTL)
- Build (Vite / Webpack / Turbopack)
- Monorepo or polyrepo
- SSR / SSG / RSC posture
- Auth model
- Feature-flag system
- Telemetry / observability
- Accessibility baseline
- Performance budgets
For each: be ready with the option you picked, the alternatives, and the reasoning.
Showing seniority
- Talk in trade-offs, not absolutes. "We picked X because Y mattered more than Z here."
- Cite constraints, not preferences. "Team was new to React" beats "I like React."
- Show how you de-risked. "We piloted on one route before rolling out."
- Show how you measured. "We set a 200KB budget and enforced it in CI."
- Show how you handled change. "Six months in, we revisited the cache layer because [...]"
Adapting by level
- Senior: own technical decisions for a team.
- Staff: own decisions across teams; influence patterns.
- Principal: shape the org's architecture standards; sponsor multi-quarter initiatives.
Calibrate to the level you're interviewing for.
What to avoid
- Listing the stack without explaining why.
- Talking exclusively in terms of what you used vs why you used it.
- 'We' overload — interviewer can't see your contribution.
- No constraints — every decision sounds equally valid.
- No measurement — architectures are validated by outcomes.
Mental model
This question tests judgment under constraint, not memorization of tools. The framework matters less than how you chose it. Lead with constraints, name the alternatives, justify the trade-off with numbers if you have them, and reflect on what you learned. Senior interviews are about decision quality, not tech taste.
Follow-up questions
- •What was the hardest trade-off you had to make?
- •How did you build consensus when the team disagreed?
- •How did you measure whether the architecture was working?
- •What would you change if you started over?
Common mistakes
- •Listing technologies instead of decisions.
- •Ignoring constraints — every option sounds equally valid.
- •'We' overload — your contribution is invisible.
- •No numbers — 'fast' and 'scalable' don't show judgment.
- •No reflection on what didn't work.
Performance considerations
- •Practice the narrative aloud, timed. Have a clean diagram and 2-3 decisions ready to expand to depth. Rehearse the 'what would you change' answer — it's almost always asked.
Edge cases
- •Decisions made before you joined — own only what you owned.
- •Architecture that was overkill in hindsight — say so.
- •Decisions reversed later — show what you learned.
- •Disagreement with leadership — handle with diplomacy.
Real-world examples
- •Senior+ frontend interviews at FAANG / unicorns lead with this.
- •Architectural decision records (ADRs) are the document form of this answer.
- •Tech lead promo packets are written in this structure.