Full-Stack Developer Interview Questions

I start with the problem scope. If the problem is well-defined and a mature library solves it reliably, I use the library: reinventing solved problems wastes time and introduces untested code. The factors I weigh are: how well-maintained is the library (recent commits, active issues, large community?), does it match our scale requirements, and what is the bundle cost if we are on the front-end? I am particularly cautious about pulling in large dependencies for small utilities. For a date formatting need I would not add a full utility library if the native Intl API handles the use case. For something like state management or HTTP handling, a battle-tested library usually wins because those surfaces are full of edge cases. I also consider long-term ownership: a dependency I cannot fork or debug is a risk if it goes unmaintained.

I always start by measuring before optimising. Premature optimisation based on assumptions leads to changes that make the code harder to read without improving the user experience. My toolkit starts with Lighthouse and browser DevTools for front-end: I look at Core Web Vitals (LCP, INP, and CLS). For back-end I profile slow queries, review N+1 problems in database access patterns, and check whether expensive computations are being repeated unnecessarily. Common front-end fixes: code splitting and lazy loading, image optimisation, and reducing unnecessary re-renders. On the back-end: query indexing, caching at the appropriate layer, and moving heavy processing to background jobs. I document performance baselines before and after any optimisation work so the improvement is measurable.

I treat authentication and authorisation as different concerns. Authentication answers "who are you?" and authorisation answers "what are you allowed to do?" For authentication I default to a well-maintained provider (such as Auth0, Supabase Auth, or Clerk) rather than rolling my own, because session management, token rotation, and OAuth flows have too many security edge cases. I use JWTs for stateless auth with short expiry times and store them in HTTP-only cookies to prevent XSS access. For authorisation I implement role-based access control at the API layer, not just the front-end. Front-end gating is a UX convenience, not a security control. I also apply the principle of least privilege: every service and user role gets the minimum permissions required for their function.

I built a real-time notification system for an internal dashboard. The requirements were: push notifications to users when an event occurred, display unread count in the nav bar, and mark notifications as read on click. For the back-end I chose WebSockets over polling because we needed real-time delivery and the connected user count was low enough that connection overhead was not a concern. I built a Node.js event emitter that listened to database change events via a Postgres trigger and pushed them through a socket connection to the client. On the front-end I used React Context with a reducer pattern for optimistic mark-as-read updates. I added a REST fallback endpoint to fetch the initial list on page load. The feature launched with zero regression and reduced support tickets about missed events by roughly 70% in the first month.

We had a production issue where a subset of users were receiving stale data on a read-heavy page, but only after being active for more than 30 minutes in the same session. I reproduced the issue locally with a long-running session, then isolated the affected code path: the data was fetched on component mount and stored in local state with no refresh logic. The root cause was a session-level cache that had been applied to data that could change during a session. The fix was to add a cache invalidation trigger on the relevant mutation event. I also added a monitoring alert for cache hit rate on that endpoint to catch any future regression. Post-fix, the issue was resolved for 100% of affected users within one deploy.

Early in my career I built a feature using client-side rendering for a page that needed to rank in search results. I chose CSR because the team was already using a React SPA and I wanted to stay consistent with the existing architecture. Six months later we discovered the page was not being indexed correctly because the crawler was not executing JavaScript reliably. We had to rebuild using server-side rendering: three weeks of work that delayed other features. The lesson was to always identify rendering requirements before choosing an architecture: CSR, SSR, SSG, and ISR each have specific use cases and the decision should be deliberate. I now add a rendering strategy question to my checklist for any new page or route.

I follow a resource-oriented design where endpoints represent entities, not actions. I use HTTP verbs correctly: GET for reads, POST for creates, PUT/PATCH for updates, DELETE for deletes. For status codes I follow the standard: 200 for success, 201 for created, 400 for client errors, 404 for not found, 401 for unauthenticated, 403 for unauthorised, 500 for server errors. I always version APIs from the start. For pagination I use cursor-based pagination for large datasets rather than offset pagination, because offset pagination becomes inconsistent when records are added or deleted during pagination. I also document the API contract before building it: it forces clearer thinking and gives the front-end team something concrete to review.

I follow a testing pyramid: many unit tests, fewer integration tests, and a small number of end-to-end tests. Unit tests cover pure functions and isolated component rendering. Integration tests cover API routes with a test database and service-layer logic. End-to-end tests cover the critical user journeys only: login, core user action, and conversion flow, using tools like Playwright. For test coverage I do not chase a percentage target; I aim to cover every user-visible outcome and every error state. I also write tests before fixing bugs: a failing test that reproduces the bug is proof that the fix works and a guard against regression. Tests that are slow, flaky, or hard to understand get refactored or deleted.

I design schemas with future evolution in mind: nullable columns are cheaper to add later, foreign key constraints are better enforced in the database than application code, and adding an index to an existing production table needs care to avoid locking. For migrations I use a dedicated migration tool rather than running raw SQL manually, and every migration is version-controlled and reviewed before production. I also distinguish between schema migrations and data migrations: schema changes should be backwards compatible where possible so a rollback is safe. I use an add-before-remove pattern for column changes: add the new column, deploy, migrate data, deploy again, then remove the old column. I always test migrations on a production data snapshot first.