Backend engineer role-specific interview questions

As asked

Walk me through the Node.js event loop phases in the order they execute. What happens in each phase, and where do setImmediate, setTimeout, and process.nextTick fit in?

Sample answer outline

A strong answer names all six phases in order: timers, pending callbacks, idle/prepare, poll, check, close callbacks. The timers phase is the first phase of each loop iteration and runs callbacks for setTimeout and setInterval whose delay has elapsed. The poll phase comes later: it retrieves and processes I/O events, and will block waiting for I/O if no timers are pending. setImmediate runs in the check phase, which comes immediately after poll. Because check follows poll in the same iteration, setImmediate fires before a setTimeout(fn, 0) when both are scheduled inside an I/O callback. process.nextTick is not part of any phase: it drains its queue after the current operation finishes and before the event loop moves to any phase, making it higher priority than setImmediate or setTimeout in all cases.

Expect these follow-ups

• What happens if you call process.nextTick recursively without a base case?
• When would you choose setImmediate over setTimeout(fn, 0)?

As asked

You are building a POST /payments endpoint. The client may retry on network failures. How do you make the endpoint idempotent, and what do you store, where, and for how long?

Sample answer outline

The client sends an Idempotency-Key header with a UUID. The server stores the key with the request fingerprint and the response in a durable store (Postgres or Redis with persistence) before returning. On retry, the server returns the stored response without re-executing the payment. Key considerations: store the key atomically with the operation using a transaction or a unique constraint; set a TTL (24 to 48 hours is typical); return 409 if the same key is used with a different request body. A strong answer also covers what to do while the first request is still in-flight (return 202 or 409 with a Retry-After header).

Expect these follow-ups

• How do you handle the case where the server crashes after the payment succeeds but before you save the idempotency record?
• Should idempotency keys be stored in the same database as payment records? Why or why not?

As asked

Name three security vulnerabilities specific to JWT handling that you have seen or know about, and tell me how you would prevent each one in a Node.js API.

Sample answer outline

Three common vulnerabilities: (1) the 'alg: none' attack where the algorithm header is set to none and the signature is stripped; prevent by hardcoding the expected algorithm in verify options, never trusting the header's alg field. (2) Algorithm confusion between RS256 and HS256 where the public key is used as an HMAC secret; prevent by specifying algorithms explicitly. (3) Missing or short expiry leading to stolen tokens being valid indefinitely; enforce short exp (15 minutes for access tokens) and use refresh tokens. A strong answer also covers storing JWTs in httpOnly cookies rather than localStorage to prevent XSS theft.

Expect these follow-ups

• How do you implement token revocation for JWTs without a blocklist?
• What is the difference between a JWT and a session cookie from a security standpoint?

As asked

Your service calls a downstream dependency that occasionally times out. You add retries. Walk me through why naive fixed-interval retries make things worse during an outage, and how you would implement exponential backoff with jitter.

Sample answer outline

Fixed-interval retries from many clients cause synchronized thundering herd: all clients retry at the same moment, amplifying the load on a struggling service. Exponential backoff doubles the delay each attempt (1s, 2s, 4s, 8s up to a cap), reducing the collision rate. Full jitter adds a random value between 0 and the computed delay, spreading retries across time. A strong answer also covers: setting a maximum retry count and total timeout budget, treating 429 and 503 responses as retryable but 400 and 404 as not retryable, and using the Retry-After header when provided.

Expect these follow-ups

• How do circuit breakers complement retry logic?
• What is the difference between a retry budget and a retry limit?

As asked

Explain the cache-aside and write-through caching patterns. For a product catalog read-heavy endpoint, which do you choose and how do you handle cache invalidation when a product is updated?

Sample answer outline

