How do you decide when to use a framework or library versus writing something from scratch?

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.

How do you approach performance optimisation in a web application?

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.

How do you approach authentication and authorisation in a web application?

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.

Tell me about a full-stack feature you built end to end. Walk me through the decisions you made.

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.

Describe a time you had to debug a difficult production issue. How did you approach it?

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.

Give an example of a technical decision you made that you would change in hindsight.

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.

How do you approach designing a REST API?

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.

How do you write and maintain tests for full-stack code?

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.

How do you handle database design and migrations in a production system?

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.

Full-Stack Developer

Full-Stack Developer interviews cover both front-end and back-end fundamentals, system design thinking, and your ability to make sound technical decisions across the entire product layer. Interviewers want to see that you can build end-to-end features, debug across the stack, and work effectively with product and design teams. This guide covers the questions asked most often and the answers that demonstrate real full-stack experience.

For general interview preparation tips, read our guide to common interview questions.

Common Full-Stack Developer Interview Questions

Behavioural Interview Questions for Full-Stack Developer Roles

Technical Questions for Full-Stack Developer Candidates

What Hiring Managers Look for in Full-Stack Developer Interviews

Full-Stack Developers who stand out can reason about trade-offs across the entire stack, not just execute within one layer. Look for candidates who explain why they made a technical decision, not just what they built. Ask them to walk through a real feature they own end to end and probe the reasoning at each layer. The best full-stack developers are also comfortable saying they are stronger on one side of the stack than the other.

Questions to Ask Your Interviewer

→What does the current tech stack look like and are there any planned migrations or refactors?
→How is the front-end and back-end work divided across the team?
→What does the test coverage look like and what is the team's approach to quality?
→How are production deployments handled and what does the on-call setup look like?
→What does a typical end-to-end feature look like from ticket to production?

Practise These Questions Before Your Interview

The mock interview tool builds a practice session around a specific job posting and your background, so you rehearse the questions most likely to come up.

Start Practising

Free to start. No commitment.

Related Roles