What are the best full stack developer interview questions?
The best full stack developer interview questions test React/Vue component architecture, Node.js async patterns, database query optimization, TypeScript generics, and English communication separately. Ask stage-specific questions rather than one long general round to surface genuine depth in each layer.
Split into stages: frontend, backend, database, TypeScript, architecture, communication
Ask about real failures and production incidents, not theoretical best practices
For nearshore hires: the technical interview is your English communication assessment
Last updated: August 18, 2026
A single-round “full stack technical interview” almost never works. It either tests too broadly and catches nothing, or it goes deep on one layer and misses gaps in the others. The engineers who look strong in a generalist round and fall apart in their first sprint are often the ones who passed a shallow screen that never tested their actual layer weaknesses.
These questions are organized by layer and stage because that’s how genuine full stack depth reveals itself. Run them in sequence, not all at once, and adjust based on what you hear.
How to Structure a Full Stack Developer Interview
The most effective full stack interview structure mirrors the actual layers of the job. One marathon technical round does not surface layer-specific gaps. A developer who sounds technically fluent in a general conversation can be surprisingly thin in React hooks, async Node.js patterns, or database query optimization when you drill into each layer individually.
The recommended structure for a senior or mid-level full stack hire is five stages: a screening call, a frontend technical session, a backend technical session, an architecture and system design conversation, and a culture and communication check. For junior roles, collapse the architecture round into the backend session and shorten each stage.
For nearshore hiring specifically, the structure is slightly different because a reputable staffing partner has already completed a pre-screening process. Your interview rounds are adding depth to a candidate who has already passed language assessment, technical screening, and communication evaluation. That means your rounds should go deeper and faster than a cold sourcing process, not duplicate the pre-screen. Use the stages below to validate and extend what the pre-screen found, not to restart from scratch.
Run every round over video, not phone. Video replicates the actual working conditions. Someone who struggles to share their screen during an interview call will not improve once hired. The video interview is also your direct assessment of communication clarity, camera presence, and how they handle technical explanations in real time.
Frontend Interview Questions (React, Vue, Angular)
These questions are designed to surface genuine frontend depth rather than vocabulary. Strong answers reference specific decisions, real tradeoffs, and concrete production experience. Watch for candidates who describe what should happen rather than what actually happened.
“Walk me through how you’d manage shared state across three components that don’t share a parent.”
Listen for: Concrete decision-making between Context API, Zustand, Redux Toolkit, or Jotai. Awareness of prop drilling as the problem being solved. An opinion on when global state is worth the overhead versus lifting state or restructuring the component tree.
“How do you decide when to use useEffect vs useCallback vs useMemo?”
Listen for: Understanding of the dependencies array and stale closure risk. Awareness that useMemo and useCallback are optimization tools, not defaults. Concrete examples of when they’ve over-used or had to remove them after profiling.
“What’s your approach to code splitting and lazy loading in a large React app?”
Listen for: React.lazy() and Suspense usage, dynamic imports, route-based splitting as the first lever, component-level splitting as the second. Awareness of chunk naming and loading states.
“How would you structure a form with 20 fields that validates on blur and on submit?”
Listen for: React Hook Form or Formik versus rolling their own. Validation library usage (Zod, Yup). Understanding of controlled versus uncontrolled inputs and why 20 controlled fields can cause re-render problems.
“Describe a performance problem you’ve debugged in a React or Vue app. What tools did you use?”
Listen for: React Profiler, React DevTools, Lighthouse, Chrome Performance tab. Specific before-and-after description of the fix. Avoid answers that name tools without describing the actual optimization step.
“How does TypeScript help you in a component-based frontend codebase?”
Listen for: Interface-first prop definitions, discriminated unions for component state, type-safe API response shapes. Not just “it catches errors” — they should give a specific pattern they use regularly.
“What is your approach to accessibility in the components you build?”
Listen for: ARIA attributes used correctly (not just added), keyboard navigation testing, screen reader awareness, Core Web Vitals as a related concern. Absence of any accessibility thinking is a signal for embedded team roles.
“How do you handle real-time updates in a web application?”
Listen for: Decision-making between WebSockets, Server-Sent Events, and polling based on use case. Trade-offs between each. Awareness of reconnection logic and connection state in the UI.
Backend Interview Questions (Node.js, Python, Java)
Backend questions should probe async architecture, error handling patterns, security decisions, and debugging experience in production environments. Candidates with tutorial experience know the happy path. Candidates with production experience know what fails and why.
“Explain how Node.js handles concurrency. Why does a CPU-intensive task block the event loop?”
Listen for: Clear explanation of the event loop, single-threaded runtime, and I/O-bound versus CPU-bound work. Worker threads or child_process clustering as the solution for CPU-intensive work. Candidates who say “Node.js is single-threaded so it can’t handle concurrency” have a gap in understanding.
“How do you handle errors in an async Express or Fastify API?”
Listen for: try/catch wrapping async route handlers, centralized error middleware, structured error response shapes (status code, message, error code). Awareness of unhandledRejection as a process-level risk.
“Walk me through designing a rate-limited API endpoint.”
Listen for: Token bucket versus sliding window algorithm, Redis for distributed rate limiting across multiple server instances, 429 response with Retry-After header. Candidates who only mention in-memory rate limiting don’t understand the distributed context.
“What’s the difference between JWT and session-based authentication? When would you use each?”
Listen for: Stateless versus stateful trade-offs, refresh token rotation for JWTs, revocation difficulty with JWTs, server memory or Redis store for sessions. An opinion on when each is appropriate with a real use case from their experience.
“How do you prevent N+1 queries when an API endpoint returns a list of items with nested relations?”
Listen for: DataLoader pattern for batching, eager loading in the ORM (.include() in Prisma, .populate() in Mongoose, joinedload in SQLAlchemy), specific ORM knowledge rather than a generic “use joins” answer.
“Describe a time you debugged a memory leak in a Node.js application.”
Listen for: –inspect flag and Chrome DevTools, heap snapshots to compare before and after, process.memoryUsage() for monitoring, specific root cause (event listener not removed, closure holding reference, large data in module cache). Generic answers that describe what a memory leak is rather than what they actually did are a signal.
“How do you structure environment configuration across local, staging, and production environments?”
Listen for: dotenv for local development, AWS Secrets Manager, HashiCorp Vault, or similar for production secrets, 12-factor app principles, never committing secrets to version control. Bonus: mention of secret scanning in CI/CD.
“When would you choose GraphQL over REST, and vice versa?”
Listen for: Over-fetching and under-fetching as the GraphQL motivation, schema complexity and tooling overhead as the REST motivation, a real use case from their experience rather than textbook definitions. Watch for candidates who default to “GraphQL is always better” without acknowledging the caching and complexity trade-offs.
Database Interview Questions (PostgreSQL, MongoDB, MySQL)
Database questions are where production experience versus theoretical knowledge separates most clearly. Every developer knows what an index is. Fewer can explain when not to add one, or how to design a schema for multi-tenant SaaS without breaking production during a migration.
“How do you identify and fix a slow query in PostgreSQL?”
Listen for: EXPLAIN ANALYZE as the first tool, reading actual row estimates versus plan estimates, index creation based on query pattern analysis, query restructuring before adding indexes as reflex. “Add an index” alone is not a complete answer.
“When would you use a composite index vs a single-column index?”
Listen for: Column order in composite indexes matching the query’s WHERE clause and ORDER BY, cardinality of each column, covering indexes that include all queried columns to avoid table lookups. Candidates who don’t understand column order in composite indexes have a real gap.
“Describe how you’d design the schema for a multi-tenant SaaS application.”
Listen for: Row-level isolation (tenant_id column on every table) versus schema-per-tenant versus database-per-tenant, trade-offs in isolation, performance, and migration complexity for each approach. An opinion on which model fits which scale and compliance requirement.
“How do you handle database migrations in a team environment without breaking production?”
Listen for: Zero-downtime techniques (add column before dropping, backfill data in batches, deploy application code before removing old column), backward-compatible schema changes, rollback plans, migration tooling (Flyway, Liquibase, Prisma Migrate, Alembic). “We run migrations in a maintenance window” is a real answer but raises a follow-up about scale.
“What is the N+1 problem and how do you solve it at the ORM level?”
Listen for: Clear explanation of the problem (one query for the list, then one query per item for the relation), ORM-level eager loading as the primary solution, DataLoader batching for API resolvers, direct join queries as the alternative. Candidates should give a specific ORM example, not a generic description.
“When would you choose MongoDB over PostgreSQL for a new project?”
Listen for: Specific use cases: document-heavy data with highly variable schemas, horizontal sharding at scale, real-time event storage. Not “NoSQL is faster” or “MongoDB is more flexible” without qualification. The strongest answers note that PostgreSQL with JSONB covers many document use cases and MongoDB’s trade-offs (no multi-document transactions until 4.x, eventual consistency risks) are real.
Want Pre-Screened Full Stack Candidates?
Kore BPO delivers shortlists of nearshore full stack developers in 2 to 5 business days. No upfront fees.
Contact Us
TypeScript Interview Questions
TypeScript fluency is not binary. Developers who have used TypeScript for a year in a permissive config are very different from developers who have written TypeScript in strict mode with no-any enforcement and real generic patterns. These questions separate them.
“What is a discriminated union and when would you use one?”
Listen for: Literal type narrowing via a shared discriminant property (type: ‘success’ | ‘error’), exhaustiveness checking with a never branch in a switch statement, a real use case like API response typing or reducer state management.
“How do you type an API response that might have one of three shapes?”
Listen for: Union types defined upfront, type guard functions (instanceof or custom is checks), Zod or Yup for runtime validation that also generates TypeScript types. Candidates who say “just use any” have a meaningful gap for TypeScript-first codebases.
“What is the difference between interface and type in TypeScript?”
Listen for: Declaration merging (interfaces can be extended after definition, types cannot), complex types like mapped types and conditional types (types only), union and intersection syntax. A practical preference with reasoning, not just a textbook answer. Both are acceptable in most codebases; the answer reveals depth of daily usage.
“How do you avoid ‘any’ when typing a third-party library that has poor or missing types?”
Listen for: Module augmentation (declare module ‘library’), type assertion with a narrowing guard, creating a local @types file, contributing to DefinitelyTyped if the library is widely used. Not just “use as any and move on.”
“What TypeScript compiler flags do you always enable and why?”
Listen for: strict mode as the baseline (covers strictNullChecks, noImplicitAny, strictFunctionTypes), noUncheckedIndexedAccess for array safety, exactOptionalPropertyTypes for precise optional handling. Reasoning for each flag shows actual experience with the bugs they prevent.
System Design and Architecture Questions
These questions are for senior and lead-level candidates. They surface the difference between developers who execute well-designed systems and developers who can design them. Run one or two, not all four, and give the candidate time to think before responding.
“How would you architect a feature that sends real-time notifications to 50,000 users?”
Listen for: WebSockets versus SSE versus long polling decision, a message broker (Redis Pub/Sub, Kafka, SQS) for fan-out, connection management at scale, reconnection handling in the client. Candidates who jump to “use WebSockets” without addressing the fan-out problem at 50K concurrent connections have a gap in distributed systems thinking.
“How would you migrate a monolithic Express API to microservices?”
Listen for: Incremental extraction (strangler fig pattern), API gateway for routing, service discovery, domain-driven service boundaries, data ownership per service. Not “split it up by route.” The order of extraction and the database decomposition strategy are the hard parts. Candidates who skip the data layer haven’t done this in production.
“How would you design the backend for a dashboard that aggregates data from five different third-party APIs?”
Listen for: Caching layers (per-source TTL, Redis or edge cache), rate limit handling per external API, error isolation so one failed source doesn’t break the dashboard, data freshness trade-offs and stale-while-revalidate patterns. Background job refreshes versus on-demand fetching.
“What’s your approach to logging and observability for a distributed full stack application?”
Listen for: Structured logging (JSON format, not string concatenation), correlation IDs passed through requests and across service boundaries, OpenTelemetry as the tracing standard, alerting thresholds on error rates and latency percentiles (p95, p99), not just average response time. Tool awareness (Datadog, Grafana, Honeycomb) is secondary to understanding what to measure and why.
Questions to Assess Communication and Distributed Team Fit
For nearshore full stack developers, communication questions are not a soft add-on. They are a core screen. A developer who writes good code but cannot explain a design decision in writing, ask a specific unblocking question in Slack, or clearly describe a problem in a standup creates ongoing friction that compounds at 20 standups per month over 12 months. Weight this section accordingly.
Ask these questions conversationally, not as a formal round. Listen for specificity, self-awareness, and how naturally the candidate communicates rather than whether they have polished answers.
- “Describe a PR comment you received that changed how you approached the code. How did you respond?” Listen for: intellectual honesty, ability to take feedback without defensiveness, a specific code example rather than a generic “I’m always open to feedback.”
- “How do you communicate a blocker in a distributed team when the person who can unblock you is in a different time zone?” Listen for: async-first thinking, Slack message with enough context for someone to respond without a follow-up clarification, internal judgment about when to wait versus escalate.
- “Tell me about a feature you shipped that didn’t go as planned. What happened and what did you do?” Listen for: specific account of the failure, their role versus the team’s role, what changed afterward. Candidates who describe team failures without any personal accountability or who can’t describe a concrete failure are signals.
- “How do you stay current with changes in the React or Node.js ecosystem?” Listen for: specific sources (official release notes, specific blogs, conference talks), a recent thing they learned and applied, not just “I follow Twitter.”
- “Walk me through how you’d explain a database schema decision to a non-technical product manager.” Listen for: ability to reduce technical detail without losing the core trade-off, use of analogy or plain language, checking for understanding rather than lecturing. This is a direct test of communication skill in a situation that happens weekly in a cross-functional sprint team.
For nearshore hiring: run the entire technical interview in English and assess communication during that conversation. You do not need a separate English test. The technical interview is the communication assessment if you pay attention to clarity, response specificity, and how naturally the candidate asks follow-up questions.
Frequently Asked Questions
What are the most important full stack developer interview questions?
The most diagnostic questions are layer-specific: a React state management question for frontend depth, a Node.js event loop question for backend depth, an N+1 question for database depth, and a TypeScript discriminated union question for type system understanding. One-size-fits-all general coding challenges miss layer-specific gaps.
How many interview rounds should a full stack developer go through?
Two to three client-side rounds after pre-screening: a technical round covering frontend and backend, an architecture discussion for senior roles, and a culture and communication conversation. More than three rounds increases drop-off without adding proportional signal. For nearshore hires through a staffing agency, the agency pre-screen replaces your first round.
How do I test React skills without a long take-home assignment?
A 30 to 45 minute live session is more diagnostic than a take-home. Ask the developer to walk through a component they’ve built, then ask follow-up questions about state decisions, TypeScript usage, and how they’d add a specific feature. Live walkthroughs reveal reasoning; take-homes reveal polish.
What questions reveal whether a developer has real production experience vs tutorial experience?
Ask about failures: a slow query they diagnosed, a memory leak they fixed, a migration that went wrong. Developers with production experience give specific, concrete answers. Developers with tutorial experience give textbook descriptions of what should happen, not what actually happened and what they did about it.
How do I assess English for a nearshore hire without seeming intrusive?
Simply run the technical interview in English and assess during that conversation. Clear code explanations, specific questions, and crisp answers are all signals. You don’t need a separate test. The technical interview itself is the communication assessment if you pay attention to clarity and response specificity.
Should I ask different questions for a nearshore full stack developer than an onshore one?
The technical questions should be identical. Add one or two questions about async communication habits and distributed team experience: “How do you handle a blocker when someone you need is 2 hours behind you in a different time zone?” This surfaces real collaboration experience rather than generic answers.
Disclosure: Kore BPO is a nearshore and offshore staffing agency. This question set reflects our direct experience running full stack developer technical screens for US engineering teams.