Cache-aside: the application checks the cache, reads from the DB on miss, and populates the cache. Write-through: every write goes to the cache and the DB synchronously. For a read-heavy product catalog, cache-aside is preferred because write-through adds write latency for every update even if nobody reads those products. Invalidation on update: delete the cache key on write (delete-on-write) or use a short TTL. A strong answer discusses the trade-off between stale-while-revalidate (serve stale, refresh in background) and aggressive TTLs, and the risk of a thundering herd on cache miss when a hot key expires.

Expect these follow-ups

• How do you prevent a thundering herd when a popular cache key expires?
• What is a write-behind cache and when would you use it?

As asked

Cloudflare Workers run at the edge using the V8 isolate model rather than containers or Lambda-style sandboxes. Walk me through what that means in practice: cold starts, memory isolation, CPU time limits, and what constraints a developer has to design around that they would not hit in AWS Lambda.

Sample answer outline

A strong answer explains that isolates share a single V8 heap partition per PoP but are isolated from each other without OS process overhead, giving near-zero cold starts (sub-millisecond vs hundreds of ms in Lambda). CPU time is capped (10ms on free, 30s on paid with Unbound), wall-clock time is different from CPU time. No filesystem access, no native modules, limited Node.js compatibility (Workers runtime is not Node.js). Memory per isolate is capped at 128MB. Strong candidates mention Durable Objects for stateful coordination and how KV is eventually consistent while Durable Objects give strong consistency.

Expect these follow-ups

• What happens to in-flight requests when Cloudflare deploys a new version of your Worker?
• How would you handle a task that takes longer than the CPU time limit?

As asked

Implement and explain a circuit breaker that wraps calls to a downstream service. Cover the state machine, configuration, and what metrics you expose.

Sample answer outline

States: closed (requests pass through), open (requests fail fast), half-open (a small probe is allowed to test recovery). Transitions driven by a rolling error rate over a window, with thresholds for opening and a cooldown before half-open. Configuration knobs: failure threshold, rolling window size, cooldown duration, half-open probe count. Metrics: state changes, fail-fast count, downstream success rate. The trap to avoid: opening the breaker on the first error spike, which causes a thundering herd when the breaker tries to close.

Reference implementation (typescript)

type State = "closed" | "open" | "half-open";

class CircuitBreaker {
  private state: State = "closed";
  private failures = 0;
  private openedAt = 0;

  constructor(
    private readonly threshold: number,
    private readonly cooldownMs: number,
  ) {}

  async call<T>(fn: () => Promise<T>): Promise<T> {
    if (this.state === "open") {
      if (Date.now() - this.openedAt < this.cooldownMs) throw new Error("circuit-open");
      this.state = "half-open";
    }
    try {
      const result = await fn();
      this.failures = 0;
      this.state = "closed";
      return result;
    } catch (err) {
      this.failures += 1;
      if (this.failures >= this.threshold) {
        this.state = "open";
        this.openedAt = Date.now();
      }
      throw err;
    }
  }
}

Expect these follow-ups

• How do you avoid the synchronised retry storm when the breaker closes?
• When would you not use a circuit breaker?
• How would you implement this in a service mesh vs in application code?

As asked

Design and implement a rate-limiting strategy on a login endpoint that mitigates credential stuffing without locking out legitimate users.

Sample answer outline

Multiple keys, not just IP. Rate-limit per username (slows stuffing against a single account), per IP (slows distributed attempts from a single source), and globally on failure rate (signals an attack in progress). Use exponential backoff per username after consecutive failures. Add a CAPTCHA after N failures, do not lock out (lockout is itself a denial-of-service vector). Watchlist credential dumps with HaveIBeenPwned-style hash prefix checks and force a password reset for known-compromised passwords. Discuss residential proxy networks that defeat per-IP rate limits and why per-username matters more.

Reference implementation (typescript)

import { Redis } from "ioredis";

