Full-Stack Integration & Deployment — Interview Questions

Q: What is CORS, and why does it exist?

CORS (Cross-Origin Resource Sharing) is a browser-enforced security mechanism, not a server-side restriction. Without it, JavaScript running on any website could silently make requests to any other site — including one you're logged into — and read the response, using your browser's existing session/cookies. CORS requires the server to explicitly declare, via response headers, which origins are allowed to have their frontend JavaScript read its responses. Critically: the request itself frequently still reaches the server — the browser is blocking your JavaScript from reading the response, not necessarily preventing the request from happening at all. This distinction is exactly why a CORS error can appear even when server-side logs show the request was received and processed successfully.

Q: Walk through, in detail, how an auth token flows from a frontend login form to a verified backend request.

A login form collects credentials and sends them to a backend login endpoint. The backend verifies the credentials against the database and, if valid, issues a signed token (commonly a JWT). The frontend receives that token and stores it — the storage mechanism (memory, an httpOnly cookie, localStorage) involves real security tradeoffs covered in this academy's Authentication technology. On every subsequent request to a protected endpoint, the frontend attaches the token, typically as an Authorization: Bearer header. Backend middleware, running before the route handler, verifies the token's signature and expiry; if valid, it attaches the decoded user identity to the request object and calls next(); if invalid, it responds 401 immediately without ever reaching the route handler. A break at any single link in that chain — the frontend forgetting to attach the header, or a route missing the middleware entirely — produces the same visible symptom, which is exactly why tracing the whole chain, rather than guessing at one link, is the real debugging skill being tested here.

Q: What's the actual security distinction between a frontend and backend environment variable?

A backend environment variable lives only on the server process and is never transmitted to the browser — genuinely private. A frontend environment variable (in a framework like Next.js, anything prefixed NEXT_PUBLIC_) gets compiled directly into the JavaScript bundle at build time and shipped to every visitor's browser — readable by anyone via browser dev tools, regardless of intent. The practical rule: a database credential, a signing secret, or a private third-party API key must always be backend-only; only values already intended to be public (a publishable key, a public analytics ID) belong as frontend variables. Treating this as a naming convention rather than a real security boundary is a common, serious mistake.

Q: What are the real tradeoffs between deploying a frontend and backend together vs. separately?

Deployed together — for example, a Next.js app whose own API routes serve as the backend, deployed as one unit — shares an origin, eliminating CORS entirely between frontend and backend, and simplifies deployment to one pipeline and one set of environment variables. The cost is coupling: the backend inherits the frontend deployment platform's constraints (which may not suit a backend needing long-running processes or heavy compute). Deployed separately — a frontend on one platform, a backend on a platform built for persistent servers — allows independent scaling and release cycles, at the cost of reintroducing CORS and requiring two coordinated deployments to stay in sync. Neither is universally correct; the deciding factor is usually whether the backend has genuine infrastructure needs the frontend's platform doesn't support well.

Q: How would you talk about AI coding assistant usage honestly in an interview?

Directly and specifically, rather than either overselling or downplaying it — using AI coding assistants (GitHub Copilot, Claude Code, Cursor, and similar tools) is genuinely standard professional practice in 2026, and interviewers increasingly expect a real, considered answer rather than pretending not to use them. The strong answer names concretely what an assistant helps with (boilerplate, test scaffolding, unfamiliar syntax) and what stays under deliberate human review regardless of how good the suggestion looks (architecture decisions, anything security-sensitive like an auth flow or a database query built from user input). The question being tested isn't "do you use AI" — it's whether you can explain and defend every line in your own project, including AI-generated ones, without deferring responsibility for a bug to "the AI wrote that part."

Q: What does "full-stack" actually mean as a skill, versus just knowing several technologies?

Knowing React and knowing Express independently doesn't automatically mean you know how to make them work together correctly — the integration layer (CORS, environment-variable security, the auth-token handshake, deployment topology) is a distinct, learnable skill set that neither technology teaches in isolation. Full-stack skill specifically means being able to reason about the seams between pieces — what crosses a network boundary, what crosses a public/private security boundary, what contract two independently-deployed pieces have to agree on and keep in sync. This is why a deployed, working project is stronger evidence of full-stack skill than strong frontend code and strong backend code that have never actually been connected and shipped together.

Q: A frontend that worked locally fails entirely after deployment. What's your diagnostic process?

"It worked locally" rules out almost nothing on its own, since local and deployed environments differ simultaneously in origin, environment variables, and network topology. The systematic check, roughly in order: is the frontend calling the correct deployed API URL, or a leftover hardcoded localhost reference? Is the backend's CORS configuration updated to allow the deployed frontend's real origin, not just a local-dev origin? Are all required environment variables actually set on the deployment platform itself, not just present in a local .env file that never left the laptop? These three categories account for the large majority of real "worked locally, broke in production" full-stack failures, and checking them as a deliberate list is faster and more reliable than guessing.

Q: Why does this technology explicitly avoid re-teaching databases, CI/CD, and containerization in depth?

Because that material already exists on this platform, taught in real depth, in the Databases, DevOps, and AI Engineering academies — duplicating it here at a shallower depth would waste time and produce a worse outcome than the dedicated material. This technology's actual job is narrower: teach exactly what's needed to integrate a database connection, a deployment pipeline, or a container into a working full-stack app, and explicitly point toward where the real depth lives for each. This is a deliberate scoping decision, not a content gap — someone who wants deep PostgreSQL or CI/CD knowledge goes to those academies directly, ideally after already understanding, from here, exactly how each piece fits into the full picture.

Q: How do you keep a frontend and backend's error handling consistent with each other?

By agreeing on one shared contract, deliberately, rather than letting each side improvise independently: the backend returns a consistent JSON error shape (commonly { error: "message" }) alongside a meaningful HTTP status code, and the frontend has one shared function that all API calls use to parse that shape rather than each call site reimplementing its own error handling. The status codes themselves carry real meaning both sides need to honor — a 401 should prompt the frontend to clear a stale token and re-prompt login, while a 403 should not, since the user's identity is fine but their permission isn't. Treating every non-2xx response identically on the frontend throws away information the backend deliberately provided.