How do you decide what logic belongs in the front end versus the back end?

Anything involving security, data access, critical business rules, or calculations that must not be manipulable by the client always belongs in the back end. The front end handles presentation, UI interactions, and convenience-level validation (not security-level). The core rule: never trust data coming from the client without also validating it on the server.

What are the advantages and limitations of a fullstack approach compared to specialized teams?

Advantages: less coordination overhead, faster delivery for smaller features, and a coherent system-wide perspective. Limitations: a fullstack developer rarely reaches the depth of a specialist in any single layer. For highly scaled systems or demanding performance requirements, specialization delivers more value. Fullstack is most effective in growing products, not in mature high-traffic systems.

How would you structure a new fullstack project to keep it maintainable as the team grows?

Separate concerns from day one: front end and back end in distinct projects or with clear boundaries, even within a monorepo. Define API contracts with shared typing (TypeScript, OpenAPI). Keep business logic separate from HTTP handlers and UI components. Establish naming conventions, folder structure, and a code review process before the team scales.

How would you manage a user's authentication state across the front-end and back-end layers?

The session token or JWT is issued by the back end after successful authentication. On the front end, it is stored securely — an httpOnly cookie provides the strongest protection — and sent with every request. The back end validates the token on each protected endpoint. The front end uses authentication state only for UI decisions, never as a real access control mechanism.

What strategy would you use to keep data types in sync between the front end and back end in a TypeScript project?

Define types or interfaces in a shared package within a monorepo (Turborepo, Nx) or publish them as an internal package. Alternatively, auto-generate types from the API schema (OpenAPI → TypeScript via openapi-typescript, or tRPC for end-to-end type safety without code generation).

How would you approach debugging a bug that could be in the front end, the back end, or the data layer?

Isolate the layer systematically: first verify whether the API is returning the correct data using a tool like Postman or curl, before looking at the front end. If the API is failing, check the server logs and the generated query. If the API is correct but the front end is rendering the data wrong, the bug is in the presentation or transformation layer. The goal is to narrow the search space before reading code.

What considerations would guide your choice between a monorepo and separate repositories for a fullstack project?

A monorepo makes it easier to share types, tooling, and pipelines, and enables atomic commits that touch both front end and back end together. Separate repositories simplify per-team access control and independent pipelines. The decision depends on team size and how often changes span both layers. For small teams or projects with significant shared code, a monorepo usually wins.

How would you prioritize what to learn in order to grow as a fullstack developer when you are stronger in one layer than the other?

Identify what is actually blocking you in your current work: if the front end is slowing down feature delivery, invest there first. Learn the weaker layer through real tasks, not just tutorials. Seek out projects where engaging with that layer is unavoidable. An effective fullstack developer doesn't need to be exceptional at both layers — they need to be competent enough not to be blocked.

How would you implement a file upload feature that requires changes to the front end, back end, and storage layer?

Front end: file input with type and size validation before sending, progress bar using XMLHttpRequest or fetch streaming. Back end: an endpoint that validates the file (magic bytes, size limit), uploads it to S3 or equivalent using presigned URLs — so the client uploads directly to storage, not through the server — and saves the reference in the database. Never store files on the server's filesystem in production.

What are the practical differences between using tRPC and a traditional REST API in a fullstack TypeScript project?

tRPC eliminates the need to generate or maintain API type definitions: back-end types are automatically inferred on the front end with no codegen step. The trade-off is that it only works when client and server share the same language (TypeScript) and typically the same monorepo. REST remains the right choice when the API must be consumed by external clients, native mobile apps, or third parties.

How would you handle real-time data synchronization between the server and multiple clients in a fullstack app?

For frequently changing data with low-latency requirements: WebSockets via Socket.io or the native WebSocket API. For less frequent updates: Server-Sent Events (unidirectional, simpler to implement). For cases where eventual consistency is acceptable: polling with React Query or SWR. The right choice depends on update frequency, the number of concurrent clients, and how much infrastructure complexity is acceptable.

How would you design end-to-end error handling so that back-end errors are surfaced to the user in a useful way?

Define a structured error format on the back end (error code, human-readable message, optional details). On the front end, a fetch interceptor or wrapper normalizes all errors to that format. Components display specific, actionable messages for business errors (409 conflict, 422 validation) and generic messages for unexpected failures (500). Log all 5xx errors with sufficient context in an observability platform.

How would you implement role-based authorization where the same permission model applies in both the back end and the front end?