export async function checkLoginAttempt(
  redis: Redis,
  username: string,
  ip: string,
): Promise<{ allowed: boolean; backoffMs: number }> {
  const userKey = `login:user:${username}`;
  const ipKey = `login:ip:${ip}`;
  const [userFails, ipFails] = await Promise.all([
    redis.incr(userKey),
    redis.incr(ipKey),
  ]);
  await Promise.all([redis.expire(userKey, 900), redis.expire(ipKey, 900)]);
  if (userFails > 10 || ipFails > 50) {
    const backoffMs = Math.min(60_000, 2 ** Math.min(userFails, 10) * 100);
    return { allowed: false, backoffMs };
  }
  return { allowed: true, backoffMs: 0 };
}

Expect these follow-ups

• What if attackers come from a botnet with 100k unique IPs?
• When would you reach for device fingerprinting?
• What is the false positive rate of locking based on geo?

As asked

Your CPU-bound task is blocking the event loop. You have two options: the cluster module or worker threads. How do you choose between them, and what are the memory and communication trade-offs of each?

Sample answer outline

Cluster forks separate OS processes, each with its own V8 heap and event loop, connected via IPC. Worker threads share memory through SharedArrayBuffer and communicate via message passing within the same process. For pure CPU work that needs shared state, worker threads win on memory overhead. For complete isolation and independent crashes, cluster is safer. A strong answer also mentions that worker threads still use libuv under the hood and that the main thread's event loop remains unblocked in both cases.

Expect these follow-ups

• How do you share a TCP port across cluster workers?
• What primitives do you use to synchronize access to SharedArrayBuffer between worker threads?

As asked

Your Redis cache is at 80% memory and you are choosing an eviction policy before it fills up. Walk me through the options and tell me which you would pick for a session store versus a leaderboard versus a rate-limiter, and why.

Sample answer outline

For a session store, allkeys-lru evicts the least recently used key across all keys, which makes sense because stale sessions should go first. For a leaderboard where all scores must be retained, noeviction is correct and you should scale memory instead. For a rate limiter using counters with TTLs, volatile-ttl evicts keys closest to expiry, which effectively removes the oldest rate windows first. A strong answer distinguishes between volatile (only keys with TTL) and allkeys variants and notes that Redis LRU is approximate, not exact.

Expect these follow-ups

• How does Redis LFU eviction differ from LRU in practice?
• What is the risk of setting maxmemory-policy to noeviction in production?

As asked

Your Kafka consumer group is rebalancing every few minutes and you are seeing lag spikes. Walk me through the most likely causes and what configuration knobs you would turn.

Sample answer outline

The most common causes are: session.timeout.ms being too short relative to processing time, max.poll.interval.ms exceeded when a consumer takes too long between polls, and consumers crashing or restarting. Mitigations include increasing max.poll.interval.ms, reducing max.poll.records so each poll batch is processed faster, and using a heartbeat thread separate from the processing thread. Static group membership with group.instance.id avoids full rebalances on restarts. A strong answer also mentions cooperative incremental rebalancing in newer Kafka versions.

Expect these follow-ups

• How does the partition assignment strategy affect rebalance duration?
• What is the difference between eager and cooperative rebalancing?

As asked

You need a distributed lock so only one instance of a cron job runs at a time across 10 pods. You reach for Redis. Walk me through how you implement it, what the failure modes are, and whether Redlock actually solves them.

Sample answer outline

The naive approach uses SET key value NX PX ttl. Failure modes include: the lock holder dies before releasing, so TTL is essential; the lock expires while the job is still running and another pod acquires it; and clock skew making TTL-based reasoning unreliable. Redlock runs the SET across multiple independent Redis nodes and requires a majority to grant the lock, reducing single-node failure risk. The Antirez vs Kleppmann debate is worth knowing: Redlock is not safe under clock jumps or GC pauses without fencing tokens. A strong answer recommends using a fencing token (a monotonically increasing value) verified by the protected resource.

Expect these follow-ups

• What is a fencing token and how does the protected resource use it?
• How would you implement lock renewal for long-running jobs?

As asked

