Full Stack Developer Interview Questions and Answers

What interviewers are testing: Whether you understand vertical feature ownership across browser, API, database, and basic ops—not just knowing two frameworks.

A full stack developer builds features across the frontend, backend, database, and deployment path.

You usually own features vertically, not just one layer.

Common responsibilities:

• Frontend — UI, forms, client state, accessibility, performance
• Backend — APIs, business logic, validation, authentication
• Database — schema design, queries, indexes, migrations
• Integration — connect UI, API, auth, and data correctly
• Ops basics — Docker, CI/CD, logs, environment variables, monitoring

Stacks vary by company:

Full stack interviews test breadth plus integration. You do not need to be the deepest expert in every layer, but you should understand how a request moves from browser to API to database and back.

A strong answer is:

A full stack developer ships features end to end—UI, API, data, and deployment basics—I explain how a request flows from browser to database and back, even if I am not the deepest expert in every layer.

A typical full stack interview process has 4–6 rounds, depending on seniority and company size.

Some companies combine frontend and backend into one pair programming session.

Example tasks:

• Build a small form and submit it to an API
• Create a CRUD endpoint with validation
• Fetch data and render it in React
• Debug a broken login or API flow
• Design a small product such as a todo app, URL shortener, or dashboard

A strong candidate explains not only the code, but also the contract between layers.

A strong answer is:

I expect screening, technical depth, and often a live exercise—I prepare a 30-second intro, stories for each round, and questions for the interviewer.

What interviewers are testing: Whether you understand which full-stack fundamentals remain constant across stacks and which backend topics change with the runtime and framework—for example Spring transactions/JPA in Java versus asynchronous execution and middleware in Node.js.

The frontend expectations are often similar, but the backend depth changes based on the stack.

For Java full stack roles, expect more questions on service layers, dependency injection, JPA, transactions, and enterprise authentication.

For Node full stack roles, expect more questions on async behavior, middleware, request lifecycle, validation, and error handling.

A strong answer is:

The frontend fundamentals are similar, but the backend runtime changes the interview depth. I prepare the framework-specific parts separately and focus this full stack prep on how the layers integrate.

A realistic full stack prep plan should produce one working mini-project, not only notes.

Best mini-project:

• Login
• List records
• Create record
• Edit/delete record
• API validation
• Database persistence
• Basic tests
• Error/loading states
• README with setup steps

Interviewers prefer a cohesive mini-project because it proves you can connect frontend, backend, and database layers.

A strong answer is:

I block weekly themes—fundamentals first, then hands-on labs, then mocks—so I can explain concepts and demonstrate them under time pressure.

What interviewers are testing: Whether your answers move beyond implementation into production judgment—trade-offs, failure modes, observability, security, migration safety, rollback, and cross-team ownership.

Senior full stack interviews focus less on definitions and more on system judgment.

Extra expectations:

• End-to-end system design
• API and database trade-offs
• Frontend performance and UX decisions
• Auth, security, and permission boundaries
• Testing strategy across frontend and backend
• Observability: logs, metrics, alerts, tracing
• Deployment and rollback thinking
• Production incident stories
• Mentoring and cross-team communication

Common senior questions:

• How would you scale this feature?
• How would you debug slow checkout?
• How would you design permissions for multiple roles?
• How would you migrate a database without downtime?
• How would you reduce frontend bundle size?
• How would you handle a production incident?

A strong senior answer is:

“I would explain the trade-off, the risk, the monitoring plan, and the rollback path. Senior interviews test production judgment, not only syntax.”

A strong answer is:

“I would explain the trade-off, the risk, the monitoring plan, and the rollback path. Senior interviews test production judgment, not only syntax.”

What interviewers are testing: Whether you can build functional UI without relying entirely on a frontend specialist—semantic structure, accessibility, responsive layout, and enough CSS knowledge to debug common presentation issues.

Full stack developers are not expected to be CSS specialists, but they should be able to build readable, accessible, responsive UI.

Common topics:

• Semantic HTML — header, main, nav, section, button, label
• Accessibility basics — alt text, form labels, keyboard focus
• Box model — content, padding, border, margin
• box-sizing — why border-box is common
• Flexbox and Grid — common layout patterns
• Responsive design — media queries and fluid layouts
• Specificity — why a style does or does not apply

A strong answer is:

As a full stack developer, I may not design the whole system visually, but I should ship UI that is semantic, responsive, accessible, and maintainable.

What interviewers are testing: Whether your JavaScript fundamentals are strong enough to reason about asynchronous code, closures, scope, equality, data transformations, and browser behavior instead of solving everything through framework APIs.

JavaScript fundamentals matter because full stack developers often debug both browser code and Node.js code.

Important topics:

