Senior Frontend Interview Guide, Part 18: Frontend System Design and Behavioral Interviews

This article is Part 18 of 18 in The Senior Frontend Engineer Interview Guide, and includes 22 interview questions with model answers.

Senior and lead frontend interviews almost always include a system design round and a behavioral round. The system design round asks you to architect a frontend application or feature end to end, combining everything in this book: React architecture, micro frontends, state and data fetching, APIs, security, accessibility, internationalization, testing, and delivery. The behavioral round explores how you work with people, handle ambiguity, and deliver results. This chapter gives you a repeatable framework for both, with worked examples drawn from enterprise financial applications.

The Frontend System Design Interview

What Interviewers Evaluate

• Requirements gathering: do you clarify scope, users, and constraints before designing?
• Architecture: can you decompose the system into components, data flows, and boundaries?
• Depth: can you go deep on the hard parts (state, performance, real-time updates, security)?
• Trade-offs: do you explain why you chose one option over another?
• Non-functional requirements: accessibility, i18n, security, performance, observability, testing.
• Communication: is your reasoning structured and easy to follow?

A Framework: RADIO-S

A structure that keeps you on track for 45 to 60 minutes:

1. Requirements: functional and non-functional (5 to 8 minutes).
2. Architecture: high-level components and how they communicate (8 to 10 minutes).
3. Data model: client-side entities, state ownership, and caching (5 to 8 minutes).
4. Interface: API contracts between client and server, and component APIs (5 to 8 minutes).
5. Optimizations and deep dives: performance, accessibility, security, i18n, edge cases (10 to 15 minutes).
6. Shipping: testing, deployment, monitoring, and rollout (3 to 5 minutes).

Write as you go: a requirements list, a box diagram, a data model, and API sketches.

Requirements Questions to Ask

• Who are the users (retail customers, business clients, internal operations staff)? What devices?
• What are the core flows for this interview? What is explicitly out of scope?
• Scale: how many users, how much data per user (number of transactions, accounts)?
• Real-time needs: must data update live?
• Offline or poor-network requirements?
• Accessibility and localization requirements (WCAG 2.2 AA, which languages, RTL?).
• Security and compliance constraints (MFA, session timeouts, PCI scope, audit).
• Performance targets (Core Web Vitals, time to show balances).
• Existing constraints: tech stack, micro frontend platform, design system, backend APIs.

Worked Example 1: Online Banking Dashboard

Prompt: “Design the frontend for a retail banking dashboard that shows accounts, balances, recent transactions, and lets users move money.”

Requirements

Functional:

• After login (with MFA), see all accounts with available balances.
• View recent transactions per account with search, filters, and infinite scroll.
• Initiate internal transfers and pay bills; see payment status.
• Notifications for important events (large transaction, payment completed).

Non-functional:

• Web, responsive from 320 px phones to large desktops.
• WCAG 2.2 AA, English and Spanish, prepared for more locales.
• Balances visible within 2.5 seconds on a mid-range phone over 4G (LCP).
• Session idle timeout of 10 minutes with warning; no sensitive data persisted in the browser.
• Multiple teams contribute (accounts, payments, cards); independent releases desired.

Architecture

            +-------------------- CDN (static assets, versioned) -------------------+
            |                                                                        |
Browser --> Shell app (auth, layout, routing, i18n, design system, error boundaries)
            |-- Accounts MFE (dashboard, account details, transactions)   [remote]
            |-- Payments MFE (transfers, bill pay, payees, status)          [remote]
            |-- Profile MFE (settings, security, notifications)             [remote]
            |
            +--> BFF (session cookie <-> OAuth tokens, aggregation, CSRF) --> microservices
                                                                   (accounts, ledger, payments,
                                                                    notifications, IdP)

Decisions and justification:

• Micro frontends with Module Federation because several teams need independent releases; a shell owns cross-cutting concerns. If only one team existed, a modular monolith would be simpler.
• BFF with HttpOnly session cookies so tokens never reach the browser (Chapter 9); the BFF also aggregates calls for the dashboard to avoid a waterfall of requests.
• Client-side rendering for authenticated pages with a fast, cached shell; server rendering adds complexity and offers little SEO benefit behind login. A lightweight server-rendered or static login page can improve first paint.

Data Model and State

Data	Owner	Tool
Session/user profile, locale, permissions	Shell	Context provided to remotes
Accounts and balances	Server	TanStack Query, key ['accounts'], staleTime 30 s, refetch on focus
Transactions	Server	useInfiniteQuery with cursor pagination, key includes filters
Filters, selected account	URL	Query parameters (shareable, back-button friendly)
Transfer draft and wizard step	Client	Zustand store scoped to Payments MFE
Payment status updates	Server push	SSE from BFF, updates query cache

API Interface (BFF)

