Full Stack Developer Interviews: Complete Request-to-Response Knowledge 2026

This is actually a beautiful journey through multiple systems:

1. DNS Resolution: Browser checks cache, then asks DNS servers to convert the domain to an IP address
2. TCP Connection: Browser establishes a TCP connection with the server (three-way handshake)
3. TLS Handshake: If HTTPS, they negotiate encryption (certificate exchange, key agreement)
4. HTTP Request: Browser sends GET request with headers (cookies, user-agent, etc.)
5. Server Processing: Request hits load balancer → web server → application code → database
6. Response: Server sends back HTML with status code and headers
7. Rendering: Browser parses HTML, builds DOM, fetches CSS/JS, paints pixels

REST (Representational State Transfer):

• Resource-based URLs (/users/123/posts)
• Fixed data structures per endpoint
• HTTP verbs define actions (GET, POST, PUT, DELETE)
• Great for caching, simple to understand

GraphQL:

• Single endpoint, query language for data
• Client specifies exactly what data it needs
• Eliminates over-fetching and under-fetching
• Strong typing with schema

When to choose:

• REST: Simple CRUD apps, public APIs, heavy caching needs, team new to APIs
• GraphQL: Complex data relationships, mobile apps (bandwidth sensitive), rapid frontend iteration

The Virtual DOM is an in-memory representation of the real DOM. Here's why it matters:

The Problem: Direct DOM manipulation is slow. Every change triggers layout recalculation, painting, and compositing.

The Solution:

1. React keeps a lightweight copy of the DOM in JavaScript
2. When state changes, React creates a new Virtual DOM tree
3. It "diffs" the new tree against the old one (reconciliation)
4. Only the actual differences are applied to the real DOM (batched updates)

{`// Without Virtual DOM: 1000 direct DOM updates
// With Virtual DOM: diff → batch → maybe 10 actual DOM updates`}

Important nuance: The Virtual DOM isn't always faster than hand-optimized DOM manipulation. Its value is in making UI updates predictable and easier to reason about while being "fast enough" for most applications.

Use SQL when: Data has clear relationships, you need transactions (banking, inventory), complex queries are common

Use NoSQL when: Schema evolves rapidly, massive scale needed, data is hierarchical/document-like (user profiles, content management)

Real answer: Most production systems use both. User auth in PostgreSQL, session data in Redis, logs in Elasticsearch.

CORS (Cross-Origin Resource Sharing) is a security mechanism that restricts web pages from making requests to a different domain than the one serving the page.

Why it exists: Without CORS, a malicious site could make authenticated requests to your bank's API using your cookies—that's called a CSRF attack.

How it works:

• Browser sends preflight OPTIONS request for non-simple requests
• Server responds with allowed origins, methods, headers
• If allowed, browser sends actual request

{`// Server response headers
Access-Control-Allow-Origin: https://myapp.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Allow-Credentials: true`}

Common mistake: Setting Access-Control-Allow-Origin: * with credentials. Browsers block this for security.

JavaScript is single-threaded but handles async operations through the event loop:

1. Call Stack: Executes synchronous code, one function at a time
2. Web APIs/Node APIs: Handle async operations (setTimeout, fetch, file I/O)
3. Callback Queue: Holds callbacks ready to execute
4. Microtask Queue: Higher priority queue for Promises
5. Event Loop: When stack is empty, moves tasks from queues to stack

{`console.log('1');
setTimeout(() => console.log('2'), 0);
Promise.resolve().then(() => console.log('3'));
console.log('4');
// Output: 1, 4, 3, 2
// Microtasks (Promise) run before macrotasks (setTimeout)`}

Node.js specifics: Uses libuv library with thread pool for file I/O, while network I/O uses OS-level async primitives (epoll, kqueue).

Authentication (AuthN): "Who are you?" - Verifying identity

• Username/password login
• OAuth (Login with Google)
• Biometrics, MFA
• Results in: session token, JWT

Authorization (AuthZ): "What can you do?" - Verifying permissions

• Role-based access control (RBAC)
• Attribute-based access control (ABAC)
• Checking if user can edit this resource

Real-world example: You authenticate to enter a building (show ID), but authorization determines which floors you can access (your keycard permissions).