The back end is always the source of truth for permissions. The token includes the user's roles as claims, which the back end validates on every protected request. The front end uses those same claims for UI decisions — showing or hiding elements — but never as a real access control mechanism. A shared permission-evaluation utility can be used in both layers for consistency.

What caching strategies would you apply in a fullstack architecture to reduce database load?

On the client: React Query or SWR with stale-while-revalidate to avoid redundant requests. On the server: API response caching with Redis for expensive queries with low update frequency. At the database level: proper indexes and the engine's query result cache. The right strategy depends on the read/write profile — data that changes infrequently and is read heavily benefits most from caching.

How would you organize testing in a fullstack project to achieve meaningful coverage without over-testing?

Back end: unit tests for pure business logic, integration tests for API endpoints against a real test database (not mocks). Front end: component tests with Testing Library focused on user-observable behavior, not implementation details. End-to-end tests with Playwright or Cypress for critical flows such as sign-up, login, and checkout. Avoid duplicating coverage: if the back end has solid integration tests, there is no need to fully mock the API on the front end.

How would you approach pagination for data consumed by both a web view and a public API?

Design pagination on the back end with a consistent format — cursor-based or page-based with metadata: total, next_cursor, has_more — that serves both consumers equally well. In the web view, React Query or SWR can abstract pagination with useInfiniteQuery. The response format should be identical regardless of the consumer; the difference lies only in how each client presents it.

How would you decide whether a project should adopt a fullstack monolithic architecture or separate the front end and back end as independent projects?

Fullstack monolith (Next.js, Nuxt, Remix): lower operational complexity, unified deployment, ideal for small teams or products where the front end and back end evolve together. Separation: necessary when the back end must serve multiple clients (web, mobile, third parties), when front-end and back-end teams operate independently, or when each layer requires a distinct scaling strategy. Separation carries a real coordination cost that must be justified by the actual needs of the project.

How would you design the data architecture of a fullstack application that needs to work fully offline and sync when a connection is available?

Implement a local storage layer (IndexedDB via Dexie, SQLite with OPFS) that acts as the client's source of truth. On reconnection, sync with the server by resolving conflicts using a defined strategy: last-write-wins, CRDTs, or manual resolution for high-risk conflicts. The server should expose a sync endpoint that accepts a vector of local changes and returns the server's changes since the last checkpoint.

How would you scale a fullstack application originally built as a monolith when it starts showing bottlenecks?

Before decomposing into microservices, exhaust the options within the monolith: horizontal scaling, query optimization, caching, CDN for static assets. If the bottleneck is isolated — image processing, email sending — extract that specific service first. The strangler fig pattern allows you to peel off parts of the monolith incrementally without a full rewrite. Premature decomposition adds complexity without solving the real problem.

How would you implement feature flags that control behavior in both the front end and back end in a coordinated way?

Use a centralized feature flag service (LaunchDarkly, Unleash, or a custom solution). The back end evaluates flags in the user's context and includes the results in a configuration endpoint that the front end fetches at session start. Both layers use the same evaluation. Never evaluate flags only on the client for features with security or billing implications — the client can be manipulated.

How would you ensure data consistency in a fullstack application that uses optimistic UI updates on the front end?

Optimistic updates on the client (React Query mutation with rollback) improve the user experience but require a reconciliation mechanism. If the server rejects the operation, the client must revert its local state and notify the user. For high-stakes operations such as payments or reservations, avoid optimistic UI or implement a confirmation step before presenting the result as final. The back end is always the source of truth.

How would you structure session management and authentication state in a Next.js application that renders on both the server and client?

With the App Router, httpOnly cookies are available in Server Components and Route Handlers via cookies() from next/headers. The server can validate the session without ever exposing the token to the client. In Client Components, session state is surfaced through a provider that consumes a secure endpoint or the next-auth context. The rule: real session validation always happens on the server; the client receives only what it needs to render the UI.

Presenting yourself as fullstack without being able to go deep on any specific layer

Saying 'I know everything' without demonstrating real depth in at least one layer erodes trust. Interviewers expect a fullstack developer to have a primary area of strength and be able to articulate why. Breadth with no depth at all is the most common signal of a developer who has used frameworks without understanding what lies beneath them.

Overlooking security when designing features that span the front end and back end

Proposing solutions such as storing tokens in localStorage, validating permissions only on the client, or trusting URL parameters for authorization decisions are serious red flags. In a fullstack role, candidates must demonstrate that they understand the threat model at every layer.

Not considering the impact on the front end when proposing back-end API changes

A fullstack developer who proposes breaking API changes without addressing front-end migration or versioning is effectively working in mental silos despite owning both layers. The whole point of fullstack ownership is the end-to-end perspective.

