Question 1

Design a real-time collaborative document editor (think Notion or Google Docs). Walk through both the backend architecture and the client-side state model.

Accepted Answer

Start by scoping: multi-user concurrency, conflict resolution (OT vs. CRDT—explain the tradeoff explicitly), persistence model (event log vs. snapshots). On the backend: WebSocket fanout, operational transform service, storage (append-only event store + periodic snapshots), presence service. On the frontend: local optimistic state, a CRDT or OT client library, rebasing local ops against server-ack'd ops, undo stack complexity. Discuss consistency guarantees you're willing to relax for latency. What interviewers look for: Whether you can reason about distributed state at both tiers simultaneously without losing the thread. They want to see that you understand CRDTs aren't free (merge complexity, memory) and OT isn't simple (transformation functions are hard to get right). Staff signal: you name the actual failure modes and explain which you'd accept.

Question 2

You're building a dashboard that aggregates metrics from 50+ microservices and must load in under 2 seconds for P95 users. How do you architect both the data pipeline and the frontend rendering?

Accepted Answer

Backend: push vs. pull aggregation, pre-materialized views in a time-series store (e.g., ClickHouse or TimescaleDB), a thin BFF (Backend for Frontend) layer that composes and caches, CDN-cached static shells. Frontend: skeleton UI + streaming responses (HTTP chunked or SSE), component-level data fetching with SWR/React Query, selective hydration, route-level code splitting. Discuss cache invalidation strategy and staleness tolerance per metric type. What interviewers look for: Ability to connect data pipeline latency directly to rendering strategy. They want to see you challenge assumptions ('does every metric need to be real-time?') and propose tiered freshness. Staff signal: you define SLOs per data type and design differently for each tier.

Question 3

Your team is debating whether to adopt a microfrontend architecture for a large monolithic React app. Make the case for and against, then give your recommendation.

Accepted Answer

For: team autonomy, independent deployments, technology flexibility, isolated failure domains. Against: significant overhead (module federation complexity, shared state headaches, duplicated dependencies, increased bundle sizes, testing surface explosion), worse UX consistency, latency on cross-app communication. Recommendation should be conditional: justified when org has 4+ independent teams shipping to the same surface with distinct release cadences; otherwise the cost is rarely worth it. Discuss alternatives: well-bounded feature flags, domain-driven module structure within a monorepo. What interviewers look for: Whether you can resist trend-chasing and give a nuanced recommendation with explicit conditions. They're evaluating technical judgment and your ability to influence architectural decisions across teams without defaulting to whatever is fashionable.

Question 4

Design a type-safe, paginated REST API for a feed of heterogeneous content items (articles, videos, events) in TypeScript, including the server handler and the client-side hook consuming it.

Accepted Answer

Define a discriminated union type for content items. Design the API response envelope: `{ items: ContentItem[], cursor: string, hasMore: boolean }`. Server handler: cursor-based pagination (not offset—explain why at scale), type narrowing per item kind, proper HTTP semantics (200 vs. 206). Client hook: useInfiniteFeed wrapping React Query's useInfiniteQuery, optimistic append on scroll, deduplication by item ID, error boundary separation. Show awareness of N+1 on the backend. What interviewers look for: Type discipline, API contract ownership, and awareness that the frontend and backend contract is a product decision. They want to see you define the contract first, then implement both sides. Staff signal: you discuss versioning strategy and how a breaking change would be handled.

Question 5

A Next.js application has a Core Web Vitals regression—LCP jumped from 1.8s to 4.2s after a recent deploy. Walk through your diagnosis and remediation process.

Accepted Answer

Structured triage: isolate the regression to the specific commit/route using Lighthouse CI diffs and RUM data (not just lab). Check: did a critical image lose its priority hint or preload? Did a third-party script move to render-blocking? Did an RSC or SSR route start doing a slow DB call on the critical path? Did bundle size spike (check webpack-bundle-analyzer diff)? Remediation ladder: fix the root cause first, then add monitoring. Discuss how you'd prevent regression with Lighthouse CI budgets in CI/CD. What interviewers look for: Systematic debugging methodology rather than a list of performance tips. They want to see you go from symptom to root cause, not spray optimizations. Staff signal: you immediately ask about RUM vs. lab data distinction and call out that P95 LCP matters more than median.