CSS specificity determines which styles apply when multiple rules target the same element:

{`/* Specificity calculated as (inline, IDs, classes, elements) */
p { }                    /* 0,0,0,1 */
.intro { }               /* 0,0,1,0 */
#header { }              /* 0,1,0,0 */
style="color:red"        /* 1,0,0,0 */
p.intro { }              /* 0,0,1,1 */
#header .nav li { }      /* 0,1,1,1 */`}

Resolution strategies:

• Use consistent methodology (BEM, CSS Modules)
• Avoid !important (creates maintenance nightmares)
• Keep specificity low and flat
• Modern: Use CSS-in-JS or Tailwind to scope styles

Categories:

• 2xx Success: 200 OK, 201 Created, 204 No Content
• 3xx Redirection: 301 Moved Permanently, 302 Found, 304 Not Modified
• 4xx Client Error: 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 422 Unprocessable Entity, 429 Too Many Requests
• 5xx Server Error: 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout

Common confusion:

• 401 vs 403: 401 = not logged in, 403 = logged in but not allowed
• 302 vs 301: 302 = temporary redirect, 301 = permanent (affects SEO)

Use cases:

• Cookies: Authentication tokens, tracking, server-needed data
• localStorage: User preferences, cached data, offline support
• sessionStorage: Form data, temporary state, single-session data

Hooks let you use state and lifecycle features in functional components:

useEffect: Handles side effects (data fetching, subscriptions, DOM manipulation)

{`useEffect(() => {
  // Effect runs after render
  const subscription = api.subscribe(data);

  return () => {
    // Cleanup runs before next effect or unmount
    subscription.unsubscribe();
  };
}, [dependency]); // Only re-run if dependency changes`}

useCallback: Memoizes functions to prevent unnecessary re-renders

{`// Without useCallback: new function on every render
// Child components re-render even if nothing changed
const handleClick = useCallback(() => {
  doSomething(id);
}, [id]); // Function only recreated if id changes`}

Common mistake: Over-using useCallback. Only use it when passing callbacks to optimized child components that rely on reference equality.

JWT (JSON Web Token) flow:

1. User logs in with credentials
2. Server validates, creates JWT (header.payload.signature)
3. Client stores JWT (httpOnly cookie preferred)
4. Client sends JWT with each request
5. Server validates signature, extracts user info

Best practice: Short-lived access tokens (15 min) + refresh tokens in httpOnly cookies

Normalization organizes data to reduce redundancy:

