Question 1

Design and implement a rate-limiting middleware for an Express.js API that supports per-user and per-endpoint limits, with configurable windows.

Accepted Answer

Start by clarifying requirements: fixed window vs. sliding window, storage backend (in-memory vs. Redis for distributed systems), and what happens on limit breach (429 with Retry-After header). Implement a sliding window counter using a sorted set in Redis (ZADD/ZRANGEBYSCORE) keyed by userId:endpoint. Discuss tradeoffs: fixed window is O(1) but has boundary burst issues; sliding window is accurate but uses more memory. Show the middleware signature, error handling, and how limits are injected via config. What interviewers look for: Do you default to a real distributed-safe solution (Redis) rather than in-process state? Do you know the tradeoffs between window strategies without being prompted? Can you write clean, testable middleware code and handle edge cases like clock skew or Redis failure gracefully?

Question 2

Implement a debounced autocomplete input in React that fetches suggestions from an API, handles race conditions, and is accessible.

Accepted Answer

Use a controlled input with a useDebounce hook (300–500ms). Cancel stale requests using AbortController inside useEffect — track a request ID or use the abort signal to ignore out-of-order responses. Render a listbox with aria-expanded, aria-autocomplete, and keyboard navigation (arrow keys, Enter, Escape). Discuss when to use a library like Downshift vs. rolling your own. Mention showing a loading state and handling empty/error states without jarring UI shifts. What interviewers look for: Race condition handling is the key signal — many candidates miss this. Accessibility is a secondary signal that separates senior from mid-level. They also want to see clean separation of data-fetching logic from rendering, and awareness of when to reach for a library.

Question 3

Design a real-time collaborative document editor (like Google Docs, but scoped to concurrent text editing for up to 50 simultaneous users).

Accepted Answer

Split the problem: client state (local optimistic updates), sync protocol (Operational Transformation vs. CRDTs — name the tradeoff: OT needs a central server to sequence ops, CRDTs are commutative but complex), transport (WebSockets via a presence server), persistence (append-only operation log + periodic snapshots), and read path (serve the latest snapshot + trailing ops). Discuss conflict resolution, cursor broadcasting, reconnection/backfill, and where Redis Pub/Sub fits for fanout. Mention Yjs or Automerge as real CRDT libraries. What interviewers look for: Interviewers want to see that you understand why naive last-write-wins fails, that you know the OT vs. CRDT vocabulary and tradeoffs, and that you can describe both the client and server sides coherently. Naming real libraries shows practical grounding.

Question 4

You need to add an activity feed (like a Twitter timeline) to an existing social app. Walk through the data model, API, and frontend rendering strategy.

Accepted Answer

Choose between fan-out-on-write (precompute feeds at write time, good for read-heavy), fan-out-on-read (compute at read time, simpler but slower), or hybrid (fan-out for normal users, skip celebrities). Data model: activity table (actor_id, verb, object_id, target_id, created_at) with an index on (target_user_id, created_at DESC). API: cursor-based pagination keyed on created_at + id. Frontend: virtualized list (react-virtual or TanStack Virtual), optimistic local prepend for own actions, polling or WebSocket for new items. Discuss cache invalidation and CDN edge caching for public feeds. What interviewers look for: The fan-out tradeoff is the core signal. Candidates who skip it or don't know why fan-out-on-write doesn't scale for celebrities with millions of followers show a gap. Cursor-based vs. offset pagination is a secondary check.

Question 5

You have a multi-tenant SaaS app. Compare row-level tenancy (shared schema), schema-per-tenant, and database-per-tenant. How do you choose, and what are the migration implications?

Accepted Answer

