5 exercises — choose the best English answer for common full-stack interview questions covering client/server architecture, real-time features, SSR, security, and query optimization.
Answering full-stack interview questions
Show trade-off thinking: "It depends on the situation — on the client for UX, on the server for security"
Name specific tools: "I've used Prisma's include / DataLoader / React Query to solve this"
Use the STAR structure for "walk me through a feature you built" questions (Situation · Task · Action · Result)
Demonstrate security awareness: cookies, HTTPS, input validation, HttpOnly — flag these unprompted
0 / 5 completed
1 / 5
An interviewer asks: "How do you decide what logic goes on the client vs. the server?" Which answer best demonstrates full-stack thinking?
The best full-stack answer shows you understand the trade-off framework, not a blanket rule. Client-side: input validation for UX (instant feedback), UI state (dropdown open/closed, tab selection), optimistic updates (show result before server confirms), data transformations that only affect display. Server-side: all security checks and authorization (never trust client), business rules that involve shared/transactional data, anything requiring database access, operations with side effects (send email, charge card). Key phrase to use: "Critical validation always runs on both — client-side for UX, server-side for security." This shows you understand that client validation is easily bypassed. Related vocabulary: thin client, thick client, BFF (Backend for Frontend), server components (React/Next.js), hydration.
2 / 5
An interviewer says: "Walk me through a feature you built end-to-end." A candidate responds: "I built a real-time notification system. On the backend, I added a Node.js service that listens to database change events and publishes them to a message queue. On the frontend, I used _____ to push updates to the browser without polling." What is the correct technical term for the blank?
WebSockets provide a persistent, full-duplex communication channel between client and server over a single TCP connection. Unlike HTTP (request-response), WebSockets let the server push data to the client at any time — ideal for real-time features: notifications, live chat, collaborative editing, live dashboards. Alternative real-time approaches: Server-Sent Events (SSE) — server-to-client only, simpler, good for live feeds; long-polling — client holds an open HTTP request until the server has data — less efficient. WebSocket lifecycle: handshake (HTTP Upgrade), open connection, exchange frames, close. In interviews, show you know when to use each: WebSockets for bidirectional real-time (chat, gaming), SSE for one-directional streams (live stock prices, notifications), regular polling for infrequent updates.
3 / 5
The interviewer asks: "What is hydration in the context of server-side rendering?" Which answer is correct?
Hydration is how SSR (Server-Side Rendering) frameworks make pages interactive. The server sends fully-rendered HTML (fast first paint, SEO-friendly). Then the browser downloads the JavaScript bundle, React (or another framework) "hydrates" the HTML by attaching event listeners, initializing component state, and taking over rendering — making the page interactive. The HTML is static but looks complete; hydration makes it dynamic. Problems: hydration mismatch (server HTML doesn't match what React would render on the client — causes error or UI flash), hydration time (TTI = Time to Interactive is delayed if the JS bundle is large). Modern solutions: partial hydration (only hydrate interactive islands), streaming SSR (send HTML chunks as they're ready), React Server Components (components that never hydrate — stay server-only). Key vocabulary: SSR, SSG (Static Site Generation), ISR (Incremental Static Regeneration), CSR (Client-Side Rendering).
4 / 5
Complete the candidate's interview answer with the correct term: "To handle the authentication flow, the frontend gets a JWT from the login endpoint and stores it in an _____ cookie — that way JavaScript can't read it, which prevents XSS attacks from stealing the token."
An HttpOnly cookie is a cookie with the HttpOnly flag set — it is sent with HTTP requests but is not accessible to JavaScript (document.cookie cannot read it). This prevents XSS (Cross-Site Scripting) attacks from stealing authentication tokens: even if an attacker injects a script, it cannot read the cookie. The full secure cookie setup for auth tokens: HttpOnly (blocks JavaScript access), Secure (only sent over HTTPS), SameSite=Strict or SameSite=Lax (prevents CSRF by restricting cross-site sending). Compared to localStorage: localStorage is accessible to JavaScript (XSS vulnerable), but cookies with the flags above are not. Common interview question: "Where do you store JWTs?" — correct answer: HttpOnly cookies for browser clients (not localStorage and not sessionStorage for security-sensitive tokens).
5 / 5
An interviewer asks: "What is the N+1 query problem, and how do you fix it?" Which answer is most complete and accurate?
The N+1 query problem: you fetch a list of N items (1 query), then for each item, fetch its related data (N more queries) = N+1 total queries. Example with an ORM: posts = Post.all (1 query) → posts.map(p => p.author) triggers 1 query per post (N queries) = N+1. Solutions: (1) Eager loading (fetch posts AND authors in one JOIN) — e.g. Post.include(:author) in ActiveRecord, include: { author: true } in Prisma; (2) DataLoader (batches and caches per-request — Facebook's solution for GraphQL — collects all IDs, then does 1 query: WHERE id IN (...)); (3) SELECT with JOIN manually. How to detect: enable SQL query logging in development and look for repeated queries with different IDs. Key vocabulary: lazy loading (load on demand — causes N+1), eager loading (load upfront with JOIN — prevents N+1), DataLoader, query batching.