GET  /bff/dashboard                -> { accounts: [...], alerts: [...], recentActivity: [...] }
GET  /bff/accounts/{id}/transactions?cursor=&q=&from=&to=&type=
     -> { items: [...], nextCursor }
POST /bff/transfers   (Idempotency-Key header)
     -> 201 { id, status: "scheduled" | "processing", deliveryDate }
GET  /bff/transfers/{id}
GET  /bff/events      (text/event-stream: payment.status, balance.updated)

Money as { value: "1520.33", currency: "USD" }, dates in ISO 8601, errors as Problem Details.

Deep Dives

Performance:

• Shell and design system loaded first; the dashboard route’s remote preloaded right after authentication.
• Single aggregated dashboard request from the BFF; skeletons with fixed dimensions to avoid CLS.
• Transaction list virtualized; filters applied in transitions; search debounced.
• Code splitting for heavy, rarely used features (statements PDF viewer, charts).
• Performance budgets in CI; RUM tracking LCP, INP, and custom “balances visible” timing.

Real-time updates: SSE connection after login; on balance.updated, invalidate ['accounts']; on payment.status, update the specific payment in cache. Reconnect with backoff, refetch on reconnect, and fall back to polling.

Security: BFF session cookie (__Host-, Secure, HttpOnly, SameSite=Lax) with CSRF token header; strict CSP with nonces and the CDN origin for remotes; step-up MFA for new payees and large transfers; idle timeout with accessible warning and cross-tab logout; data cleared from query caches on logout; no PII in analytics.

Accessibility: semantic landmarks and headings; accessible data tables with captions; route change focus management; live region announcements for “Transfer scheduled”; contrast-checked tokens; full keyboard support; axe in CI plus manual screen reader testing.

Internationalization: react-i18next with namespaces per MFE; Intl.NumberFormat with account currency and user locale; business dates as plain dates; cutoff times shown with the bank’s time zone; RTL-ready logical CSS.

Error handling: per-remote error boundaries; per-widget error states with retry; global handlers for 401 (session expired dialog) and 503 (maintenance banner); trace IDs shown on error screens for support.

Shipping

Unit and component tests with MSW; contract tests for BFF APIs and MFE events; Playwright end-to-end tests for login, view transactions, and transfer happy path across Chromium, WebKit, and mobile emulation; visual regression of design system components. Each MFE has its own pipeline and deploys versioned assets; the manifest controls which version is live, enabling canaries and instant rollback. Feature flags gate new features. Dashboards track errors and Web Vitals by MFE version.

Worked Example 2: Real-Time Payment Status Tracker for Operations

Prompt: “Design an internal tool where operations staff monitor thousands of payments (ACH, RTP, wires) in real time and act on exceptions.”

Key points to cover:

• Users and scale: 200 operations analysts, tens of thousands of payments per day, hundreds of exceptions.
• Data grid: virtualized grid (AG Grid or TanStack Table with virtualization) with server-side filtering, sorting, and pagination, because the dataset is too large for the client. Column configuration saved per user.
• Real time: WebSocket or SSE stream of status changes; apply updates to visible rows; throttle UI updates (batch per 500 ms) to prevent thrashing; show “new items” indicators rather than reordering rows under the user’s cursor.
• Actions: approve, reject, return, or escalate exceptions, with maker-checker enforced server-side; optimistic locking to prevent two analysts acting on the same payment (409 handling with a clear message).
• Permissions: role-based UI and server enforcement; audit trail visible per payment.
• Keyboard efficiency: shortcuts for common actions, accessible grid navigation (ARIA grid pattern), focus retention after updates.
• Reliability: reconnect logic, stale data indicators (“Live” versus “Reconnecting…”), and a manual refresh.
• Observability: track action latency, error rates, and WebSocket disconnections.

Worked Example 3: Design-System Autocomplete (Component-Level Design)

Prompt: “Design a reusable autocomplete for selecting payees that will be used across many teams.”

Cover:

• API: controlled and uncontrolled (value, defaultValue, onChange), async loadOptions(query, signal), renderOption, getOptionLabel, getOptionKey, minQueryLength, debounceMs, empty and error states, label (required), hint, error.
• Behavior: debounced fetching with cancellation of stale requests; caching recent queries; keyboard navigation per the ARIA combobox pattern (role="combobox", aria-expanded, aria-controls, aria-activedescendant, listbox options with aria-selected); Escape to close; Enter to select; screen reader announcement of the number of results via a live region.
• Performance: virtualize long option lists; memoize option rendering.
• i18n: all strings via props or the i18n system; locale-aware matching (Intl.Collator with base sensitivity for accent-insensitive search); RTL support.
• Theming: tokens and CSS Modules; className merging; container-query responsiveness.
• Testing: RTL tests for keyboard interaction and async results with MSW; axe checks; visual tests; Storybook stories for all states.
• Distribution: published in the design system package with semantic versioning and documentation; built on a headless hook (useCombobox) so teams with special needs can compose their own UI.