• let, const, and scope
• Closures
• this behavior
• Promises and async/await
• Fetch error handling
• Event loop basics
• Array methods such as map, filter, reduce, and find
• == vs ===
• ES modules and imports
• JSON serialization and parsing

Common live-coding tasks:

• Transform API data
• Debounce a search input
• Fetch and render a list
• Validate a form
• Filter or group records
• Handle loading and error states

Further reading: JavaScript equality

A strong answer is:

For full stack roles, JavaScript fundamentals matter because the same language often appears in the browser, build tools, tests, and backend services.

What interviewers are testing: Whether you understand the difference between React state and synchronization with external systems, including dependencies, cleanup, stale closures, and when an Effect is unnecessary.

useState stores local component state. Updating state triggers a re-render.

Common uses:

• Form input
• Toggle state
• Selected item
• Modal open/close
• Local UI filters

useEffect runs side effects after render. Use it when the component must synchronize with something outside React.

Common uses:

• Fetching data
• Subscribing to events
• Setting up timers
• Syncing with browser APIs
• Cleaning up external resources

Short example:

useEffect(() => {
  const controller = new AbortController();

  fetch(`/api/users/${userId}`, { signal: controller.signal })
    .then((response) => {
      if (!response.ok) {
        throw new Error(`HTTP ${response.status}`);
      }
      return response.json();
    })
    .then(setUser)
    .catch((error) => {
      if (error.name !== "AbortError") {
        setError(error);
      }
    });

  return () => controller.abort();
}, [userId]);

React still documents Effects as a way to synchronize with external systems, including manual data fetching, but its current guidance also recommends framework/data-cache mechanisms when available because direct Effect-based fetching is manual and can cause waterfalls or lack caching.

Manual fetching in an Effect is valid, but modern frameworks or data libraries such as TanStack Query often handle caching, deduplication, and request lifecycle more effectively.

Interviewers usually check:

• Dependency array mistakes
• Stale closures
• Cleanup on unmount or dependency change
• Avoiding effects for simple derived values

A strong answer is:

I use useState for local UI state and useEffect for synchronization with external systems. I also clean up subscriptions, timers, and stale requests.

What interviewers are testing: Whether you can contrast Local state and global state — when do you use each with trade-offs and a concrete example of when each is the right choice.

Use the smallest state scope that solves the problem.

Important distinction:

• Client state is owned by the UI.
• Server state comes from an API and needs caching, refetching, invalidation, and loading/error handling.

A strong full stack answer is:

“I keep state local when possible. I use Context for low-frequency global values, a state library for complex shared client state, and React Query or similar tools for server data.”

A strong answer is:

“I keep state local when possible. I use Context for low-frequency global values, a state library for complex shared client state, and React Query or similar tools for server data.”

What interviewers are testing: Whether you understand how static types improve frontend/backend contracts while recognizing that TypeScript does not replace runtime validation at trust boundaries.

Modern full stack roles ask about TypeScript because it helps catch API contract bugs before runtime.

Important interview distinction: TypeScript types disappear at runtime. A typed response does not prove that an external API actually returned that shape, so untrusted request/response data still needs runtime validation where appropriate.

Common benefits:

• Safer request and response types
• Shared DTOs between frontend and backend
• Better autocomplete and refactoring
• Fewer null/undefined mistakes with strict settings
• Clearer error handling with union types
• Better documentation through types

Useful talking points:

• interface or type for API DTOs
• Union types for success/error responses
• Discriminated unions for predictable state handling
• Strict null checks for safer data access
• OpenAPI code generation, GraphQL codegen, or tRPC for shared contracts

Tools such as generated OpenAPI clients improve compile-time contracts, while runtime schema validation can protect trust boundaries.

A strong answer is:

"TypeScript improves frontend/backend contracts and makes refactoring safer, but its types disappear at runtime. I still validate untrusted API data at trust boundaries rather than assuming a TypeScript interface proves the payload is valid."

What interviewers are testing: Whether you measure first, identify whether the bottleneck is rendering, JavaScript, network, API, or backend latency, and optimize the limiting layer rather than applying random frontend tricks.

I would first measure the bottleneck, then optimize the largest user-visible problem.

Common improvements:

• Code splitting and lazy-loaded routes
• Smaller JavaScript bundles
• Image optimization and CDN caching
• Avoiding waterfall API calls
• Parallelizing independent requests
• Caching API responses where safe
• Reducing unnecessary React re-renders
• Memoization only when profiling shows a need
• Rendering loading states quickly
• Avoiding large synchronous work on the main thread

Senior-level points:

• Improve LCP by optimizing hero content, images, fonts, and server response time
• Improve INP by reducing long tasks and expensive interaction handlers
• Improve CLS by reserving space for images and dynamic content
• Track performance budgets in CI when possible