Row-level: simplest ops, lowest cost, but requires every query to include tenant_id and RLS policies (PostgreSQL Row Level Security is worth naming). Schema-per-tenant: good isolation, pg_schemas or MySQL databases, but connection pooling becomes expensive (PgBouncer in transaction mode helps). Database-per-tenant: strongest isolation, easiest compliance, but operationally expensive and makes cross-tenant analytics hard. Choose based on compliance requirements, tenant count, and query patterns. For migrations: schema-per-tenant requires running migrations per tenant — use a migration runner that iterates schemas. Discuss blue/green migration patterns for zero-downtime. What interviewers look for: Do you know what RLS is and why it's not a complete solution on its own? Do you understand connection pool exhaustion as a real operational concern? Can you reason about which model fits which business context rather than defaulting to one?

Question 6

Design a versioning strategy for a public REST API that has 10,000 active clients and is adding breaking changes.

Accepted Answer

Compare URL versioning (/v1/, /v2/), header versioning (Accept: application/vnd.api+json;version=2), and query param versioning. URL versioning is most explicit and cacheable — preferred for public APIs. For the rollout: add the new version alongside the old, use a deprecation timeline communicated via Sunset header (RFC 8594), run both versions simultaneously behind a router layer. Consider a transformation layer (adapter pattern) that translates v1 requests to the internal model so you don't maintain two code paths. Discuss sunset analytics: track per-version usage to know when it's safe to retire. What interviewers look for: Knowing the RFC for Sunset headers is a strong signal. The adapter/translation layer idea shows architectural thinking. Interviewers check whether you think about client impact — not just what's convenient for the server team.

Question 7

A Next.js page that aggregates data from three internal microservices is slow (3–4s TTFB). Walk through how you diagnose and fix it.

Accepted Answer

First, instrument: are the three fetches sequential or parallel? In Next.js getServerSideProps or an RSC, sequential awaits are a common culprit — fix with Promise.all. Then profile each service call with server-side tracing (OpenTelemetry spans). If one service is slow, check whether the data is static enough for ISR (Incremental Static Regeneration) or edge caching. Consider moving aggregation to a BFF (Backend for Frontend) layer to reduce chattiness. On the client side, check for waterfall fetches caused by nested components. Mention HTTP/2 and keep-alive for inter-service calls if not already in place. What interviewers look for: Sequential vs. parallel fetches is the first thing a strong candidate spots. Knowing ISR and when it's appropriate separates Next.js-experienced candidates. OpenTelemetry or any distributed tracing tool shows production maturity.

Question 8

A junior engineer opens a PR adding a feature that accepts a filename from the user and reads that file from disk. What issues do you raise in code review?

Accepted Answer

Path traversal is the primary vulnerability — user input like ../../etc/passwd must be sanitized. Fix: use path.basename() to strip directory components, then join to a fixed allowed base directory and verify the resolved path still starts with that base (path.resolve + startsWith check). Raise: no rate limiting on the endpoint, no file size limit, no allowlist of permitted extensions, and no authentication check shown. Also check whether the file content is returned directly (potential info disclosure) or just a status. Recommend writing a test with a traversal payload. What interviewers look for: Path traversal by name is table stakes; the defense (resolve + prefix check) is the real signal. Raising multiple layers (rate limiting, auth, extension allowlist) shows defense-in-depth thinking rather than patching a single hole.

Question 9

How would you architect state management for a large React application with server state, local UI state, and shared client state across multiple teams?

Accepted Answer

Separate concerns explicitly: server state (data from APIs) → React Query or SWR, which handle caching, deduplication, and invalidation; shared client state (auth session, feature flags, shopping cart) → Zustand or Jotai (prefer atomic stores over a monolithic Redux store at this scale); local UI state (modal open, form draft) → useState/useReducer co-located with the component. Avoid putting server state in Redux — it leads to cache staleness bugs. For multi-team scale, discuss module federation or micro-frontend boundaries to prevent state coupling. Define clear ownership: which team owns which store slice. What interviewers look for: The signal is whether you distinguish server state from client state — many candidates lump everything into one store. Knowing React Query vs. Redux for server state is now expected at senior level. Multi-team ownership discussion shows organizational thinking.

