Full Stack Developer Interview Questions and Answers

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 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.

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.

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.”

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.

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.

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) => response.json())
    .then(setUser)
    .catch((error) => {
      if (error.name !== "AbortError") {
        setError(error);
      }
    });

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

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.

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.”

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

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

A strong answer is:

TypeScript is valuable in full stack work because frontend and backend must agree on data shapes. Types reduce integration bugs and make refactoring safer.

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.

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.

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

Useful distinction:

• 401 means the user is not authenticated.
• 403 means the user is authenticated but not allowed.
• 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.

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.

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.

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 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 drill.

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.

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.

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.

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.

A common login flow 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.

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.

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 frontend and backend behind the same domain when possible.
• 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.

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.
• Escape or sanitize unsafe user-generated content to reduce XSS risk.
• 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 interview answer is:

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

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.
• Backend can verify token without session lookup.
• Works well for APIs and mobile clients.
• Revocation needs short expiry, refresh rotation, or token blocklist.
• Avoid putting sensitive data in JWT claims.

A practical full stack answer:

“For a traditional server-rendered app, I may choose sessions. For SPA/mobile APIs, I may use short-lived JWT access tokens with a secure refresh-token strategy. The key trade-off is revocation, storage, CSRF, and operational complexity.”

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.

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

A strong answer is:

Spring Boot auto-configuration gives sensible defaults based on the classpath, but I can override those defaults with configuration properties or custom beans.

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.

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:

For production, I prefer separate deployment with a CDN for React and an API service for Spring Boot. For small internal apps, embedding React inside the Spring Boot JAR can be simpler.

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.

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.

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.

Caching can happen at multiple layers.

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.

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 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.

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.

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.

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.

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.

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.”

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.

Use the final week to connect concepts across layers.

Checklist:

• Build or polish one mini-app with auth, CRUD, validation, and error states
• Trace one user click from React → API → service → SQL → response → UI
• Practice two system design prompts: todo app and URL shortener
• Review CORS, cookies, JWT, sessions, CSRF, and XSS basics
• Practice SQL joins and CRUD queries
• Explain REST status codes and API error shapes
• Prepare one frontend performance example
• Prepare one backend/database performance example
• Prepare one production debugging story
• Prepare five STAR stories: conflict, deadline, bug, performance, learning
• Review Git workflow, CI/CD, Docker, and deployment basics

Also review:

• SQL technical guide
• Java interview guide
• Node.js developer guide
• design patterns in Java
• Interview Questions

A strong final-week goal:

“Be ready to build a small feature, debug it across layers, explain the architecture, and discuss trade-offs clearly.”