• 1NF: Atomic values, no repeating groups
• 2NF: No partial dependencies (all non-key columns depend on full primary key)
• 3NF: No transitive dependencies (non-key columns don't depend on other non-key columns)

When to denormalize:

• Read-heavy workloads where joins are expensive
• Reporting/analytics databases (data warehouses)
• Caching frequently-accessed aggregations
• When you've proven normalization is the bottleneck (not before!)

Real talk: Start normalized. Denormalize specific queries only when you have performance data proving it's needed.

React's reconciliation (diffing) algorithm compares Virtual DOM trees efficiently:

Key assumptions that make it O(n):

1. Elements of different types produce different trees (rebuild entirely)
2. Keys hint which children are stable across renders

Process:

• Same element type → update attributes, recurse on children
• Different element type → unmount old tree, mount new tree
• Lists → use keys to match children (avoid index as key!)

The problem: Loading a list of items (1 query), then loading related data for each item (N queries)

{`// N+1 Problem: 1 query for posts + N queries for authors
const posts = await Post.findAll(); // 1 query
for (const post of posts) {
  post.author = await User.findById(post.authorId); // N queries
}

// Solution: Eager loading with JOIN
const posts = await Post.findAll({
  include: [{ model: User, as: 'author' }]
}); // 1 query with JOIN (or 2 queries with batching)`}

Solutions:

• Eager loading: Include related data in initial query (JOINs)
• Batch loading: Collect IDs, fetch all at once (DataLoader pattern)
• GraphQL DataLoader: Automatic batching and caching per request

Modern approach (Next.js): Mix strategies per page. Static for marketing, SSR for dynamic, ISR (Incremental Static Regeneration) for best of both.

Common algorithms:

• Token Bucket: Tokens refill at fixed rate, requests consume tokens
• Sliding Window: Count requests in rolling time window
• Fixed Window: Reset count at interval boundaries (can burst at edges)

{`// Redis-based sliding window
async function rateLimit(userId, limit, windowSec) {
  const key = \`ratelimit:\${userId}\`;
  const now = Date.now();

  await redis.zremrangebyscore(key, 0, now - windowSec * 1000);
  const count = await redis.zcard(key);

  if (count >= limit) {
    return { allowed: false, retryAfter: windowSec };
  }

  await redis.zadd(key, now, now);
  await redis.expire(key, windowSec);
  return { allowed: true, remaining: limit - count - 1 };
}`}

Best practices: Return 429 status, include Retry-After header, rate limit by user/IP/API key, use distributed store (Redis) for multi-server

Requirements clarification:

• 100M URLs/month, 10:1 read/write ratio
• Short codes 7 characters (62^7 = 3.5 trillion possibilities)
• Custom aliases optional, analytics tracking

High-level design:

{`Client → Load Balancer → API Servers → Cache (Redis) → Database

POST /shorten: Generate short code, store mapping
GET /:code: Look up URL, 301 redirect

Short code generation:
1. Base62 encode auto-increment ID (simple, predictable)
2. Hash URL + random salt (collision handling needed)
3. Pre-generate codes (best for high throughput)`}

Database schema:

{`urls: short_code (PK), long_url, created_at, expires_at, user_id
analytics: id, short_code, timestamp, ip, user_agent, referer`}

Scaling considerations:

• Cache popular URLs in Redis (80/20 rule)
• Database sharding by short_code hash
• Async analytics writes (Kafka → analytics DB)
• CDN for redirect handling at edge

Systematic approach:

1. Scope the problem: All endpoints or specific ones? All users? When did it start? (Check deployment logs)
2. Check infrastructure: CPU/memory usage, disk I/O, network latency (CloudWatch, Datadog)
3. Database investigation:
   • Slow query log - any new expensive queries?
   • Connection pool exhaustion?
   • Lock contention (SHOW PROCESSLIST)?
4. Application profiling:
   • Add timing logs around suspected code
   • Check for N+1 queries
   • Look for blocking I/O
5. External dependencies: Third-party API latency? DNS issues?

Core challenge: Multiple users editing simultaneously without conflicts

Solutions:

• OT (Operational Transformation): Transform concurrent operations to preserve intent (Google Docs approach)
• CRDT (Conflict-free Replicated Data Types): Data structures that merge automatically (Yjs, Automerge)

Architecture:

{`Clients ←→ WebSocket Server ←→ Document Service
                              ↓
                        Redis Pub/Sub (multi-server sync)
                              ↓
                        PostgreSQL (persistence)

Each edit = operation (insert/delete at position)
Server applies OT/CRDT, broadcasts to all clients
Periodic snapshots for new joiners`}

Key considerations:

• Cursor position sync (show where others are typing)
• Undo/redo per user
• Offline support with sync on reconnect
• Version history and snapshots

Choose monolith when:

• Small team (<10 engineers)
• New product, unclear domain boundaries
• Simple deployment requirements

Choose microservices when:

• Large org with multiple teams
• Clear domain boundaries exist
• Different scaling/availability needs per component
• Team already has microservices expertise

Real talk: Start with a modular monolith. Extract to microservices when you have clear reasons, not because it's trendy.

The challenge: Old code and new code run simultaneously during deployment. Schema changes must work with both.

Expand-Contract pattern:

1. Expand: Add new column/table (nullable or with default)
2. Migrate: Backfill data, update code to write to both old and new
3. Contract: Remove old column/code after all servers updated

{`# Example: Rename column 'name' to 'full_name'

# Step 1: Add new column
ALTER TABLE users ADD COLUMN full_name VARCHAR(255);

# Step 2: Deploy code that writes to BOTH columns
# Step 3: Backfill existing data
UPDATE users SET full_name = name WHERE full_name IS NULL;

# Step 4: Deploy code that only reads from new column
# Step 5: Drop old column (after old servers gone)
ALTER TABLE users DROP COLUMN name;`}

Rules:

• Never rename columns directly
• Never drop columns in same deploy as code change
• Use feature flags for risky migrations