Compare the token bucket algorithm and the sliding window log algorithm for API rate limiting. When does each break down, and how would you implement either in Redis at scale?

Sample answer outline

Token bucket allows burst up to bucket capacity and refills at a steady rate; it is easy to implement with Redis incr and a TTL but allows a burst at the start of each window. Sliding window log stores each request timestamp in a sorted set, counts entries within the window, and rejects if over the limit; it is accurate but memory-heavy at high traffic. Sliding window counter is a practical middle ground: keep counters for the current and previous window, interpolate. A strong answer mentions atomic Lua scripts in Redis to avoid race conditions between the check-and-increment steps.

Expect these follow-ups

• How would you handle rate limiting across a distributed cluster where Redis itself could be a bottleneck?
• How do you rate limit by user ID plus IP simultaneously with different limits for each?

As asked

Your Go service's memory and goroutine count grow steadily until it OOMs after 12 hours. How do you detect where goroutines are leaking, and what are the three most common patterns that cause this?

Sample answer outline

Use runtime.NumGoroutine() metrics over time, or expose pprof and look at the goroutine profile. The three most common patterns are: (1) a goroutine blocked on a channel send or receive with no sender/receiver that will ever arrive; (2) a goroutine waiting on a context that is never cancelled because the parent context was not properly propagated; (3) a goroutine spawned in a loop with no bound or backpressure mechanism. Fixes involve always pairing goroutines with a done channel or context cancellation, using errgroup for coordinated shutdown, and adding a timeout to every blocking operation.

Expect these follow-ups

• How do you use pprof in a production Go service without significant overhead?
• What does the goleak library do and where in your test suite would you use it?

As asked

You need to publish a Kafka event whenever a database record is created, and you cannot afford to lose events even if the service crashes after the DB write but before the publish. Walk me through the transactional outbox pattern and how you would implement it.

Sample answer outline

Write the domain record and an outbox row in the same database transaction. A separate poller or change-data-capture (CDC) process reads committed outbox rows and publishes them to Kafka, then marks them as processed. Debezium is the most common CDC tool for Postgres, streaming the WAL. The at-least-once guarantee means consumers must be idempotent. A strong answer also covers the polling vs CDC trade-off: polling is simpler but adds latency and DB load; CDC is near-real-time but operationally heavier.

Expect these follow-ups

• How does Debezium connect to Postgres to read the WAL and what permission does it need?
• What happens to unprocessed outbox rows if your poller goes down for an hour?

As asked

Your Node.js service is growing from 200MB to 1.5GB of heap over 6 hours. You cannot reproduce it locally. Walk me through exactly how you would profile and isolate the leak in production with minimal disruption.

Sample answer outline

Send SIGUSR2 or use the --inspect flag on one pod to enable the V8 inspector. Take two heap snapshots several minutes apart and compare the object allocation delta in Chrome DevTools. Look for object counts growing in the Comparison view. Common culprits: closures retaining event emitter listeners (check for missing removeListener calls), global caches with no eviction, and module-level arrays that grow. A strong answer also mentions using process.memoryUsage() metrics over time, and the clinic.js heapprofiler tool for less invasive profiling. Kill the pod after the session to avoid lingering inspector exposure.

Expect these follow-ups

• How do you detect an event emitter listener leak specifically?
• What is a retained size versus a shallow size in a heap snapshot?

As asked

You are designing a public REST API that will be consumed by mobile clients you cannot force-update. Compare URL versioning, header versioning, and content negotiation. Which would you choose and why?

Sample answer outline

URL versioning (/v1/users) is the most visible and easiest for clients to implement and for routing at the proxy level. Header versioning (Accept-Version: 1) keeps URLs clean but is invisible in browser address bars and harder to cache at the CDN layer. Content negotiation (Accept: application/vnd.company.v1+json) is the REST purist's choice but complex for clients. For a mobile API with varied client versions, URL versioning is the pragmatic choice because it is cacheable, loggable, and debuggable. A strong answer covers deprecation strategy: how long to maintain old versions and how to communicate sunset dates.

