At high salaries, they don't hire based on what you know. They hire based on how you think when you don't know.
This guide is organized by topic in the exact priority order that maximizes salary potential fastest — especially if you already have 5–7 years of experience.
- What 50L Companies Actually Expect
- Frontend System Design
- Performance Engineering
- Browser & Web Platform Internals
- React Internals — Staff Level
- JavaScript Deep Internals
- Architecture for Large Codebases
- Testing Strategy
- Production Engineering Mindset
- Communication Signals Interviewers Watch
- Self-Assessment Checklist
- Realistic Timeline to 50L Readiness
There is a common misconception about what these interviews test. Here is the real picture:
They assume you already know:
React, JavaScript fundamentals, API calls, basic performance, and testing basics. These are table stakes — not differentiators.
They test whether you can:
Design, scale, and own a frontend system used by millions of users across multiple teams with constantly evolving requirements.
The shift in mindset is everything. Stop preparing to write code fast. Start preparing to turn vague requirements into a scalable architecture with tradeoffs.
This is the round most engineers under-prepare for, and the one that most directly unlocks high-salary offers.
You need to be able to walk through the architecture of systems like these with confidence:
- Google Docs UI — collaborative editing, conflict resolution, operational transforms
- Real-time dashboard — WebSocket management, data streaming, chart rendering at scale
- Design system platform — component API design, theming, versioning, accessibility contracts
- Collaborative editor — CRDT vs OT tradeoffs, cursor presence, offline support
- Social feed with 1M users — virtualization, feed ranking, optimistic updates, pagination
- Video streaming UI — adaptive bitrate, buffering strategy, seek optimization, error recovery
For each system, structure your answer across these dimensions:
State architecture — Where does state live? What is server state vs. UI state vs. shared state? How does it flow through the system?
Caching strategy — What is cached, at what layer (CDN, service worker, in-memory), for how long, and how is it invalidated?
Data flow — How does data move from server to UI? Is it REST, GraphQL, WebSocket, SSE? What are the tradeoffs?
Rendering strategy — SSR, CSR, SSG, ISR, or streaming? Why this choice for this system specifically?
Failure & loading states — What happens when an API fails, times out, or returns partial data? Where do error boundaries live?
API contracts — What does the frontend need from the backend? Define the shape of the data, not just "we call an API."
Scalability constraints — What breaks first at 10x traffic? What would you redesign if you knew it would reach 100x?
Not a list of technologies. A structured architecture explanation with explicit tradeoffs — and the ability to defend your choices when pushed.
At the senior/staff level, frontend engineering is performance engineering. You are expected to reason about performance without needing a profiler in hand.
You must understand the exact sequence: HTML parsing → DOM construction → CSSOM construction → Render tree → Layout → Paint → Composite. Know where JavaScript blocks this sequence and how to mitigate it (async, defer, preload, preconnect).
Happens when you interleave DOM reads and writes, forcing the browser to recalculate layout repeatedly in a single frame. The fix is batching reads first, then writes — or using requestAnimationFrame to schedule visual updates.
Reflow vs. Repaint — Reflow recalculates geometry (width, height, position) and is expensive. Repaint updates visual styles (color, background) and is cheaper. Compositing (transform, opacity) happens on the GPU and is cheapest. Design animations to stay on the compositor thread.
The canonical answer to "how do you render 1 million rows smoothly?" — you don't render 1 million rows. You render only the rows visible in the viewport and recycle DOM nodes as the user scrolls. Libraries like react-window implement this. Know the tradeoff: accessibility and keyboard navigation become harder because off-screen rows don't exist in the DOM.
Code splitting — Split at route boundaries using dynamic import(). Users only download code for pages they visit.
Tree shaking — Dead code elimination. Requires ES modules (import/export), not CommonJS (require). Importing from lodash-es instead of lodash enables this.
Bundle analysis — Use Webpack Bundle Analyzer or Vite's rollup visualizer to audit what is in your bundle before it ships. Set performance budgets in CI so regressions are caught before production.
For CPU-intensive tasks (data transformation, CSV parsing, image processing), offload to a Web Worker so the main thread stays free for user interactions. The main thread should only do what only the main thread can do.
"How would you render 1 million rows smoothly?"
Expected answer covers: virtualization, windowing, memoization of row components, debounced scroll handling, and — if pushed — a discussion of when to paginate instead and why.
This is where most candidates fail at high salary bands. Companies at this level expect you to own the platform, not just use it.
You should be able to narrate this end-to-end: DNS resolution → TCP handshake → TLS negotiation → HTTP request → server response → HTML parsing → resource discovery → parallel fetching → DOM + CSSOM construction → render tree → layout → paint → interactive.
Interviewers often ask this to see how deep you go. Most candidates stop at "the browser sends a request." Senior candidates talk about the preload scanner, render-blocking resources, and how <script defer> affects the sequence.
Know the difference between browser cache, service worker cache, CDN cache, and HTTP cache headers (Cache-Control, ETag, Last-Modified). Understand when each layer serves a response and how to invalidate each.
Cookies vs. Storage — Cookies are sent with every HTTP request (relevant for auth); localStorage is synchronous and blocks the main thread; sessionStorage is tab-scoped; IndexedDB is async and suitable for large structured data.
CORS — Cross-Origin Resource Sharing controls which origins can read responses. Know the difference between simple and preflight requests. Know that CORS is a browser enforcement mechanism, not a server security mechanism.
CSP (Content Security Policy) — A response header that restricts which scripts, styles, and resources can execute. The primary defense against XSS. Know how to write a basic policy and why unsafe-inline defeats its purpose.
Candidates who cannot explain the browser rendering pipeline or caching layers are instantly filtered at high salary bands. The platform is your foundation — owning it signals engineering maturity that surface-level React knowledge never can.
Hooks usage is not senior. Internals are.
React's reconciler compares the previous virtual DOM tree to the new one and computes the minimal set of DOM mutations needed. The Fiber architecture (introduced in React 16) reimplements this as a linked list of work units, enabling React to pause, prioritize, and resume rendering work rather than processing it synchronously in one blocking pass.
You must be able to explain why React re-renders a component unexpectedly — and trace it through reconciliation logic. Common causes: referential inequality of objects/arrays passed as props, unstable function references, context value changes, or parent re-renders with no bailout.
React 18's concurrent mode lets React interrupt a low-priority render to handle an urgent update (like user keystrokes). useTransition lets you mark a state update as non-urgent — React will render the current state while preparing the next one in the background. useDeferredValue is similar but for derived values.
Batching — React 18 batches all state updates by default (including those in setTimeout and Promises), reducing render cycles. In React 17 and below, only updates in React event handlers were batched.
Hydration — The process of attaching React's event system to server-rendered HTML. Hydration mismatches (server HTML differs from what React expects) are a common source of subtle bugs.
React Server Components (RSC) — Components that run exclusively on the server, have zero client-side JavaScript cost, and can directly access server resources (databases, file system). The key mental model: RSCs do not hydrate. They stream serialized component trees to the client.
"Why does React re-render this component unexpectedly?"
If you cannot reason through reconciliation, fiber scheduling, and referential equality — you will not pass senior interview loops at top-tier companies.
This is foundational. Companies assume you know the surface; they test whether you know what is underneath.
Event loop — JavaScript is single-threaded. The event loop processes the call stack, then drains the microtask queue (Promises, queueMicrotask), then picks one task from the macrotask queue (setTimeout, setInterval, I/O). This cycle repeats. Microtasks always run before the next macrotask.
Closures & memory behavior — A closure captures variables from its enclosing scope, keeping them alive in memory as long as the closure exists. The common memory leak pattern: closures that retain large objects (DOM nodes, arrays) longer than necessary.
Prototype chain — When you access a property on an object, JavaScript walks up the prototype chain until it finds it or reaches null. Class syntax in JS is syntactic sugar over prototype delegation, not classical inheritance.
Execution context & this binding — this is determined at call time, not at definition time (except for arrow functions, which capture this from their enclosing lexical scope). Know all four binding rules: default, implicit, explicit (call/apply/bind), and new.
You should be able to implement these from scratch and explain their time complexity and edge cases:
| Function | Key Edge Cases |
|---|---|
Promise.all |
Short-circuit on rejection; handle empty array |
debounce |
Leading vs. trailing edge; cancel method |
throttle |
Trailing call guarantee; timer cleanup |
deepClone |
Circular references; Date, RegExp, Map, Set |
curry |
Variable arity; partial application |
bind / call / apply |
new with bound function; this in strict mode |
retry(fn, n) |
Exponential backoff; promise chaining |
| LRU Cache | O(1) get and put using Map + doubly-linked list |
The expectation is not just a working implementation — it is a correct implementation with complexity analysis and a discussion of the tradeoffs and failure cases.
Interviewers use architecture questions to assess engineering maturity — whether you think like someone who has shipped and maintained systems, not just built features.
Organizing by file type (/components, /hooks, /utils) does not scale past a small team. At scale, organize by domain:
src/
features/
billing/
components/
hooks/
api/
types.ts
index.ts ← public interface only
dashboard/
notifications/
shared/
ui/ ← design system primitives
utils/
types/
Each feature owns its internals and exposes only what it needs to via index.ts. Other features import from the public interface, never from internal paths. This creates enforced module boundaries without complex tooling.
Monorepo (Turborepo, Nx) works well when teams share code heavily, want atomic cross-package refactors, and can invest in build tooling. CI scoped to affected packages keeps it fast.
Polyrepo works well when products are truly independent, teams deploy at different cadences, and cross-cutting changes are genuinely rare.
Neither is universally correct — the right answer depends on coupling, team size, and deployment model.
Micro-frontends enable independent deployment per team but add significant complexity: runtime integration, shared dependency versioning, cross-app communication, and inconsistent user experience if design systems are not enforced. They are often the right answer for large organizations with autonomous product teams and are rarely the right answer for startups.
A shared component library should be versioned like a package so consuming teams can adopt changes deliberately. It should encode design tokens (color, spacing, typography) as variables, bake in accessibility at the primitive level, and have a clear contribution model. Without governance, design systems drift into inconsistency faster than they were built.
Senior depth here is not about knowing how to write tests — it is about designing a testing strategy for a system.
Unit tests (many, fast, isolated) → Integration tests (some, verify components working together) → E2E tests (few, slow, test critical user journeys). Most teams invert this pyramid accidentally and end up with slow, brittle test suites.
In a frontend/backend system, contract tests verify that the API shape the frontend expects matches what the backend actually returns. Tools like Pact enable consumer-driven contract testing. This catches integration failures without requiring a full end-to-end environment.
Tools like Chromatic or Percy capture screenshots of components and flag pixel-level regressions. Essential for design system components where visual correctness matters as much as functional correctness.
Mock at the boundary — network calls, not internal functions. Use MSW (Mock Service Worker) to intercept real HTTP requests in tests, giving you realistic behavior without real API calls. Avoid mocking React internals or component internals; test behavior, not implementation.
Flaky tests erode trust in the test suite faster than no tests at all. Common causes: timing dependencies (fix with proper waitFor patterns), shared state between tests (fix with proper teardown), environment variance (fix with deterministic seeds and fixed timestamps). Quarantine flaky tests immediately and treat their resolution as a priority.
The difference between a senior who has shipped production systems and one who has only built features is visible the moment you ask about what happens after deployment.
Error tracking — Sentry captures runtime exceptions with stack traces, release context, and user session data. Upload source maps so production traces point to original source lines. Set up alerts for error rate spikes per release.
Real User Monitoring (RUM) — Measures Core Web Vitals (LCP, FID/INP, CLS) from real user sessions segmented by route, device, and geography. Synthetic benchmarks do not catch real-world regressions.
Session Replay — Tools like LogRocket or FullStory record user interactions to reproduce bugs that are impossible to identify from logs alone. Also invaluable for UX research.
Logging strategy — Log structured events, not unstructured strings. Include correlation IDs so frontend errors can be traced to backend requests.
Feature flags — Decouple deployment from release. Ship code to production before it is user-visible, then enable it for a percentage of users or specific cohorts. Tools like LaunchDarkly or homegrown flag systems enable this.
Canary releases — Roll out a new version to a small percentage of traffic first. Monitor error rates, performance metrics, and business metrics before rolling out fully.
A/B testing — Run controlled experiments where different user groups see different UI variants. Measure impact on business metrics before committing to either variant.
Strong candidates talk about production proactively. They do not just design a system — they describe how they would know if it was working correctly, how they would detect degradation, and how they would roll back safely.
Technical correctness is necessary but not sufficient at this level. Interviewers are also evaluating whether you can operate at a staff level — which requires clear communication and structured thinking.
Structured answers — You organize your response before speaking. You say "I'd approach this in three parts" and then cover all three. You do not ramble.
Justified decisions — You do not just say what you would do; you say why, and you acknowledge the alternative you rejected and why you rejected it.
Explicit tradeoffs — You proactively surface what your proposed solution does not do well. This signals confidence and experience. Engineers who only advocate never acknowledge weaknesses.
Clarifying questions — Before designing a system, you ask about scale, team size, existing infrastructure, and constraints. Jumping to a solution without understanding requirements is a red flag.
Accessibility and inclusion — Strong candidates mention accessibility naturally, not because they were prompted. It signals that they think about the full range of users, not just the median case.
Before answering any design question: pause, structure, clarify. After answering: invite challenge. Say "I made this tradeoff — do you want me to explore the alternative?" This demonstrates collaborative thinking, not defensive attachment to your first answer.
Be honest with yourself. These are the questions that separate candidates who get offers from those who do not.
- [ ] Can I design a scalable frontend system from vague requirements?
- [ ] Can I explain why React re-renders a component, without guessing?
- [ ] Can I optimize a visibly slow UI without opening a profiler?
- [ ] Can I design a state architecture for a system used by 100,000 concurrent users?
- [ ] Can I debug a production performance regression by reasoning from first principles?
- [ ] Can I articulate the tradeoffs between three different architectural approaches?
- [ ] Can I explain the browser rendering pipeline end-to-end?
- [ ] Can I implement
Promise.all,debounce, and an LRU cache from scratch with edge cases? - [ ] Can I describe what my monitoring and rollout strategy would look like for a new feature?
- [ ] Can I explain when not to use a technology I know well?
If you answered No to three or more — those are your gap areas. Do not spread effort evenly; target the gaps.
| Starting Point | Estimated Preparation Time |
|---|---|
| Already a strong senior (system design gaps only) | 2–3 months |
| Mid senior (solid coding, weak design & internals) | 4–6 months |
| Average developer (broad gaps) | 6–9 months |
If you have 6+ years of experience, work in this exact order to maximize leverage:
- Frontend system design — highest ROI, most differentiating
- Performance engineering — tested heavily, under-prepared for by most
- Browser & web platform internals — common filter at top companies
- React internals — expected at staff level, not optional
- Advanced JavaScript — fills in reasoning gaps
- Architecture patterns — supports system design answers
- DSA — medium difficulty is sufficient; this is rarely the deciding factor
The most important insight: senior engineers are not hired because they know more facts. They are hired because they demonstrate a way of thinking — structured, tradeoff-aware, and calibrated to real-world constraints. That thinking is what this guide is trying to build.