A strong answer is:

I would measure first, then optimize based on impact. For full stack work, performance may require frontend changes, API changes, database indexing, caching, or CDN improvements.

What interviewers are testing: Whether you understand HTTP method semantics such as safety and idempotency and can map them correctly to application operations and retry behavior.

HTTP methods describe the action a client wants to perform on a resource.

Important interview distinction:

• Safe means the request should not change server state. GET is safe.
• Idempotent means repeating the same request has the same intended effect. PUT and DELETE are idempotent.
• PATCH can be designed to be idempotent, but you should not assume it automatically is.

Full stack interviews often connect methods to UI actions:

A strong answer is:

I choose HTTP methods based on resource intent. I also think about what the UI should do on success, validation failure, authorization failure, or retry.

What interviewers are testing: Whether you use HTTP status semantics to create a predictable contract between backend behavior and frontend UX instead of returning 200 for every outcome.

A full stack developer should know the status codes that affect both API behavior and frontend UX.

Useful distinction:

• 401 — the request lacks valid authentication credentials for the resource or authentication is required.
• 403 — the server understood the request but refuses it; insufficient authorization is a common cause.

In application APIs, 401 = authenticate; 403 = authenticated but insufficient permission is a useful practical shorthand.

• 400/422 usually map to form errors.
• 500 should not expose internal implementation details to the user.

A strong answer is:

The backend should return the right status and structured error body. The frontend should map that response to the right UX: inline field errors, login redirect, permission message, retry, or fallback error.

What interviewers are testing: Whether you can design an API contract that minimizes frontend guesswork through predictable resources, response shapes, error formats, pagination, authentication behavior, and compatibility rules.

A frontend-friendly REST API is predictable, consistent, and documented.

Important qualities:

• Consistent resource naming, such as /users/:id/orders
• Clear request and response shapes
• Stable error format
• Pagination for large lists
• Filtering and sorting conventions
• Versioning or compatibility policy
• OpenAPI/Swagger documentation
• Consistent auth behavior
• Avoiding too many round trips for one screen

Example response shape for a list endpoint:

{
  "items": [],
  "nextCursor": "abc123",
  "total": 120
}

Example error shape:

{
  "code": "VALIDATION_ERROR",
  "message": "Please fix the highlighted fields.",
  "fields": {
    "email": "Invalid email address"
  }
}

A common full stack mistake is building chatty APIs where one page needs many dependent calls before it can render.

A strong answer is:

A good API contract helps the frontend render loading, success, empty, and error states clearly. I would design endpoints around screen needs while keeping resource names and behavior consistent.

What interviewers are testing: Whether you can contrast REST and GraphQL for full stack projects with trade-offs and a concrete example of when each is the right choice.

REST and GraphQL both work well, but they solve different problems.

Use REST when:

• The app is mostly CRUD
• HTTP caching matters
• The team wants simpler API operations
• The resource model is clear

Use GraphQL when:

• Different clients need different field sets
• The UI combines data from many sources
• Strong schema-driven frontend/backend contracts are useful
• You can manage resolver performance carefully

A strong answer is:

I would choose REST by default for simple CRUD apps. I would consider GraphQL when clients need flexible nested data, but I would watch resolver performance, caching, authorization, and N+1 query problems.

What interviewers are testing: Whether you treat errors as part of the frontend/backend contract and can separate validation, authentication, authorization, not-found, conflict, network, and unexpected server failures into useful UX and observable backend behavior.

Errors should move from backend to frontend in a structured and predictable way.

Backend responsibilities:

• Validate input at the API boundary
• Return appropriate 4xx errors for client problems
• Return structured validation errors for forms
• Log 5xx errors with stack traces internally
• Include a correlation/request ID for debugging
• Avoid leaking secrets or internal details in API responses

Frontend responsibilities:

• Show field-level errors for validation failures
• Show login redirect or token refresh for 401
• Show permission message for 403
• Show not-found UI for 404
• Show retry/fallback UI for 5xx or network errors
• Preserve user input when a form submission fails
• Log client-side errors where appropriate

Example error shape:

{
  "code": "VALIDATION_ERROR",
  "message": "Please correct the highlighted fields.",
  "requestId": "req_123",
  "fields": {
    "title": "Title is required"
  }
}

A strong full stack answer is:

“I design errors as part of the API contract. The backend returns structured errors, and the frontend maps them to useful UX instead of showing a generic failure for everything.”

A strong answer is:

“I design errors as part of the API contract. The backend returns structured errors, and the frontend maps them to useful UX instead of showing a generic failure for everything.”

What interviewers are testing: Whether you can write and reason about the SQL needed for application features, including joins, constraints, transactions, indexes, and query shape.