Expect these follow-ups

• How would you implement parallel running of v1 and v2 in the same Node.js or Go codebase?
• How do you handle breaking versus non-breaking changes in your versioning policy?

As asked

Your team is debating whether to use gRPC or REST/JSON for communication between 15 internal microservices. Walk me through the concrete technical reasons you would choose one over the other.

Sample answer outline

gRPC uses Protocol Buffers for serialization (3 to 10x smaller payloads, faster encoding), HTTP/2 for multiplexing, and generates type-safe client/server stubs from a schema, reducing contract drift. REST/JSON is human-readable, widely supported, and simpler to debug with curl. gRPC wins on performance and strong typing for high-throughput internal services. REST wins for external APIs where clients are heterogeneous. A strong answer covers streaming: gRPC supports server, client, and bidirectional streaming natively. It also mentions that gRPC service discovery and load balancing require more infrastructure than HTTP/1.1 REST.

Expect these follow-ups

• How does Protobuf backward compatibility work with field numbers?
• How would you expose a gRPC service to a browser client?

As asked

A Go HTTP handler receives a request and fans out to three downstream gRPC calls. The client drops the connection mid-flight. Walk me through how Go context cancellation propagates and what happens to the in-flight gRPC calls.

Sample answer outline

net/http sets the request context to Done when the client closes the connection. If you pass that context to grpc.Dial or http.NewRequestWithContext, the gRPC client cancels its own call by sending a RST_STREAM. If the downstream service checks ctx.Err() or uses context-aware DB queries, it stops processing. A strong answer covers: always pass context as the first argument down the call stack; never use context.Background() inside a handler; use errgroup.WithContext to fan out and cancel all children if one fails.

Expect these follow-ups

• What is the difference between context.WithCancel and context.WithTimeout?
• How do you prevent a slow goroutine from leaking after a context is cancelled if it does not check ctx.Done?

As asked

You are designing a feature where a user uploads a video and it needs to be transcoded. Your team suggests either a direct HTTP call to the transcoder service or putting a job on a queue. Walk me through how you make that decision.

Sample answer outline

Synchronous RPC couples the caller to the callee: if the transcoder is slow or down, the upload endpoint fails. Transcoding is slow (minutes), so holding an HTTP connection open is impractical. A queue decouples them: the upload endpoint enqueues a job and returns immediately with a job ID. The transcoder processes jobs at its own pace and can be scaled independently. A queue also provides built-in retry and durability. Synchronous calls are appropriate for fast, critical-path operations where the caller needs the response immediately. A strong answer also considers dead letter queues, job status polling or webhooks for the client, and queue depth as a scaling signal.

Expect these follow-ups

• How do you expose job status to the client after they receive a 202 Accepted?
• What happens to jobs in the queue if your transcoder deployment is rolled back?

As asked

Cloudflare KV is eventually consistent. Durable Objects provide strong consistency. Describe the design of Durable Objects: how they achieve serialized execution, how they handle migration between PoPs, and when you would pick Durable Objects over KV for a real application.

Sample answer outline

A strong answer explains that each Durable Object is a single-threaded actor with a unique ID, always running in exactly one PoP at a time. All requests to that object are serialized by the runtime, so there are no concurrent writes. The Durable Object storage API is asynchronous (returns Promises) but requests are processed one at a time, so callers never observe interleaved state. Migration happens when the runtime decides to move an object to a different PoP; in-flight requests are drained first. Use DOs over KV when you need transactions, counters, WebSocket connection state, or any write-read consistency guarantee. KV is fine for read-heavy globally replicated config.

Expect these follow-ups

• How would you implement a rate limiter using Durable Objects?
• What is the latency trade-off when a client in Tokyo hits a Durable Object pinned to a US PoP?