Common System Design Topics to Prepare

• News feed or activity feed with infinite scroll and real-time updates.
• Chat or support messaging widget.
• Multi-step onboarding (KYC) with document upload, save and resume, and validation.
• Data-heavy dashboards with charts, filters, and export.
• Collaborative editing (conflict resolution, presence).
• Offline-capable forms with sync.
• Image or document upload with progress and resumable uploads.
• A micro frontend platform: shell, discovery, shared dependencies, governance.
• Rich-text editor or comment system with XSS considerations.
• AI assistant embedded in an application (Chapter 17).

The Behavioral Interview

Behavioral questions assess past behavior as a predictor of future behavior. Answer with the STAR method:

• Situation: brief context (team, project, constraints).
• Task: your specific responsibility.
• Action: what you did, in detail, with reasoning. Use “I” for your actions while crediting the team.
• Result: measurable outcome, what you learned, and what you would do differently.

Prepare eight to ten stories from your experience that can be adapted to many questions: a technical challenge, a conflict, a failure, a leadership moment, a time you influenced without authority, a time you improved a process, a time you dealt with ambiguity, a time you mentored someone, and a time you delivered under pressure.

Sample Story: Performance Improvement

Situation: Our banking dashboard’s INP was poor on Android devices, and customer complaints about sluggish filtering were rising.

Task: As the senior engineer on the accounts team, I owned diagnosing and fixing it within one quarter.

Action: I added RUM instrumentation to segment INP by device and interaction, profiled the transaction filter with the Chrome Performance panel and React Profiler, and found that each keystroke re-rendered a 2,000-row table and recomputed groupings synchronously. I virtualized the table, moved grouping into a memoized selector, wrapped filter updates in startTransition, and added a performance budget test in CI. I paired with a junior engineer on the virtualization work and documented the patterns for other teams.

Result: 75th-percentile INP on Android dropped from 480 ms to 160 ms, complaints about filtering stopped, and two other teams adopted the same approach. I learned to instrument before optimizing; my first guess about the cause was wrong.

Behavioral Interview Questions and Answers

The answers below show the shape of a strong response. Replace the details with your own experience.

Q1. Tell me about yourself.

Give a two-minute narrative: your current role and focus (for example, senior frontend engineer building React micro frontends for a payments platform), two or three achievements relevant to the job (a migration to React 18, an accessibility program, a design system), the technologies from the job description you know well, and why this role is your logical next step. End by connecting to the company’s mission.

Q2. Describe the most technically challenging project you worked on.

Choose a project with real complexity, such as migrating a monolith to Module Federation. Explain the constraints (zero downtime, many teams), the key decisions (async bootstrap, singleton React, manifest-based deployment, shared auth client), the problems encountered (duplicate React copies, CSS collisions), how you solved them, and measurable results such as release frequency and build time.

Q3. Tell me about a time you disagreed with a colleague or manager.

Describe a professional disagreement about a technical approach, for example storing tokens in localStorage versus a BFF. Show that you sought to understand their reasoning, gathered evidence (security guidance, a threat model), proposed options with trade-offs, and reached a decision together or escalated respectfully. Highlight the outcome and the relationship afterward.

Q4. Tell me about a time you failed.

Pick a real failure with consequences, such as a release that broke checkout for Safari users. Take ownership, explain the root cause (insufficient cross-browser testing), what you did immediately (rollback, communication), and the systemic improvements you drove (WebKit in the Playwright matrix, canary releases). Interviewers value learning over perfection.

Q5. How do you handle tight deadlines?

Describe clarifying the must-haves, negotiating scope with product, breaking work into increments that can ship independently behind feature flags, communicating risks early, and protecting quality where it matters most (security, accessibility, money handling) while deferring nice-to-haves with tracked follow-ups.

Q6. How do you ensure quality in your code?

Discuss your practices: small pull requests, tests at the right levels (component tests with MSW, Playwright for critical flows), type safety, linting and accessibility checks in CI, code review focused on behavior and risk, monitoring after release, and blameless reviews when issues escape.

Q7. Describe a time you mentored someone.

Explain how you assessed their needs, set goals, paired on real work, gave specific feedback, gradually increased their ownership, and the result, such as them leading a feature or presenting at a guild meeting.

Q8. How do you stay current with frontend technologies?

Mention concrete habits: following React and web platform release notes, reading specifications or browser blogs, experimenting in side projects, internal guilds or tech talks, and evaluating new tools against real problems before adopting them. Give an example of something you adopted and why (or decided not to).