Assuming that fullstack means every project should be a monolith

Defaulting to a monolithic architecture out of comfort — without evaluating when separating concerns delivers more value — signals limited architectural experience. The right call is choosing the architecture that fits the context, not the one you are most familiar with.

Not having a clear sense of when to scale the solution up and when to bring in a specialist

An effective fullstack developer knows when a problem requires a DBA, a security engineer, or an infrastructure specialist. Proposing fullstack solutions for problems that genuinely require deep specialization is just as problematic as being unable to solve anything without calling in a specialist.

Describing past projects without being able to explain the architecture decisions of any layer in depth

Fullstack candidates often describe complete projects but cannot explain why they chose that database, how they modeled the schema, or why they structured the UI that way. This suggests they executed without truly understanding — which raises real doubts about their ability to make sound decisions on the next project.

Fullstack Developer

Designs and builds digital products end-to-end, from the user interface to the data layer.

A Fullstack Developer is capable of working across every layer of an application: front end, back end, and database. They are not necessarily a deep specialist in every layer, but they have the technical judgment to make coherent decisions across the entire stack and reduce friction between teams. They are especially valuable in startups, small teams, or projects where delivery speed and an integrated product perspective are the top priorities. They collaborate with designers, product managers, and DevOps to ship complete features from design through to production.

JavaScriptTypeScriptReactNode.jsPostgreSQLDocker

Recruit the best Fullstack Developer here

Start now

Main Responsibilities

•Implement complete features that span UI changes, business logic, and data model updates in a coherent, end-to-end manner.
•Design and integrate REST or GraphQL APIs consumed by the front end that the same developer builds.
•Model database schemas and write optimized queries aligned with the product's access patterns.
•Identify and resolve performance issues on both the client and the server side.
•Participate in architecture decisions by evaluating the impact across all layers of the system.
•Maintain CI/CD pipelines and ensure that changes at any layer pass automated testing before reaching production.

Key Skills

Technical Skills

Front-end development with React, Vue, or Angular and state management in medium-to-large-scale applications
Back-end development with Node.js, Python, or equivalent: REST/GraphQL APIs, authentication, and business logic
Relational databases (PostgreSQL, MySQL) and non-relational (MongoDB, Redis), with sound judgment on when to use each
Containerization with Docker and deployment on cloud platforms (AWS, GCP, Vercel, Railway)
TypeScript as a unified language across front end and back end for shared data contracts
Testing at both layers: unit tests, API integration tests, and component tests with Testing Library

Soft Skills

End-to-end product perspective to anticipate how a technical decision will affect the end user's experience
Autonomy to take a feature from inception to production without depending on another team for each layer
Clear communication when acting as a bridge between front-end, back-end, and design specialists
Focus management: knowing when to go deep on a layer and when to move forward with a good-enough solution
Context-switching ability to move between layers of the stack within the same workday
Judgment to recognize when a problem calls for a specialist rather than a fullstack solution

Real use cases

Context

In startups or new products, iteration speed is more valuable than specialization. A fullstack developer can build and validate complete features without coordinating across separate teams.

Real examples

Web applications with authentication, CRUD operations, and a dashboard in a single repository
Landing pages with forms connected to a custom back end
Functional prototypes for validation with real users
Quick integrations with third-party services (Stripe, Twilio, SendGrid)

Context

Many companies have applications where the front end and back end live in the same repository. A fullstack developer can navigate and evolve that codebase without friction.

Real examples

Rails, Django, or Laravel applications with templates and logic in the same stack
Incremental migrations from server-rendered views to React components
Query optimization and UI improvements within the same development cycle
Bug fixes that span multiple layers of the system

Context

Connecting a product to payment services, notifications, analytics, or third-party authentication requires coordinated changes in both the back end and front end.

Real examples

Stripe checkout implementation: webhook handling on the back end and payment UI on the front end
OAuth2 integration with Google or GitHub as part of the login flow
Transactional email system setup with Resend or SendGrid
Feature flag implementation with LaunchDarkly on both client and server

Context

Internal tools need to be functional and maintainable — not necessarily polished in design. A fullstack developer can deliver value quickly without depending on multiple specialists.

Real examples

Admin panels for managing users, roles, and content
Operational dashboards with tables, filters, and data export
Support tools for customer success teams to manage accounts and orders
Internal reporting systems with basic data visualizations

Context

In teams with short iteration cycles, a fullstack developer can implement a complete feature within a single sprint without waiting on another team to finish their part.