As asked

A customer reports that their Cloudflare cache hit ratio dropped from 85% to 30% overnight with no configuration changes on their end. Walk me through how you would diagnose this step by step.

Sample answer outline

A methodical answer checks Cache-Control and Vary headers in the origin response first, since a new Vary: Cookie or no-store directive would bypass the cache. Then check if query string parameters changed (new tracking params creating cache key fragmentation). Look at whether the origin started returning Set-Cookie on cached responses (which Cloudflare treats as a bypass signal). Check if the customer deployed a new Cache Rule or Page Rule that altered caching behavior. Strong candidates mention using Cloudflare Cache Analytics and the CF-Cache-Status response header (HIT, MISS, EXPIRED, BYPASS, DYNAMIC) to narrow down which status is spiking.

Expect these follow-ups

• How would you use a Cache Rule to cache responses that include Set-Cookie?
• What is edge cache TTL vs browser cache TTL, and which one does Cloudflare control?

As asked

You are building a multi-tenant SaaS on Cloudflare Workers. Each tenant has a configuration object that changes rarely and is read on every request. Some tenants also need transactional writes across multiple records. Walk me through how you would pick between KV, D1, and Durable Objects for each use case.

Sample answer outline

KV is ideal for the configuration read: globally replicated, eventually consistent, very low read latency, handles high read fanout. D1 (SQLite at the edge) is good for structured relational data with SQL queries and ACID transactions within a database, but it has regional consistency and is not globally replicated the way KV is. Durable Objects suit the transactional use case when you need cross-record consistency with strong ordering. A strong answer draws the distinction clearly: KV for hot reads, D1 for structured SQL with ACID within a region, DOs for actor-model coordination or cross-record transactions with global ordering.

Expect these follow-ups

• What happens to a D1 database query latency for a user in Sydney if the database is hosted in North America?
• How would you replicate a D1 database closer to users in multiple regions?

As asked

You are setting up a CI/CD pipeline for a critical Cloudflare Worker that handles payment redirects. Walk me through how you would structure environments (dev, staging, prod), manage secrets, handle rollbacks, and use Wrangler's features to minimize deployment risk.

Sample answer outline

A strong answer uses Wrangler environments in wrangler.toml to separate dev/staging/prod with different KV namespaces, route patterns, and Worker names. Secrets are stored in Cloudflare's encrypted secret store via `wrangler secret put` rather than in source code. Deployments use `wrangler deploy` gated by CI tests. Rollback uses `wrangler rollback` to revert to the last version, or candidates mention Gradual Deployments (percentage-based traffic splitting between old and new Worker versions). Monitoring uses Cloudflare Workers analytics and logpush to detect errors post-deploy.

Expect these follow-ups

• How does Cloudflare's version control for Workers differ from a typical containerized deployment?
• What is a Workers Placement Hint and when would you use it?

As asked

A user in Singapore is reporting a time-to-first-byte of 800ms on a Cloudflare-proxied site. The origin is in Frankfurt. Walk me through how you would identify where the latency is coming from, using Cloudflare's tools and standard network diagnostics.

Sample answer outline

A strong answer starts with checking CF-Cache-Status to confirm the response is a cache MISS, then looks at the CF-RAY header to identify which PoP handled the request. With a cache miss, TTFB = edge-to-origin RTT + origin processing + network. Singapore to Frankfurt is roughly 160-180ms RTT bare minimum, so 800ms suggests origin processing or a TCP handshake to origin adding overhead. Next steps: check if Argo Smart Routing is enabled (uses Cloudflare's private backbone), look at origin response time in Cloudflare Analytics, and use the Observatory tool. If origin has keep-alive misconfigured, new TCP handshakes on each request add hundreds of ms.

Expect these follow-ups

• What is Argo Smart Routing and under what conditions does it most improve latency?
• How would enabling Cloudflare's Tiered Cache change the origin hit rate for this scenario?