Vibe coder or product engineer backend interview questions

As asked

You are adding an AI chat feature to your product. The LLM API supports streaming. Walk me through the full stack implementation from the API call to the user seeing tokens appear in real time, including how you handle errors mid-stream.

Sample answer outline

On the server you call the LLM with stream:true, pipe the response as a ReadableStream through a Next.js Route Handler with the correct content-type of text/event-stream, and flush chunks as SSE events. On the client you use the Fetch API with a ReadableStream reader or the Vercel AI SDK's useChat hook which handles reconnection and parsing. Error handling mid-stream is the tricky part: if the stream closes with an error event you need to surface that in the UI rather than silently stopping, and you should add a timeout so a stalled stream does not block the user indefinitely. A strong answer also mentions storing partial completions for resumability if the user refreshes.

Expect these follow-ups

• How would you rate-limit streaming endpoints to prevent abuse without killing legitimate long sessions?

As asked

You are building auth for a new product. Walk me through the concrete tradeoffs between storing session state in a server-side store with a cookie versus using stateless JWTs, and when each breaks in production.

Sample answer outline

Server-side sessions are easy to revoke instantly by deleting the session record, but require a shared store like Redis when running multiple serverless instances so they are not truly stateless. JWTs are self-contained and scale without a shared store, but revoking a JWT before expiry requires a denylist which brings back the shared store you were trying to avoid. Short-lived access tokens plus refresh token rotation is the common production pattern: the access JWT expires in 15 minutes so you limit exposure, and the refresh token in an HttpOnly cookie can be revoked server-side. A strong answer also covers storing JWTs in HttpOnly cookies rather than localStorage to prevent XSS token theft.

Expect these follow-ups

• How does NextAuth.js handle token rotation and session invalidation under the hood?

As asked

You are shipping a new API route on Vercel. What factors make you choose the Edge Runtime over the default Node.js serverless runtime, and what are the things you give up by going Edge?

Sample answer outline

Edge runs in V8 isolates at the CDN PoP closest to the user, so cold starts are under 1ms versus the 200ms to 1s range for Node.js serverless. That matters for latency-sensitive paths like auth middleware or personalization headers. What you give up is Node.js built-ins: no fs, no native modules, limited crypto surface, and no long-running TCP connections, which rules out most database drivers except those built for HTTP or WebSocket. A strong answer names Prisma Accelerate, Neon HTTP driver, or Supabase as ways to connect to a DB from Edge, and mentions that Edge Middleware has a 2MB bundle size cap while Edge Functions allow up to 4MB.

Expect these follow-ups

• How would you handle a database call that requires a persistent connection pool from an Edge function?

As asked

You are adding rate limiting to a REST API built on Next.js API routes. You want to allow 100 requests per minute per user. Walk me through how you implement this without a dedicated rate-limiting service, and what breaks at scale.

Sample answer outline

The simplest approach is a sliding window counter in Redis using INCR plus EXPIRE, or the more precise token bucket or sliding log using a Lua script for atomicity. Upstash Redis is a common choice here because it is HTTP-based and works from Edge functions. What breaks at scale is Redis becoming a hot key if many users hit their limits simultaneously, and the naive fixed-window approach letting users burst to 2x the limit across a window boundary. A strong answer also covers returning Retry-After headers, distinguishing anonymous vs authenticated limits, and syncing limits across multiple serverless function instances which cannot share in-process memory.

Expect these follow-ups

• How would you handle rate limiting for a user who is making requests from multiple devices simultaneously?

As asked

You need to let users upload files up to 100MB from the browser directly to S3. Walk me through the full implementation including how you avoid routing the file through your server and how you validate file type and size securely.

Sample answer outline

The client requests a presigned PUT URL from your API, which calls S3's createPresignedPost or the SDK's getSignedUrl with a short TTL and conditions like content-length-range and content-type. The browser uploads directly to S3 using that URL, so your server never touches the bytes. File type validation cannot rely on the Content-Type header the client sends because it is spoofable; instead you use an S3 Lambda trigger or a separate processing step that reads the file magic bytes after upload. Size limits are enforced by the presigned URL condition. A strong answer also covers CORS configuration on the S3 bucket, using a separate upload-only bucket separate from your main assets bucket, and scanning uploads with an antivirus Lambda before moving them to the serving bucket.

Expect these follow-ups

• How would you handle multipart upload for files over 5GB?

As asked

You are starting a new product with a Next.js frontend and Node.js backend, both in TypeScript. How do you choose between REST, GraphQL, and tRPC, and what specifically makes you pick one over the others for this stack?

Sample answer outline

tRPC is the fastest path for a TypeScript monorepo because you get end-to-end type safety without a code generation step: the client infers types directly from the router definition. REST is the right choice when you need a public API that external clients consume, since tRPC requires a TypeScript client. GraphQL pays off when you have multiple client types with very different data needs or when you have a dedicated frontend team that wants to own their queries. A strong answer notes that tRPC can run on top of Next.js API routes or as an HTTP server, that it composes well with Zod for input validation, and that the tradeoff is tighter coupling between client and server that makes versioning harder.

Expect these follow-ups

• How would you add a public REST API alongside an existing tRPC API without duplicating logic?

As asked

Your Next.js app is deployed on Vercel. You need to send a transactional email five minutes after a user signs up. Vercel functions time out after 10 seconds by default. How do you implement this reliably?

Sample answer outline

You cannot block the serverless function for 5 minutes, so you need a durable queue or scheduler. Options in roughly increasing complexity: a simple Postgres-backed job table polled by a cron-triggered function (simple but polling lag), a hosted queue like Inngest, Trigger.dev, or QStash that handles retries and scheduling with a webhook back to your function, or a dedicated worker process on a long-running server. The key properties you need are durability (the job survives a function cold start), at-least-once delivery with deduplication, and retry with backoff on failure. A strong answer mentions that Vercel Pro and Enterprise plans allow functions up to 300s or 900s, but that is not the right tool for deferred scheduling anyway.

Expect these follow-ups

• How do you make the email send idempotent so retries do not send the same email twice?

As asked

A user clicks the checkout button twice quickly. Walk me through how you prevent double charging, and separately, how you handle Stripe webhook events that may arrive out of order or more than once.

Sample answer outline

For the double click, disable the button on first click in the UI, but that alone is not enough because two requests can still race through. The server-side fix is using Stripe's idempotency keys: generate a UUID per checkout session and pass it as the Idempotency-Key header so Stripe deduplicates the charge. For webhooks, Stripe can deliver the same event more than once, so your handler must be idempotent: store the event ID in a DB table and skip processing if already seen. Out-of-order delivery is handled by always reading the authoritative state from Stripe's API on receipt rather than inferring state transitions from event sequence, for example fetching the PaymentIntent status when you receive payment_intent.succeeded rather than trusting local state.

Expect these follow-ups

• How would you test the double-charge scenario and webhook deduplication in a local development environment?