Web Development
Web Development Interview Prep
Senior frontend interviews at companies like Google, Meta, Airbnb, and Stripe consistently test three things: the ability to explain browser fundamentals precisely (event loop, critical rendering path), the ability to design systems at scale (CDN strategy, micro-frontends, SSR tradeoffs), and the ability to reason about tradeoffs without a single correct answer. Memorizing APIs is not the goal - reasoning demonstrably about constraints is.
- Google's frontend interview loop includes a "rendering performance" question where candidates are asked to diagnose a janky animation from a Chrome DevTools flame chart. The expected answer traces from JavaScript execution to style calculation to layout to paint to composite.
- Stripe's engineering interviews include a "system design for a payment UI" question. Candidates who discuss CSP, SRI, iframe isolation for PCI compliance, and the tradeoffs of client-side vs server-side validation demonstrate the security awareness Stripe prioritizes.
- Airbnb's senior frontend process includes a "state management decision" question. The expected answer is not "always use Redux" but a reasoned comparison of Redux vs Zustand vs React Query for a specific scenario, including testing, debugging, and team familiarity tradeoffs.
DOM and Browser Internals
Browser internal questions test whether a candidate understands what actually happens between typing a URL and seeing a rendered page. The critical rendering path: DNS lookup -> TCP handshake -> TLS negotiation -> HTTP request -> HTML parsing -> DOM construction -> CSSOM construction -> Render tree -> Layout -> Paint -> Composite. Each step is an optimization opportunity and a potential bottleneck.
requestAnimationFrame() is the correct API for animations: it runs just before the browser's next paint, inside a single frame. setTimeout(fn, 0) runs in the macrotask queue and can be delayed by other tasks. Using setTimeout for animations causes jank; rAF produces 60fps animations by aligning with the browser's repaint cycle.
What is the order of execution: synchronous code, setTimeout(fn, 0), and Promise.then()?
Async Patterns and Common Traps
Async interview questions test whether a candidate knows how Promises, async/await, and concurrent execution actually work - not just how to use them. Common traps: forgetting await inside a loop (running sequential when parallel is faster), unhandled Promise rejections, and missing error handling in async functions.
Promise.allSettled() vs Promise.all(): all() rejects as soon as any promise rejects (fail-fast). allSettled() waits for all promises and returns results regardless of individual failures - useful when partial success is acceptable (loading multiple optional widgets on a dashboard).
What does Promise.all([p1, p2, p3]) do when p2 rejects?
System Design for Web Applications
System design questions in frontend interviews ask how to architect a large feature or application. A structured answer: clarify requirements and scale (MAU, p99 latency targets), design the data flow (client-side, SSR, or edge), discuss state management, address performance (CDN, lazy loading, streaming), and identify failure modes (what if the API is slow?).
The best system design answers mention failure modes proactively. YouTube's recommendation API is occasionally slow; the frontend should show a skeleton and load recommendations in the background rather than blocking the entire page render. This shows production mindset - not just "how it works when it works" but "how it degrades gracefully."
In a system design interview, what does starting with "clarify requirements" signal to the interviewer?
Articulating Tradeoffs
Senior-level interviews evaluate whether candidates can reason about tradeoffs explicitly. A junior answer: "I would use Redux because it is popular." A senior answer: "Redux adds 40 KB to the bundle and requires action/reducer boilerplate that slows small teams. For this product's team size and audit requirements, the time-travel debugger and strict action log justify the overhead. For a simpler form with five fields, Zustand or React state would be sufficient."
Tradeoff answers should acknowledge what would change the decision. "I would use SSR for this case, but if the team had no Node.js deployment experience and the product had no SEO requirements, CSR with a static host would be the right trade." This demonstrates that the answer is context-dependent, not a tribal preference.
"It depends" is always the right answer to a tradeoff question in an interview
It depends is the starting point, not the answer - the follow-up must specify which factors it depends on, quantify the costs and benefits, and reach a concrete recommendation
"It depends" without specifics signals an inability to reason under ambiguity. The interviewer's job is to evaluate judgment. "It depends on team size, audit requirements, and bundle size budget - in this case I would choose X because of Y" is the actual answer.
What distinguishes a senior-level answer about a technology choice from a junior-level answer?
Summary
- **DOM questions:** the event loop, microtask queue, event bubbling/capturing, critical rendering path, and reflow vs repaint - the browser internals that explain performance anomalies
- **Async questions:** Promise chaining, async/await error handling, concurrent vs sequential execution, and the Web APIs (fetch, setTimeout, Web Workers) that interact with the event loop
- **System design:** CDN strategy, SSR vs CSR vs ISR, micro-frontend architecture, and state management at scale - open-ended questions expecting trade-off reasoning
- **Tradeoffs:** every architectural decision has costs and benefits; senior interviews test whether a candidate can articulate both sides without defaulting to "it depends" without specifics
Related Topics
Interview preparation draws on every previous topic:
- Performance at Scale — CWV, rendering strategies, and CDN tradeoffs are the most common senior frontend system design topics
- State Management — Choosing between Redux, Zustand, React Query, and Signals is a canonical tradeoff question at senior interviews
- TypeScript for the Web — TypeScript generics and utility types appear in live coding rounds - understanding them deeply signals engineering maturity
Вопросы для размышления
- The event loop question (synchronous -> microtask -> macrotask order) is tested in nearly every senior frontend interview. Why is this concept so persistent as an interview benchmark - what does knowing it signal about a candidate's mental model?
- System design interviews for frontend roles are often open-ended ("design the Airbnb search results page"). What is the risk of spending too long on data modeling (backend schema) vs the rendering and state architecture that is the frontend engineer's actual domain?
- Tradeoff questions assume there is a right answer discoverable through reasoning. For genuinely novel problems (a new rendering paradigm, an untested architecture), how should a candidate signal intellectual honesty about uncertainty while still demonstrating analytical ability?