Frontend System Design Interview Approach

Interview Question: "Design a [Twitter feed / Google Docs / Figma / Spotify]. You have 45 minutes."

The 8-Step Framework

"I approach every frontend system design with the same framework. It keeps me structured, ensures I don't miss critical areas, and shows the interviewer I can think architecturally."

Step 1: Requirements Clarification (3-5 min)

"Before drawing anything, I clarify functional and non-functional requirements. This is where most candidates fail — they jump straight into components."

Functional Requirements (what it does):

• Core user flows
• What data is displayed, created, updated
• Real-time vs eventual consistency needs

Non-Functional Requirements (how well it does it):

• Performance targets (TTI, LCP)
• Offline support needed?
• Scale — how many concurrent users / items
• Accessibility requirements
• Internationalization
• SEO requirements

Step 2: High-Level Architecture (5 min)

┌─────────────────────────────────────────┐
│              Client Layer               │
│  ┌──────┐  ┌──────────┐  ┌──────────┐  │
│  │ View │  │  State   │  │ Network  │  │
│  │Layer │◄─┤ Manager  │◄─┤  Layer   │  │
│  └──────┘  └──────────┘  └──────────┘  │
│                               │         │
└───────────────────────────────┼─────────┘
                                │
                    ┌───────────▼──────────┐
                    │    API Gateway /     │
                    │    BFF Layer         │
                    └─────────────────────┘

"I sketch the major boundaries first: view layer, state management, network layer, and how they connect to the backend. This gives us a skeleton to fill in."

Step 3: Data Model (5 min)

interface Tweet {
  id: string;
  authorId: string;
  content: string;
  media: MediaAttachment[];
  createdAt: number;
  metrics: { likes: number; retweets: number; replies: number };
}
 
interface Feed {
  tweets: Tweet[];
  cursor: string | null;
  hasMore: boolean;
}
 
interface User {
  id: string;
  handle: string;
  displayName: string;
  avatarUrl: string;
}

"Defining the data model early forces clarity about what we're rendering and what the state shape looks like."

Step 4: API Design (5 min)

// REST approach
GET  /api/feed?cursor={cursor}&limit=20
POST /api/tweets
POST /api/tweets/:id/like
 
// Real-time updates via WebSocket or SSE
WS   /ws/feed -> { type: 'NEW_TWEET', tweet: Tweet }

"I think about the API contract — pagination strategy (cursor-based for infinite scroll), optimistic updates for interactions, and whether we need real-time push."

Step 5: Component Architecture (5-7 min)

<App>
  <Header />
  <FeedContainer>             ← data fetching boundary
    <VirtualList>             ← only renders visible items
      <TweetCard>
        <TweetAuthor />
        <TweetContent />
        <TweetMedia />        ← lazy loaded
        <TweetActions />      ← like, retweet, reply
      </TweetCard>
    </VirtualList>
    <LoadingSpinner />
  </FeedContainer>
  <ComposeButton />
  <ComposeModal />            ← portal, focus trapped
</App>

"I organize components by responsibility: container components handle data, presentational components handle rendering. I call out key patterns like virtualization and lazy loading at this stage."

Step 6: Performance (5-7 min)

"Performance is where senior answers diverge from mid-level."

Rendering Performance:

• Virtual scrolling for the feed (only render ~20 items, not 10,000)
• Image lazy loading with loading="lazy" and srcset
• Skeleton screens instead of spinners

Network Performance:

• Cursor-based pagination (fetch 20 at a time)
• Optimistic updates for likes/retweets (instant feedback)
• Service Worker for offline reading
• Stale-while-revalidate caching strategy

Bundle Performance:

• Code-split the compose modal (only loaded when needed)
• Dynamic import for rich text editor
• Route-based code splitting

Step 7: Accessibility (3 min)

• Feed is an ARIA feed role with aria-busy during loading
• Tweet cards are article elements
• Like/retweet buttons have aria-pressed state
• Keyboard navigation: arrow keys between tweets, Enter to expand
• Focus management when compose modal opens/closes
• Live region announces "New tweets available" for real-time updates

Step 8: Error Handling & Edge Cases (3 min)

• Failed tweet post → retry with exponential backoff, keep draft in state
• Network offline → queue actions, sync when back online
• Rate limiting → show user-friendly message
• Empty states — new user with no feed, search with no results
• Infinite scroll edge case — what happens at end of feed

Time Management

What Separates Senior from Architect Answers

What Interviewers Look For

• Structure over perfection — having a framework matters more than getting every detail right
• Trade-off awareness — "I'd choose X because Y, accepting the downside of Z"
• Depth on demand — ability to go deep when probed on any section
• Non-functional requirements — performance, a11y, error handling aren't afterthoughts
• Communication — thinking out loud, asking clarifying questions, managing time

Common Mistakes

• Jumping into code or components without understanding requirements
• Ignoring non-functional requirements (performance, a11y, offline)
• Spending 30 minutes on component hierarchy with no time for performance
• Saying "I'd use a library for that" without explaining the underlying concept
• Not discussing trade-offs — every decision has a cost
• Designing for the happy path only — no error handling or edge cases

Red Flags

• No mention of pagination strategy for large lists
• No discussion of state management approach
• Treating accessibility as optional
• No awareness of real-time update strategies
• Cannot articulate why one approach is better than another