Q9. Tell me about a time you improved accessibility or security in a product.

Describe how you identified the gap (an audit, a customer complaint, a penetration test), the changes you made (fixing focus management and form errors, adding CSP and removing dangerouslySetInnerHTML), how you made improvements stick (lint rules, CI checks, design system fixes, training), and measurable outcomes.

Q10. How do you work with backend engineers and designers?

Explain collaborating early: API contract reviews using OpenAPI, agreeing on error formats and pagination, mocking with MSW to work in parallel; with designers, reviewing designs for feasibility, accessibility, and edge cases (loading, empty, error, long text, RTL), and using the design system and tokens as a shared language.

Q11. Tell me about a time you dealt with ambiguous requirements.

Describe identifying the ambiguity, asking targeted questions, building a quick prototype or spike to make trade-offs concrete, documenting assumptions, and iterating with stakeholders. Emphasize that you moved forward with a reasonable default rather than waiting.

Q12. Describe a production incident you handled.

Walk through detection (alerts or reports), triage (impact and scope), mitigation (rollback or feature flag), communication (status updates to stakeholders), root cause analysis, and preventive actions. Mention specific tools such as error tracking with release tags and trace IDs.

Q13. Why do you want to work in financial services?

Connect personal motivation (impact on people’s financial lives, interesting technical challenges in security, accessibility, and correctness) with the specific company’s products or mission. Show awareness of the domain: regulation, trust, and the stakes of getting money movement right.

Q14. Where do you see yourself in a few years?

Describe growth that aligns with the role: deepening architecture skills, leading cross-team initiatives such as the micro frontend platform or design system, mentoring, and contributing to engineering standards, while staying hands-on.

Q15. Do you have any questions for us?

Always ask thoughtful questions: How are frontend teams organized, and how do they share the platform? How is the micro frontend architecture governed? What does the release process look like? How do you measure frontend quality and performance? What accessibility standards and testing do you follow? What are the biggest technical challenges in the next year? How do engineers grow here?

System Design Questions and Answers

Q16. How would you start a frontend system design interview?

By clarifying requirements: users, core flows, scale, devices, real-time needs, performance targets, accessibility and localization requirements, security constraints, and existing technology constraints. Then confirm the scope with the interviewer and outline the plan (architecture, data model, APIs, deep dives, shipping) before diving in.

Q17. When would you choose server-side rendering for a banking application?

For public, SEO-relevant, and performance-critical pages such as marketing, product pages, and possibly the login page. For authenticated dashboards, client-side rendering with a fast shell is often sufficient; streaming SSR can still improve perceived performance for content-heavy authenticated pages, at the cost of server infrastructure and complexity. Choose based on measured needs.

Q18. How would you design for offline or poor connectivity?

Cache the app shell with a service worker, keep read-only data available from a cache with clear “last updated” timestamps, queue safe actions for later with idempotency keys, block or warn for actions that require confirmation (payments), detect connectivity with navigator.onLine plus failed requests, and show clear offline indicators.

Q19. How do you decide between polling, SSE, and WebSockets?

Polling is simplest and fine for infrequent updates and small user counts. SSE suits server-to-client streams (status updates, notifications, AI responses) over plain HTTP with automatic reconnection. WebSockets suit high-frequency bidirectional communication (trading, chat). Consider infrastructure support, scaling, authentication, and fallbacks.

Q20. How do you design a large data table feature?

Server-side pagination, sorting, and filtering backed by indexes; cursor pagination for large or changing data; virtualization in the client; URL-synced filter state; column configuration persistence; accessible table or grid semantics; export via asynchronous server jobs for large datasets; and loading and empty states that do not shift layout.

Q21. How do you approach observability for a frontend?

Error tracking with release and micro frontend version tags and source maps; RUM for Core Web Vitals segmented by route and device; custom business timings (time to balances); structured logs for key user actions without PII; distributed tracing with traceparent headers to link frontend and backend; dashboards and alerts tied to release health.

Q22. How would you migrate a legacy AngularJS or jQuery banking app to React?

Use the strangler fig pattern: introduce a shell or reverse proxy that routes new or rewritten sections to React micro frontends while the legacy app serves the rest; share authentication and session; build a design system for visual consistency; migrate highest-value or highest-pain areas first; maintain feature parity tests with Playwright; and retire legacy routes progressively.

Key Takeaways

• Use a consistent structure for system design: requirements, architecture, data, interfaces, deep dives, and shipping.
• Justify every decision with trade-offs and tie it to requirements and team structure.
• Always cover non-functional concerns: performance, accessibility, security, i18n, testing, and observability.
• Prepare STAR stories with measurable results, and ask thoughtful questions at the end.

---

← Part 17: AI Functions in Frontend Applications · All chapters

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Comment *

Name *

Email *

Website

Δ