A full stack developer should know feature-level SQL well enough to build and debug application features.

Important topics:

• SELECT, WHERE, ORDER BY, LIMIT
• JOIN across related tables
• GROUP BY for simple reports
• INSERT, UPDATE, and DELETE
• Transactions for multi-step writes
• Primary keys and foreign keys
• Unique constraints
• Basic indexes
• Avoiding N+1 query patterns
• Reading query plans at a basic level

Examples of interview expectations:

• Fetch user orders with product details
• Create a record and related child rows in one transaction
• Add an index for a slow lookup
• Explain why a join duplicates rows
• Design a simple schema for a feature

A strong answer is:

I do not need DBA-level tuning for every role, but I should understand joins, transactions, constraints, and indexes because they directly affect app correctness and performance.

Practice: SQL technical interview questions for deeper query and database drill.

What interviewers are testing: Whether you can contrast ORM and raw SQL — trade-offs with trade-offs and a concrete example of when each is the right choice.

An ORM maps database tables to application objects and reduces repetitive CRUD code.

Use ORM for:

• Common domain CRUD
• Simple relationships
• Standard application workflows
• Faster development

Use raw SQL for:

• Complex reporting
• Heavy joins
• Bulk operations
• Performance-sensitive queries
• Queries that the ORM generates poorly

A strong answer is:

I use an ORM for normal domain operations, but I still inspect generated SQL and drop to raw SQL when query shape, performance, or reporting complexity demands it.

What interviewers are testing: Whether your schema follows product relationships and access patterns while preserving integrity through keys, constraints, normalization, and appropriate indexes.

Start from product requirements and data access patterns.

Steps:

1. Identify core entities.
2. Define relationships.
3. Choose primary keys and foreign keys.
4. Add required constraints.
5. Normalize the schema first.
6. Add indexes for common lookup paths.
7. Add timestamps such as created_at and updated_at.
8. Add soft delete only when the product needs recovery/audit behavior.
9. Denormalize only when read performance justifies it.

Example blog entities:

Example e-commerce entities:

A strong answer is:

I design the normalized model first, add constraints for correctness, then add indexes and selective denormalization based on real query patterns.

What interviewers are testing: Whether you can change a production schema without assuming the application and database deploy atomically—using backward-compatible migrations, staged backfills, observability, and a safe recovery path.

Production database changes should be versioned, reviewed, and backward compatible.

Good practices:

• Use versioned migrations such as Flyway, Liquibase, Prisma Migrate, or similar tools
• Store migration files in version control
• Test migrations in staging
• Avoid destructive changes in the same release that introduces new code
• Make changes backward compatible when possible
• Backfill large data changes carefully
• Have rollback or recovery steps
• Monitor errors after deployment

For zero-downtime changes, use the expand/contract pattern.

Example rename flow:

1. Add new nullable column.
2. Deploy code that writes to both old and new columns.
3. Backfill existing rows.
4. Deploy code that reads from the new column.
5. Stop writing to the old column.
6. Drop the old column in a later release.

A strong answer is:

I avoid risky one-step schema changes in production. I use versioned migrations and backward-compatible expand/contract steps so old and new app versions can run safely during deployment.

What interviewers are testing: Whether you can name decision criteria for would you choose mongodb or dynamodb over postgresql instead of a blanket always/never rule.

Choose the database based on data shape, access patterns, consistency needs, team skill, and operational requirements.

PostgreSQL is a strong default when you need:

• Relational data
• Joins
• Transactions
• Constraints
• Ad hoc SQL queries
• Reporting
• Strong consistency for business records

MongoDB can be a good fit when:

• Data is naturally document-shaped
• Related data is usually read together
• Schema changes frequently
• Flexible document structure helps development
• Access patterns fit document modeling

DynamoDB can be a good fit when:

• You need very high scale
• Access patterns are known upfront
• Key-value/document access works well
• You want managed scaling
• You can design around partition keys and avoid joins

A common mistake is choosing NoSQL only because it sounds more scalable. Poor data modeling can make NoSQL harder, not easier.

A strong answer is:

I usually choose PostgreSQL by default for relational product data. I choose MongoDB or DynamoDB when the access patterns, scale requirements, and document/key-value model clearly fit the product.

What interviewers are testing: Whether you can trace authentication across browser and backend while reasoning about credential storage, token/session lifecycle, CSRF, XSS exposure, refresh, logout, and authorization.

One common token-based SPA architecture is:

1. User submits email and password from the React login form.
2. React sends a POST /api/auth/login request over HTTPS.
3. Spring Boot validates credentials.
4. Server returns a short-lived access token and sets a secure refresh token cookie.
5. React stores the access token in memory and sends it as Authorization: Bearer <token>.
6. When the access token expires, React calls a refresh endpoint.
7. Server validates and rotates the refresh token.
8. Logout clears the refresh cookie and invalidates the refresh token if stored server-side.