Question 6

Describe the full threat model for a web application that handles user-uploaded files and displays them to other users. What controls do you implement at each layer?

Accepted Answer

Threat surface: stored XSS via SVG/HTML uploads, SSRF if the server fetches URLs, malware distribution, path traversal, content-type sniffing. Controls by layer—upload: file type validation (magic bytes, not extension), size limits, AV scanning, store on isolated origin (not same domain); serving: Content-Disposition: attachment for downloads, X-Content-Type-Options: nosniff, serve from separate cookieless domain or object store URL, CSP on the display page; backend: run file processing in isolated sandbox (Lambda/container), never trust client-supplied MIME type. What interviewers look for: Whether you instinctively think in layers and cover both the upload and serve path. A mid-level answer covers XSS; a staff answer covers SSRF, sandbox isolation, and same-site origin separation as first-class concerns.

Question 7

Tell me about a time you changed the technical direction of a project after work had already begun. How did you build alignment and manage the cost?

Accepted Answer

Use a structured narrative: what signal prompted the re-evaluation (new data, failed assumption, external change), how you quantified the cost of continuing vs. pivoting, how you brought stakeholders along (written doc, prototype, explicit tradeoff table), what you did with the sunk cost argument, and how you handled team members who disagreed. Be specific about what you preserved from prior work. What interviewers look for: Intellectual honesty under pressure, the ability to change your own mind and others' without creating organizational debt. They're evaluating whether you lead by reasoning or by authority. Staff-level signal: you explicitly discuss how you handled the people who were emotionally invested in the original direction.

Question 8

Describe a technical standard or practice you introduced that was adopted beyond your immediate team. What made it stick?

Accepted Answer

Pick something concrete: a TypeScript strict-mode migration, a BFF pattern, an API contract review process, an observability standard. Explain the adoption mechanism: RFC process, internal talk, pilot team, dogfooding. Distinguish between mandated adoption (fragile) and organic adoption (durable). Discuss what friction you removed and what you learned from teams that didn't adopt it. What interviewers look for: Whether your impact is organizational, not just technical. Staff engineers multiply through others. They want to see you understand that adoption is a product problem—you have to make the right thing the easy thing.

Question 9

How would you architect the state management for a complex multi-step workflow (e.g., a checkout flow with branching logic, async validation, and partial save) in a React application?

Accepted Answer

Model the workflow as an explicit state machine (XState or a hand-rolled reducer with typed states and transitions—explain the choice). Separate UI state from server state (React Query/SWR handles server sync; the machine handles workflow logic). Persist intermediate state to the backend on each valid transition (not just on submit) for resilience. Discuss how you handle: concurrent validation, rollback on server error, deep-linking to a step, and accessibility of step transitions. What interviewers look for: Whether you reach for explicit modeling (state machines) rather than ad-hoc flag accumulation. They want to see that you've been burned by boolean flag soup and have a principled alternative. Staff signal: you raise the deep-linking and accessibility concerns unprompted.

Question 10

Design the data model and query strategy for a social graph feature (followers/following) that needs to support: follow counts, mutual-follow detection, and a 'people you may know' recommendation at scale.

Accepted Answer

Core model: edges table (follower_id, followee_id, created_at) with composite indexes in both directions. Follow counts: materialized counters (increment/decrement on write) rather than COUNT(*) at query time. Mutual detection: EXISTS subquery or bidirectional edge check. 'People you may know': friend-of-friend query is expensive at scale—precompute via a batch job or graph DB (Neo4j, Neptune) for the recommendation layer, or use approximate methods (Bloom filters for intersection estimation). Discuss fan-out-on-write vs. fan-out-on-read for feed implications. What interviewers look for: Whether you distinguish between what works at 10K users vs. 10M users and design accordingly. Staff signal: you proactively separate the OLTP path (follow/unfollow) from the analytics/recommendation path and propose different storage engines for each.

