The Architecture Interview: What Senior Frontend Engineers Actually Know
I've been on both sides of the frontend architecture interview. The questions that actually reveal seniority aren't about syntax or API surface — they're about trade-offs, failure modes, and the ability to reason under constraints.
What Most Candidates Get Right
Most senior candidates can explain component composition, hooks, and basic performance patterns. They know what memoization does, can describe the virtual DOM, and have a mental model of how state flows through a React application. This is table stakes.
The Questions That Actually Differentiate
The questions that reveal genuine seniority involve architectural trade-offs with real constraints. "When would you not use React Query?" is more revealing than "What is React Query?" because it forces the candidate to articulate failure modes, not just features.
- Given a team of 8 engineers and a codebase with 400+ components, how would you enforce consistent data-fetching patterns without a linting rule?
- Your app has 40% of users on 3G in Southeast Asia. What architectural decisions change because of this constraint?
- You've just taken over a codebase where every component fetches its own data. What's your phased migration path?
State Colocation: A Reliable Signal
How a candidate thinks about state colocation reveals a lot about their mental model of React. The principle is simple — state should live as close as possible to where it's consumed. The execution is where judgment matters.
The right question is not "where does this state belong?" but "what is the lifetime and ownership of this data?" State owned by one user action should never outlive that action.
Practical Preparation
If you're preparing for a senior frontend role, practice explaining architectural decisions you've made — including the ones that turned out to be wrong. The ability to articulate what you'd do differently, and why, is a strong positive signal in any architecture interview.