Same-origin browser apps may instead use a server-side session or BFF pattern where authentication credentials remain in HttpOnly cookies and browser JavaScript does not handle bearer tokens.

Security points to mention:

• Use HTTPS everywhere.
• Store passwords using bcrypt, Argon2id, or another strong password hashing algorithm.
• Avoid storing refresh tokens in localStorage.
• Use httpOnly, Secure, and SameSite cookie attributes.
• Add CSRF protection when authentication depends on cookies.
• Keep access tokens short-lived.
• Rotate refresh tokens where possible.
• Do not expose sensitive token details in logs.

A strong answer is:

I separate short-lived access tokens from refresh tokens, protect refresh tokens with httpOnly cookies, handle CSRF when cookies are used, and make logout/refresh behavior explicit.

What interviewers are testing: Whether you can contrast What is CORS and how do you fix it in development and production with trade-offs and a concrete example of when each is the right choice.

CORS stands for Cross-Origin Resource Sharing. It is a browser security mechanism that controls whether frontend JavaScript from one origin can read responses from another origin.

Example:

• Frontend: http://localhost:5173
• Backend: http://localhost:8080

These are different origins because the port is different.

How to fix it in development:

• Use a Vite/Webpack dev proxy so the browser sees same-origin requests.
• Or configure Spring Boot CORS for the local frontend origin.

How to fix it in production:

• Put the frontend and API behind the same origin when that architecture makes sense, for example by reverse-proxying /api to the backend.
• Use an API gateway or reverse proxy.
• Configure explicit allowed origins.
• Allow only required methods and headers.
• Do not use Access-Control-Allow-Origin: * with credentials.

Common mistake:

“CORS is not fixed from React alone. The backend or gateway must send the correct CORS headers.”

A strong answer is:

CORS is enforced by the browser. In dev, I often use a proxy. In production, I configure an explicit origin allowlist and never use wildcard origins with credentialed requests.

What interviewers are testing: Whether security is part of your normal design thinking across browser, API, authentication, database, dependencies, secrets, and deployment—not something you add only after the feature works.

A full stack developer should know the common security basics across frontend, backend, and database.

Important checklist:

• Use HTTPS everywhere.
• Hash passwords with bcrypt, Argon2id, or another strong password hashing algorithm.
• Never store passwords in plain text.
• Validate input on the backend, not only in the UI.
• Use parameterized queries or ORM-safe query APIs to prevent SQL injection.
• Add rate limiting on login, signup, password reset, and OTP endpoints.
• Use proper authentication and authorization checks.
• Protect cookie-based flows from CSRF.
• Use context-appropriate output encoding, and sanitize user-generated HTML when the product intentionally allows HTML content.
• Set security headers such as HSTS and CSP where appropriate.
• Do not expose secrets in frontend code, logs, or Git.
• Scan dependencies with tools such as npm audit, OWASP Dependency-Check, Snyk, or similar.
• Log security-relevant events without leaking sensitive data.

A strong answer is:

I think about security at every boundary: browser, API, database, dependencies, deployment, and logs.

What interviewers are testing: Whether you can contrast Session cookies and JWT — when to use each with trade-offs and a concrete example of when each is the right choice.

Both session cookies and JWTs can be valid choices.

Session cookies:

• Server stores session state.
• Browser sends session cookie automatically.
• Logout/revocation is straightforward.
• CSRF protection matters for cookie-based auth.

JWT:

• Token carries claims.
• A self-contained signed JWT can usually be validated without a server-side session lookup, although applications may still perform revocation or account-state checks.
• Works well for distributed APIs, mobile/native clients, and service-to-service calls.
• Revocation needs short expiry, refresh rotation, or token blocklist.
• Avoid putting sensitive data in JWT claims.

Mobile/native apps have different credential-storage considerations than browser SPAs.

A practical full stack answer:

“For a traditional server-rendered app, I may choose sessions. For distributed APIs or mobile clients, I may use short-lived JWT access tokens with a secure refresh-token strategy. For browser apps, I also consider sessions or a BFF so tokens are not exposed to JavaScript. The key trade-off is revocation, storage, CSRF, and operational complexity.”

A strong answer is:

“For a traditional server-rendered app, I may choose sessions. For distributed APIs or mobile clients, I may use short-lived JWT access tokens with a secure refresh-token strategy. For browser apps, I also consider sessions or a BFF so tokens are not exposed to JavaScript. The key trade-off is revocation, storage, CSRF, and operational complexity.”

What interviewers are testing: Whether you understand separation of HTTP concerns, business rules, transaction boundaries, and persistence rather than putting all logic in controllers.