Question 11

How do you design observability into a full-stack feature from the start, before it ships? Walk through what you instrument and how.

Accepted Answer

Define SLIs before writing code: latency (P50/P95/P99), error rate, and business-level correctness metrics (e.g., 'checkout completion rate'). Backend: structured logging with trace IDs, distributed tracing spans wrapping every external call, custom metrics on key business events. Frontend: RUM for Core Web Vitals, client-side error tracking (Sentry), custom performance marks around key interactions. Wire trace IDs from the backend into client-side error reports for end-to-end correlation. Define alerting thresholds and on-call runbook before launch, not after the first incident. What interviewers look for: Whether observability is a design input, not an afterthought. They want to see that you define SLIs before writing code and that you connect frontend RUM to backend traces. Staff signal: you mention business-level metrics alongside technical ones and treat on-call ergonomics as a first-class concern.

Question 12

You've inherited a full-stack codebase with significant technical debt—an outdated frontend framework, a monolithic backend with no clear domain boundaries, and no test coverage. You have one quarter and a team of four. What do you do?

Accepted Answer

Start with a week of diagnosis: identify the debt that actually causes production pain vs. aesthetic debt. Prioritize by blast radius × frequency of change. Don't rewrite—strangle. On the frontend: introduce the new framework incrementally in new routes (strangler fig pattern), leaving stable legacy routes untouched. On the backend: draw domain boundaries in the existing code first (packages/modules), add contract tests at boundaries before extraction. Test coverage: focus on the highest-churn, highest-risk paths first, not blanket coverage. Communicate a realistic roadmap with explicit tradeoffs to stakeholders. What interviewers look for: Pragmatism over purity. They want to see that you resist the rewrite temptation, triage by actual risk, and protect team morale by shipping visible improvements alongside debt work. Staff signal: you explicitly discuss how you communicate progress and tradeoffs to non-technical stakeholders, and how you keep the team from burning out on pure maintenance.

Staff Full-Stack Engineer Interview Questions

What to expect

12 questions, with how to answer them

1. Design a real-time collaborative document editor (think Notion or Google Docs). Walk through both the backend architecture and the client-side state model.

2. You're building a dashboard that aggregates metrics from 50+ microservices and must load in under 2 seconds for P95 users. How do you architect both the data pipeline and the frontend rendering?

3. Your team is debating whether to adopt a microfrontend architecture for a large monolithic React app. Make the case for and against, then give your recommendation.

4. Design a type-safe, paginated REST API for a feed of heterogeneous content items (articles, videos, events) in TypeScript, including the server handler and the client-side hook consuming it.

5. A Next.js application has a Core Web Vitals regression—LCP jumped from 1.8s to 4.2s after a recent deploy. Walk through your diagnosis and remediation process.

6. Describe the full threat model for a web application that handles user-uploaded files and displays them to other users. What controls do you implement at each layer?

7. Tell me about a time you changed the technical direction of a project after work had already begun. How did you build alignment and manage the cost?

8. Describe a technical standard or practice you introduced that was adopted beyond your immediate team. What made it stick?

9. How would you architect the state management for a complex multi-step workflow (e.g., a checkout flow with branching logic, async validation, and partial save) in a React application?

10. Design the data model and query strategy for a social graph feature (followers/following) that needs to support: follow counts, mutual-follow detection, and a 'people you may know' recommendation at scale.

11. How do you design observability into a full-stack feature from the start, before it ships? Walk through what you instrument and how.

12. You've inherited a full-stack codebase with significant technical debt—an outdated frontend framework, a monolithic backend with no clear domain boundaries, and no test coverage. You have one quarter and a team of four. What do you do?

Study tips