Question 10

What is your testing strategy for a full-stack feature that spans a React frontend, a Node.js API, and a PostgreSQL database?

Accepted Answer

Layer the tests: unit tests for pure business logic (validation, transformation) at both layers; integration tests for the API using a real test database (not mocks) — spin up PostgreSQL in Docker or use testcontainers, run migrations, test actual SQL behavior; component tests for React using Testing Library against a mocked API (MSW for network interception); end-to-end tests (Playwright or Cypress) for critical user flows only, run on CI against a staging environment. Avoid mocking the database in integration tests — it hides real query bugs. Test the contract between frontend and backend with OpenAPI or TypeScript shared types. What interviewers look for: The key signal is avoiding over-mocking at the integration layer. Knowing MSW for frontend testing and testcontainers for database testing shows production-tested judgment. The shared types point shows full-stack systems thinking.

Question 11

Tell me about a time you identified and fixed a systemic problem in your team's engineering process — not just a one-off bug.

Accepted Answer

Use STAR but go deep on the 'systemic' part: what was the root cause pattern, how did you identify it was recurring (metrics, postmortems, code review observations), what was the solution (process change, tooling, documentation, architectural guardrails), and how did you measure improvement. Strong answers involve some form of data, a before/after comparison, and show that you influenced peers rather than just fixing it yourself. Avoid answers where 'systemic fix' means 'I wrote a script for myself.' What interviewers look for: Interviewers check whether you operate beyond your own tasks — this is the key senior-vs-mid differentiator. They want evidence of lateral influence (changing behavior across the team) not just vertical depth (doing your own work well). Quantified impact is a strong positive signal.

Question 12

Describe a situation where you had to push back on a product or business requirement because of technical risk, and how you handled it.

Accepted Answer

Structure: describe the requirement and why it was technically risky (security, scalability, maintainability — be specific). Explain how you framed the tradeoff in business terms rather than just saying 'that's hard.' Describe the negotiation: did you propose an alternative, a phased approach, or a spike to quantify the risk? Outcome: what was agreed, and was the outcome good? Be honest if you were overruled — interviewers respect candidates who learned from it. Avoid answers where the pushback was trivially correct (e.g., 'they wanted to skip all tests'). What interviewers look for: This tests whether you can be a technical voice in cross-functional decisions without being obstructionist. The signal is translating technical risk into business impact language, proposing alternatives rather than just vetoing, and showing you can influence without authority.

Senior Full-Stack Engineer Interview Questions

What to expect

12 questions, with how to answer them

1. Design and implement a rate-limiting middleware for an Express.js API that supports per-user and per-endpoint limits, with configurable windows.

2. Implement a debounced autocomplete input in React that fetches suggestions from an API, handles race conditions, and is accessible.

3. Design a real-time collaborative document editor (like Google Docs, but scoped to concurrent text editing for up to 50 simultaneous users).

4. You need to add an activity feed (like a Twitter timeline) to an existing social app. Walk through the data model, API, and frontend rendering strategy.

5. You have a multi-tenant SaaS app. Compare row-level tenancy (shared schema), schema-per-tenant, and database-per-tenant. How do you choose, and what are the migration implications?

6. Design a versioning strategy for a public REST API that has 10,000 active clients and is adding breaking changes.

7. A Next.js page that aggregates data from three internal microservices is slow (3–4s TTFB). Walk through how you diagnose and fix it.

8. A junior engineer opens a PR adding a feature that accepts a filename from the user and reads that file from disk. What issues do you raise in code review?

9. How would you architect state management for a large React application with server state, local UI state, and shared client state across multiple teams?

10. What is your testing strategy for a full-stack feature that spans a React frontend, a Node.js API, and a PostgreSQL database?

11. Tell me about a time you identified and fixed a systemic problem in your team's engineering process — not just a one-off bug.

12. Describe a situation where you had to push back on a product or business requirement because of technical risk, and how you handled it.

Study tips