A typical Spring Boot REST app is organized into layers:

Controller  →  Service  →  Repository  →  Database
   HTTP        business       JPA/SQL

Example request flow:

1. React calls POST /api/orders.
2. Controller receives and validates the request DTO.
3. Service applies business rules.
4. Repository saves data inside a transaction.
5. Controller returns a response DTO to React.

A strong answer is:

I keep HTTP concerns in the controller, business rules in the service, and persistence logic in the repository. This separation makes the code easier to test and maintain.

For core Java depth, use the Java interview guide.

What interviewers are testing: Whether you can define Spring Boot auto-configuration at interview level precisely and connect it to when it matters in real systems—not a one-line textbook definition.

Spring Boot auto-configuration helps set up common application components automatically based on the dependencies available in the project.

For example:

• If web dependencies are present, Spring Boot configures web-related beans.
• If database dependencies are present, it can configure datasource-related components.
• If Spring Security is present, security defaults are applied unless customized.

Spring Boot starters are dependency bundles that make common setup easier.

Examples:

• spring-boot-starter-web
• spring-boot-starter-data-jpa
• spring-boot-starter-security
• spring-boot-starter-test

You can customize behavior using:

• application.properties
• application.yml
• Custom @Configuration classes
• Explicit @Bean definitions

Auto-configuration is conditional: Spring Boot activates configuration when relevant classes, properties, and beans are present, and many defaults back off when you provide your own configuration.

A strong answer is:

Spring Boot auto-configuration conditionally provides common beans based on the classpath, properties, and existing beans. It saves boilerplate, but I can override or replace those defaults when the application needs different behavior.

What interviewers are testing: Whether you keep persistence models separate from external API contracts to avoid leaking database structure, sensitive fields, and ORM behavior into the frontend.

Separate Entity and DTO classes because database structure and API contracts should not be tightly coupled.

Why separation matters:

• Avoids exposing internal database structure
• Prevents accidental exposure of sensitive fields
• Avoids circular JSON from bidirectional relationships
• Reduces over-fetching
• Allows API versioning
• Keeps frontend contract stable even if database changes
• Makes validation cleaner for request bodies

Mapping options:

• Manual mapper
• MapStruct
• ModelMapper
• Constructor/projection-based DTOs for read endpoints

A strong answer is:

Entities model persistence. DTOs model the API contract. Keeping them separate protects the API from database changes and prevents leaking fields or lazy relationships to React.

What interviewers are testing: Whether you understand the operational trade-offs between one deployable artifact and independently deployed frontend/API components.

React and Spring Boot can be deployed together or separately.

Separate deployment example:

• React: app.example.com
• API: api.example.com
• CDN serves static assets.
• Spring Boot runs as API service.
• CORS or gateway routing is configured correctly.

Embedded deployment example:

• Run npm run build
• Copy React build output into Spring Boot static resources
• Package one JAR
• Deploy one artifact

CI/CD steps usually include:

1. Install frontend dependencies.
2. Build React app.
3. Run frontend tests.
4. Build Spring Boot app.
5. Run backend tests.
6. Package artifacts.
7. Deploy frontend and backend together or separately.

A strong answer is:

Separate frontend/CDN and backend deployment is common when independent scaling, release cadence, or edge caching matters. A single deployment can be simpler and completely appropriate for smaller or tightly coupled applications.

What interviewers are testing: Whether you can prove end-to-end ownership through a real project—what problem you solved, which decisions you personally made, what went wrong, how you fixed it, and what measurable outcome followed.

Use a structured answer that shows end-to-end ownership.

Good structure:

1. Product goal — what problem the feature solved
2. Frontend — React components, forms, routing, state management
3. Backend — Spring Boot REST APIs, validation, services
4. Database — JPA entities, schema design, migrations
5. Auth/security — login, roles, permissions, secure cookies/JWT
6. Challenge — CORS issue, N+1 query, slow endpoint, auth edge case, deployment issue
7. Fix — what you changed and why
8. Outcome — latency reduction, fewer bugs, better UX, successful release

Example answer outline:

“I built a portfolio dashboard where users could log in, create records, and view analytics. The frontend used React forms and React Query for API state. The backend used Spring Boot REST controllers, service-layer validation, JPA repositories, and Flyway migrations. One issue was an N+1 query on the dashboard endpoint, which I fixed by changing the query strategy and adding a test. The page became faster and the API response time dropped.”

A strong answer is:

I explain the feature from UI to database, then highlight one real trade-off or bug I solved. That proves full stack ownership better than listing technologies.

What interviewers are testing: Whether you can decompose the problem into components, justify technology choices, and discuss scale and failure handling—not just list buzzwords.

Start by clarifying scope:

