Full Stack Developer Interview Prep Guide

Plan the full stack before coding. Database: PostgreSQL with users, boards, tasks tables and proper foreign keys. API: REST endpoints for CRUD with JWT authentication middleware. Auth: registration with bcrypt password hashing, login returning access + refresh tokens, protected routes. Frontend: React with TanStack Query for server state, optimistic mutations (update UI immediately, rollback on error). Real-time: WebSocket server broadcasting task changes to connected room members. Discuss your technology choices and why you picked them over alternatives.

Cover the full OAuth 2.0 authorization code flow: 1) Frontend redirects to Google consent screen with client_id and redirect_uri, 2) User grants permission, Google redirects back with authorization code, 3) Backend exchanges code for access + refresh tokens using client_secret, 4) Backend creates or finds user in database, generates a session or JWT, 5) Frontend stores token (httpOnly cookie preferred over localStorage for XSS protection), 6) Subsequent API calls include the token, 7) Backend middleware validates token on every request. Discuss: CSRF protection with SameSite cookies, refresh token rotation, and session invalidation.

This tests full stack thinking. Backend: WebSocket server (Socket.io or native WS) with Redis Pub/Sub for horizontal scaling, PostgreSQL for message persistence with proper indexing on (chat_id, created_at), message delivery states (sent, delivered, read). Frontend: virtual list for message history (only render visible messages), optimistic message sending, connection status indicator, reconnection with exponential backoff. Discuss tradeoffs: polling vs WebSocket vs SSE, when to persist vs ephemeral (typing indicators are ephemeral, messages persist), and how to handle offline messages.

Demonstrate nuanced understanding beyond textbook answers. SSR (getServerSideProps/Server Components) for: SEO-critical pages, personalized content, frequently changing data. CSR for: highly interactive dashboards, authenticated-only content, real-time features. SSG/ISR for: marketing pages, blog posts, product catalogs. Discuss Next.js App Router patterns: React Server Components for data fetching, client components for interactivity, streaming SSR for fast TTFB with Suspense. Give a real example: "Our product pages used ISR with 60-second revalidation because they needed SEO but changed hourly, while the user dashboard was fully CSR because it is behind auth and highly interactive."

Show cross-stack debugging skills: 1) Open browser Network tab to identify slow API calls and check response sizes, 2) Check if caching headers (Cache-Control, ETag) are set correctly, 3) Use backend APM (Datadog, New Relic) to trace slow endpoints, 4) Check database query performance with EXPLAIN ANALYZE, 5) Verify CDN cache hit rates, 6) Check if the frontend is making unnecessary re-fetches or not using stale-while-revalidate. The stale data could be: browser cache not invalidated, CDN serving cached responses, database read replica lag, or TanStack Query staleTime set too high. Show you can reason across all layers.

Discuss three approaches: 1) Shared database, shared schema with tenant_id column (simplest, most common for SaaS, use Row-Level Security in PostgreSQL for enforcement), 2) Shared database, separate schemas per tenant (good isolation, harder migrations), 3) Separate databases per tenant (strongest isolation, highest operational cost). For most startups, recommend approach 1 with RLS. Design the schema: tenants, users (belongs to tenant), projects (belongs to tenant), tasks (belongs to project). Add composite indexes: (tenant_id, created_at) for filtered queries. Discuss connection pooling across tenants.

Show systematic approach: "Users reported that file uploads were failing silently. Frontend showed success, but files were not appearing. I traced the request flow: the frontend was sending multipart/form-data correctly, the API returned 200, but the file was not being saved. Using server logs, I found the upload was going to the correct endpoint but the file size exceeded the Nginx proxy_body_size limit (default 1MB). The backend returned 413 to Nginx, but our error middleware was catching and converting it to 200 with an empty response. Fix: increased Nginx limit to 25MB, added proper error propagation, and added frontend file size validation with a clear error message."

Discuss defense in depth: validate on the frontend for UX (immediate feedback), validate on the API layer for security (never trust client input), and validate at the database layer for integrity (constraints, triggers). Use a shared validation schema library like Zod across frontend and backend when using TypeScript. Cover: type checking, required fields, string length limits, email format, business rules (end date after start date), and sanitization (prevent XSS). Show you understand that frontend validation is for UX, backend validation is for security.