Component Architecture and Code Organization Questions

Focuses on structuring code and components for maintainability, extensibility, and testability. Topics include separation of concerns between structure presentation and logic, component design and reuse patterns, module and file organization, dependency management, state management strategies for complex state, framework specific best practices when applicable, testing strategy and testability, performance and rendering considerations, and evolving designs at senior or staff levels to balance flexibility with simplicity. Candidates should be able to discuss concrete code organization approaches and architectural trade offs for component based systems.

EasyTechnical

57 practiced

Explain atomic design (atoms, molecules, organisms, templates, pages) and describe how you would map these categories to component responsibilities and a practical folder structure in a mid-size React application. What are the main benefits and potential drawbacks of this approach?

HardBehavioral

59 practiced

Tell me about a time you convinced stakeholders to simplify a flexible but complex component API (for example, a mega-form with many optional props). Explain the data, prototypes, or user feedback you used, how you presented trade-offs, and what the result and measurable impact were.

HardTechnical

81 practiced

Architect components and patterns to support server-side rendering and client-side hydration (for Next.js or a custom SSR solution). Explain where to place data fetching, how to avoid double fetching during hydration, caching strategies, and how to ensure components render identically on server and client.

Sample Answer

**Approach summary**Describe a single source-of-truth for data fetched on the server, serialize it into the HTML, and hydrate the client from that serialized state so the client does not re-fetch. Use predictable rendering (no non-deterministic values) and cache at multiple layers (CDN, server, in-memory, client cache).

**Where to place data fetching**- Next.js: perform fetches in getServerSideProps / getStaticProps (or app dir’s server components) so data is available during render.- Custom SSR: fetch in the server render pipeline before rendering React to string, attach results to a props object.- Keep minimal per-page data; load global data via middleware or a top-level layout fetch.

**Avoid double fetching during hydration**- Serialize server data into the HTML (window.__INITIAL_DATA__ or react-query’s dehydrate).- On client, use client-side data hooks that first check for that initial data and consume it, then mark it as used.Example (SWR fallback):

javascript

// server: inject JSON into HTML as __INITIAL_DATA__
/* client: */
import useSWR from 'swr';
const fetcher = url => fetch(url).then(r => r.json());
function Page({ initialData }) {
  const { data } = useSWR('/api/data', fetcher, { fallbackData: initialData });
  ...
}

Or with react-query:

javascript

// server: const dehydratedState = dehydrate(queryClient); inject to HTML
// client: hydrate(queryClient, window.__REACT_QUERY_STATE__);

**Caching strategies**- CDN / edge caching for public pages (cache-control, stale-while-revalidate).- Server-side: in-memory LRU cache or Redis for expensive API calls; tag-based invalidation for updates.- Client-side: use react-query/SWR with TTLs, background revalidation, and deduplication to avoid duplicate requests across components.- HTTP: set ETag/Last-Modified for conditional requests to reduce payload.

**Ensure identical server/client render**- Avoid useEffect/Date.now/random during render; use deterministic utilities or seed values.- Use same serialization formats (e.g., timestamps as ISO strings) and parse consistently.- Ensure CSS-in-JS produces same classnames server and client (same build/runtime).- Hydrate with same React root and matching props; log mismatches during dev.

**Trade-offs / notes**- SSR increases TTFB but improves SEO and first meaningful paint.- Stale-while-revalidate improves UX but means clients see slightly stale data momentarily.- Protect sensitive data: do not serialize secrets to client.

This pattern—server fetch → serialize state → client hydrate using fallback/dehydration + layered caching—prevents double fetches, scales via CDN/edge caches, and ensures isomorphic rendering.

EasyTechnical

63 practiced

What concrete rules or heuristics do you use to decide where to split components and modules into files (for example: one component per file, colocate styles/tests, avoid giant index barrel files)? Provide at least six guidelines that help keep a codebase maintainable and explain why.

EasyTechnical

74 practiced

In TypeScript, define prop interfaces for a generic Button component that supports: variant ('primary'|'secondary'|'link'), size ('sm'|'md'|'lg'), an optional icon (React.ReactNode), disabled, and an onClick handler. Also show how to let the component accept native button attributes (e.g., aria-label, type) without losing type safety.

Sample Answer

**Approach — overview**Extend native button attributes while adding strict custom props. Use Omit to avoid conflicting types for onClick (optional) and keep full type safety for aria-*, type, etc.

**Type definitions and component**

tsx

import React from "react";

type Variant = "primary" | "secondary" | "link";
type Size = "sm" | "md" | "lg";

interface BaseButtonProps {
  variant?: Variant;
  size?: Size;
  icon?: React.ReactNode;
  disabled?: boolean;
  onClick?: React.MouseEventHandler<HTMLButtonElement>;
}

// Merge native attributes but prefer our onClick/disabled signatures
export type ButtonProps = BaseButtonProps &
  Omit<React.ButtonHTMLAttributes<HTMLButtonElement>, keyof BaseButtonProps>;

export const Button: React.FC<ButtonProps> = ({
  variant = "primary",
  size = "md",
  icon,
  children,
  className,
  ...rest
}) => {
  const classes = `btn ${variant} ${size} ${className ?? ""}`.trim();
  return (
    <button className={classes} {...rest}>
      {icon && <span className="btn-icon">{icon}</span>}
      <span>{children}</span>
    </button>
  );
};

**Why this works**- Omit<..., keyof BaseButtonProps> removes native props that would conflict (onClick, disabled), so our signatures win.- All other native attributes (aria-*, type, id, data-*, etc.) remain available and type-checked.- Example usage:

tsx

<Button
  variant="secondary"
  size="sm"
  aria-label="Close"
  type="button"
  onClick={(e) => console.log("clicked")}
>
  Close
</Button>

Unlock Full Question Bank

Get access to hundreds of Component Architecture and Code Organization interview questions and detailed answers.

Join thousands of developers preparing for their dream job.