• Single-user todos or shared lists?
• Real-time collaboration or refresh-based updates?
• Simple checklist or comments, assignments, and due dates?
• Web-only or mobile clients too?

A simple full stack design:

Important trade-offs:

• Use polling for simpler apps.
• Use WebSocket/SSE when many users need live updates.
• Use optimistic UI for fast feedback, but handle rollback on API failure.
• Add permissions checks on the backend, not only in React.

A strong answer is:

I would first clarify whether collaboration is real-time. Then I would design the data model, API, permission checks, frontend states, and deployment path together.

What interviewers are testing: Whether you can decompose the problem into components, justify technology choices, and discuss scale and failure handling—not just list buzzwords.

A URL shortener tests API design, database modeling, caching, and read-heavy system thinking.

Core requirements:

• User enters a long URL.
• System generates a short code.
• Visiting the short URL redirects to the original URL.
• Optional analytics track clicks.

Basic design:

Important trade-offs:

• Random short codes need collision handling.
• Sequential IDs are simple but predictable unless encoded carefully.
• Redirect endpoint should be optimized because it receives most traffic.
• Analytics should not slow down redirects.

A strong answer is:

I would keep redirect fast, cache hot links, and log analytics asynchronously so click tracking does not increase redirect latency.

What interviewers are testing: Whether you choose the cache layer, key, TTL, and invalidation strategy based on freshness and correctness rather than saying "add Redis."

Caching can happen at multiple layers.

Database indexes improve lookup efficiency but are not application caches. Databases also maintain their own internal buffer/page caches, which are a different concern from application-level caching.

Caching helps reduce latency and load, but it adds invalidation complexity.

Common strategies:

• Use long cache TTLs for versioned static assets.
• Use short TTLs for frequently changing API data.
• Invalidate cache when important data changes.
• Use stale-while-revalidate where slightly stale data is acceptable.
• Avoid caching user-specific sensitive data incorrectly.

A strong answer is:

I cache based on data freshness and risk. Static assets can be cached aggressively, but user-specific or frequently changing data needs careful invalidation.

What interviewers are testing: Whether you can contrast Monolith and microservices for a growing product with trade-offs and a concrete example of when each is the right choice.

For most early or medium products, I would start with a modular monolith.

A modular monolith means:

• One deployable application
• Clear module/package boundaries
• Shared database or carefully separated schemas
• Simpler development and operations
• Easier debugging and transactions

Move toward microservices only when there is a real reason:

• Different modules need independent scaling
• Teams need independent ownership and deployment
• Release cadence is blocked by one large codebase
• Fault isolation is important
• A bounded context is stable enough to split

Trade-offs:

A strong senior answer is:

“I would not split into microservices just because the product is growing. I would first enforce module boundaries, then split services only when scaling, ownership, or release independence justifies the operational cost.”

A strong answer is:

“I would not split into microservices just because the product is growing. I would first enforce module boundaries, then split services only when scaling, ownership, or release independence justifies the operational cost.”

What interviewers are testing: Whether you can place tests at the cheapest layer that gives useful confidence—unit tests for logic, integration tests for boundaries and persistence, component tests for UI behavior, and a smaller number of E2E tests for critical user journeys.

A good full stack testing strategy covers business logic, API contracts, database behavior, and critical user flows.

Critical flows worth E2E testing:

• Login
• Signup
• Checkout
• Create/edit/delete record
• Permission-sensitive actions
• Password reset

Interview point:

“Unit tests are fast, but integration tests catch API, database, and contract bugs that unit tests miss.”

A strong answer is:

I use unit tests for logic, integration tests for API/database behavior, and a smaller number of E2E tests for the most important user journeys.

What interviewers are testing: Whether you understand how source code becomes a tested, immutable deployable artifact and how Docker plus CI/CD reduces differences between developer, test, and production environments.

Docker and CI/CD help make development, testing, and deployment repeatable.

Docker usage:

• Dockerfile for backend API
• Multi-stage builds for smaller production images
• docker compose for local API, frontend, database, and cache
• Environment variables for config
• Separate dev and production settings

CI/CD pipeline usually runs:

1. Install dependencies
2. Lint frontend and backend
3. Run unit tests
4. Run integration tests
5. Build frontend
6. Build backend/API image
7. Run security or dependency checks
8. Deploy to staging
9. Deploy to production after approval or merge

You do not need Kubernetes depth unless the job description expects platform or DevOps ownership.

A strong answer is:

I use Docker to make environments repeatable and CI/CD to catch issues before deployment. The pipeline should build, test, package, and deploy in a predictable way.

What interviewers are testing: Whether your Git workflow enables small reviewable changes, safe integration, automated checks, and straightforward rollback rather than whether you memorized Git commands.

Many teams use trunk-based development or a lightweight feature-branch workflow.

