Full Stack Developer Interview Questions

I start from the data model and the access patterns, design the API contract next (so the UI can build in parallel), then the UI against that contract. I think about validation and auth at the API boundary, caching where reads dominate, and the failure/empty/loading states in the UI. I shipped subscription billing this way — Postgres schema, Node API, React UI — and it processed ₹4 Cr/month within two quarters.

Measure before guessing — add timing/tracing to find whether it's the query, the network, or the render. Most of the time it's the database: an N+1, a missing index, or fetching more than needed. I cut a set of endpoints from 800ms to 120ms p95 with indexes, a Redis cache, and killing N+1s — not by rewriting in a faster language.

When reads dominate and slightly-stale data is acceptable. The hard part is invalidation — I prefer short TTLs plus event-based busting for the data that must be fresh, and I never cache user-specific data in a shared key. Wrong caching leaks one user's data to another or serves stale prices; those are the bugs to design against up front.

REST for simple, cacheable, resource-shaped APIs and public surfaces. GraphQL when clients need flexible, nested data and you're tired of either over-fetching or maintaining a dozen bespoke endpoints — at the cost of caching complexity and N+1 risk on resolvers. It's a client-needs decision, not a fashion one.

S: A launch needed billing live in two weeks; the 'right' abstraction needed more. T: Ship without creating a mess. A: I built a contained, well-tested first version with a clear seam, shipped, then refactored to the general solution once we had real usage data. R: Hit the date and the refactor landed cleanly because the seam was deliberate, not accidental.

A typed contract — OpenAPI or a shared TypeScript types package, or end-to-end types via tRPC. Contract-first lets both sides build in parallel and breaks loudly at compile time instead of silently in prod. I also keep integration tests that exercise the real boundary.

Auth at the edge (validate a signed token), authorization enforced server-side on every protected resource — never trust the client to hide a button. I keep session/JWT handling in one place, scope permissions to the resource, and treat the frontend checks as UX only. The server is the source of truth.

Tested at the right levels, observable (logs/metrics for the new paths), handles the error and empty states, has a rollback or feature flag, and doesn't regress performance. 'It works on my machine' is the start, not the finish — production-ready means it fails safely and I can see when it does.