Common practices:

• Short-lived feature branches
• Pull request review
• Required CI checks
• Protected main branch
• Squash or rebase merge
• Linked ticket or issue
• Clear commit messages
• Code owners for sensitive areas

GitFlow may still appear in some release-heavy teams, but many web teams prefer simpler flows with frequent merges.

Interviewers care about collaboration, not only Git commands.

Good stories to prepare:

• You handled code review feedback well
• You resolved a merge conflict
• You split a large PR into smaller pieces
• You reverted a risky change safely
• You improved CI or review quality

A strong answer is:

I prefer small PRs, required checks, and frequent integration. The workflow should reduce merge risk and make code review easier.

What interviewers are testing: Whether you can give a specific, honest story with situation, action, and outcome—not a generic strength disguised as a weakness.

Use the STAR format.

A good full stack story should show that you can ship without ignoring risk.

Example structure:

A strong story includes:

• What you intentionally simplified
• What you refused to compromise on
• What risk remained
• How you documented or monitored it
• What follow-up work happened

A strong answer is:

I can move fast, but I make trade-offs visible. I document known debt, protect critical paths with tests, and avoid shortcuts that create security or data integrity risk.

What interviewers are testing: Whether you debug across boundaries systematically—browser → HTTP request → API → application logs → database—instead of guessing which layer is responsible.

A full stack bug should be debugged by narrowing the failure layer.

Steps:

1. Reproduce the issue.
2. Check the browser console and network tab.
3. Inspect request URL, method, headers, body, and response.
4. Confirm whether the API returns wrong data or the UI renders it incorrectly.
5. Use correlation/request ID to trace backend logs.
6. Check database query results if needed.
7. Compare recent deployments, feature flags, or config changes.
8. Add a regression test after fixing.

Example:

If a user sees the wrong order status, check:

• Did React call the right endpoint?
• Did the API return the wrong status?
• Did the backend query join the wrong rows?
• Did the database contain stale data?
• Did the UI map status codes incorrectly?

A strong answer is:

I bisect the problem across browser, API, backend logs, and database. Once I find the failing boundary, I add an integration or E2E test to prevent regression.

What interviewers are testing: Whether full stack is a deliberate preference for end-to-end product ownership while still recognizing where specialist depth is necessary.

A strong answer should focus on product ownership, not “I know everything.”

Good reasons:

• You enjoy building features end-to-end.
• You can move faster from UI to API to database.
• You understand frontend needs when designing APIs.
• You understand backend constraints when building UI.
• You like debugging across boundaries.
• You care about user-visible outcomes.

Also be honest about depth limits.

A mature answer:

“I like full stack because I can own a feature from user experience to data persistence. I also know when to involve specialists for security, infrastructure, accessibility audits, or deep database tuning.”

A strong answer is:

“I like full stack because I can own a feature from user experience to data persistence. I also know when to involve specialists for security, infrastructure, accessibility audits, or deep database tuning.”

Ask questions that reveal team structure, expectations, and engineering maturity.

Good questions:

• Is this role truly full stack, or mostly frontend/backend with occasional support?
• How are frontend and backend responsibilities split?
• What is the current stack?
• How does CI/CD work?
• What does the local development setup look like?
• How are production incidents handled?
• Is there on-call responsibility?
• What is the biggest technical debt in the product?
• How are API contracts managed?
• What does success look like in the first 90 days?
• What is the path from mid-level to senior on this team?

A strong answer is:

I ask questions that help me understand ownership, delivery process, production responsibility, and where the team needs the most help.

What interviewers are testing: Whether you understand that disabling a button is only a UX safeguard and that duplicate side effects must be prevented server-side using idempotency, uniqueness, and safe retry semantics.

Full stack reliability needs both UX and server authority.

Client-side (UX):

• Disable the submit button after the first click.
• Show a loading state so the user does not retry immediately.

Server-side (authoritative):

• Accept an idempotency key or request ID from the client on create/payment endpoints.
• Store the key with the resulting resource ID or payment status.
• If the same key arrives again, return the same result instead of performing the side effect twice.
• Bind the idempotency key to the request's operation/payload or reject conflicting reuse, so the same key cannot silently represent two different payment requests.
• Add a unique database constraint on business keys where appropriate (for example, external payment reference).

Example flow:

1. User clicks Pay.
2. Frontend generates Idempotency-Key: pay_abc123 and sends it with the request.
3. Backend processes payment once and stores { key: pay_abc123, orderId: 42, status: paid }.
4. A retry with the same key returns order 42 with status paid—no second charge.

A strong answer is:

“The UI reduces duplicate clicks, but the server remains authoritative. I use idempotency keys plus unique constraints so retries are safe and return the original outcome.”